The Web Application Hacker's Handbook

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

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

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

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

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

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

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

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!

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

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.