PHP: There are more reasons to deactivate display_errors than just hiding the structure of your code.

Consider this small PHP script:

$dir = $_GET['dir'];
if (substr($dir, 0, 2) == '..' || strpos($dir, '/..') !== false || strpos($dir, "\\..") !== false)
<!doctype html>
<head><title>Show dir</title></head>
if ($dh = opendir(dirname(__FILE__)."/$dir")) {
    while (($file = readdir($dh)) !== false) {
        echo 'filename: '.htmlspecialchars($file)." : filetype: " . filetype($dir . $file) . "\n";
} ?>

Looks fairly innocent, right?
Well it has a hidden XSS vulnerability if display_errors is activated and error_reporting contains E_WARNING. Consider the generated code when calling it with this querystring:


What happens? Well the path (most likely) doesn't exists, so opendir gives a warning of level E_WARNING – containing the unescaped path that couldn't be found:

<!doctype html>
<head><title>Show dir</title></head>

Warning: opendir(/var/www/<script>window.alert('foobar!');</script>): failed to open dir: No such file or directory in /var/www/test.php on line 11

Uhm php, maybe you could at least escape the error messages when the content type currently being outputted is text/html?…

__declspec(thread) on windows

Microsoft Visual C++ Compiler v.100 (the one for Visual Studio 2010) compiles the main function of the following short program:

__declspec(thread) int i = 0;

int main() {

To this:

int main(int argc, char **argv) {
00CC1890  push        ebp
00CC1891  mov         ebp,esp
00CC1893  sub         esp,0C0h
00CC1899  push        ebx
00CC189A  push        esi
00CC189B  push        edi
00CC189C  lea         edi,[ebp+FFFFFF40h]
00CC18A2  mov         ecx,30h
00CC18A7  mov         eax,0CCCCCCCCh
00CC18AC  rep stos    dword ptr es:[edi]
00CC18AE  mov         eax,dword ptr ds:[00CC8194h]
00CC18B3  mov         ecx,dword ptr fs:[0000002Ch]
00CC18BA  mov         edx,dword ptr [ecx+eax*4]
00CC18BD  mov         eax,dword ptr [edx+00000104h]
00CC18C3  add         eax,1
00CC18C6  mov         ecx,dword ptr ds:[00CC8194h]
00CC18CC  mov         edx,dword ptr fs:[0000002Ch]
00CC18D3  mov         ecx,dword ptr [edx+ecx*4]
00CC18D6  mov         dword ptr [ecx+00000104h],eax
00CC18DC  xor         eax,eax
00CC18DE  pop         edi
00CC18DF  pop         esi
00CC18E0  pop         ebx
00CC18E1  mov         esp,ebp
00CC18E3  pop         ebp
00CC18E4  ret

So what is going on here? The interesting part here is this:

ecx,dword ptr fs:[0000002Ch]

What is at fs:[0000002Ch]? The fs segment is offset to start at the start of the Thread Environment Block (TEB). Microsoft won't tell you much except for "don't touch". Wikipedia has more information. Offset 2Ch is a pointer to the Thread Local Storage (TLS) slots. So it stores a TLS index at 00CC8194h, looks up the data at that TLS slot, which apparently is a pointer to an array of thread local values for that thread – where the variable i is placed at offset 104h.

So Microsoft tells us that the TEB is an internal structure subject to change from one Windows version to another, and toying around with it is a big no-no. And yet their compiler happily generates code that directly accesses this "internal implementation detail".

Hipocrisy much?

Has the webservice client lost the connection?

How do you tell if an exception from a call to a webservice is caused by an IO error?

        public static bool IsIoException(Exception e)
            return (e is TimeoutException || e is CommunicationException || e is EndpointNotFoundException) && !(e is FaultException);

Easy, right?

FaultException is derived from CommunicationException, but it occours when the server sends a SOAP fault back, so definitely not a communication problem (at least between client and webservice). I'm not sure why an EndpointNotFoundException would be thrown because of not being able to talk with the host, but I've seen it happen after unplugging my ethernet cable…

So why exactly can't I just have one sort of exception to catch? Am I not supposed to handle a lost connection in a graceful way?

Oww Microsoft thou art a heartless bitch…


In .NET windows forms you can't not have a default button on a dialog

I haven't tested if this only applies to forms shown with ShowDialog or to every form, but the form will always have a default (accept) button – the one receiving enter presses.

Setting the AcceptButton property to null will nevertheless select a button as the default button. Actually the AcceptButton property is complety ignored. Don't believe anything on the MSDN page. The only thing that decides which button receives an enter press is which control has focus.

So what can you do if you don't want a button to has focus when first showing the form? A control must have focus, and it must be visible. But nothing stops you from placing it in an invisible position such as setting Left to -1000. Set it as the form's ActiveControl and set TabStop to false, meaning that the user won't get back to the dummy button when tabbing around.