Spellbook

httpOnly cookies are a Microsoft extension to the cookie standard. The idea is that cookies marked as httpOnly cannot be accessed from JavaScript. This was implemented to stop cookie stealing through XSS vulnerabilities. This is unlike many people believe not a way to stop XSS vulnerabilities, but a way to stop one of the possible attacks (cookie stealing) that are possible through XSS.

Unfortunately the mozilla family still refuses to implement httpOnly cookies in Firefox and therefore their newest release: Firefox 2.0 still comes without support for httpOnly cookies. Luckily an annoying bug within the Firefox internals was fixed in Firefox 2.0 which enables an extension to correctly intercept incoming and outgoing cookies. In previous Firefox versions it was not possible to intercept incoming cookies, because the Cookie header was already parsed before the examine response hook was called.

Therefore I sat down during the last hours and wrote my little httpOnly extension. This extension adds transparent httpOnly cookie support to Firefox by using a funny hack.

The idea of the extension is to create a random key in the Firefox preferences on the first startup. It then hooks the hooks for outgoing and incoming HTTP requests. It then parses all incoming cookies (for now only Set-Cookie header) and rewrites cookies marked as httpOnly. Their name gets a ‘hO_’ prefix and their content gets AES encrypted. The key used for this encryption is based on the key stored in the preferences and the real name of the cookie. This results in Firefox storing an encrypted cookie into it’s cookie storage. Of course it is still possible for JavaScript to read this cookie, but because the content is encrypted it is not possible for malicious JavaScript to retrieve the original value. All outgoing cookies on the other hand will be processed by another hook and decrypted if they are ‘hO_’ prefixed.

With this little hack it is now possible to have httpOnly cookies in Firefox 2.0. You can download this little extension from here. Be warned that this was a hack of only a few hours. Therefore you should only consider it a proof of concept. However I am planning on improving it in the near future.

Update: I just uploaded the extension to addons.mozilla.org.

Original post by blog-admin@nopiracy.de (Stefan Esser)

During the last weeks several researchers have spent their time hunting and warning people that have not read the Flash documentation carefully and therefore exposed their domains to cross domain Flash access. You will even find statistics about the number of Fortune 500 sites affected by this.

Well, I did not participate in such witchhunts, mainly because I do not consider it security research to use google to find crossdomain.xml files or to draw sweet looking statistics. On the other hand these Flash policies were interesting enough for me to test and exploit.

Therefore I researched a bit and have released a mini article about a new class of holes this obscure Flash feature pokes into web applications.

You are invited to read it here.

Original post by blog-admin@nopiracy.de (Stefan Esser)

After 6 months of waiting PHP 4 users finally can install an update that fixes the critical unset() vulnerability that I have disclosed to php.net at the end of January.

Because there are meanwhile a lot of rumours about this vulnerability in the underground and because the PHP 4.4.3 release announcement does not mention this critical hole at all I wrote up a little article about it, which you can read here.

PS: This is the long awaited hole that allows PHP code execution in latest patched phpBB.

Original post by blog-admin@nopiracy.de (Stefan Esser)

While searching for the perfect Wiki PHP application for my own german/korean wiki I tested DokuWiki and found an ugly security hole, that allows remote PHP code injection through it’s AJAX spellchecking service.

You can grab my advisory at the usual place.

Original post by blog-admin@nopiracy.de (Stefan Esser)

During the last days a lot of blog entries, forum posts and even articles in IT magazines were made about a potential phpBB mass hack in preparation. From what is reported it seems to me that FuntKlakow is only a spambot and that the whole situation is a little bit overhyped. In the end it seems enough to enable the visual confirmation in the registration form (captcha) to keep FuntKlakow out, although the captcha is so bad that it should not be hard to break it.

So why am I writing about this. Yes I do believe that FuntKlakow is only a spambot but “all warfare is based upon deception” and therefore this might only be a trick. What I do know on the other hand is, that I recently found another way to bypass phpBB’s register_globals deregistration layer. This time my trick works on all PHP versions and is therefore a lot more dangerous than the tricks that I reported together with the signature_bbcode_uid remote code execution exploit. Of course it still means the phpBB host needs register_globals turned on, but I guess a worm will find enough of such hosts.

It is also noteworthy that the fact that signature_bbcode_uid is still exploitable is simply caused by the fact, that the phpBB did not use the patch supplied by me to fix the issue. Instead they used their own patch. This is why I blame them for still beeing vulnerable to modified signature_bbcode_uid exploits, although the trick I use is not their fault.

And of course it is also their fault, that they still do not mention the remote code execution vulnerability in their security tracker at all…

Original post by blog-admin@nopiracy.de (Stefan Esser)