HTTP/1.1 200 OK
”¦
Set-Cookie: _de=a\r\n\r\n
<script>alert(/XSS/);</script>; domain=.xiaonei.com; expires=xxxx
Set-Cookie: login_email=null; domain=.xiaonei.com; path=/; expires=xxx
Content-Type: text/html;charset=UTF-8
Connection: close

Please note the boldfaced section. If you have some programming background, you would know that “\r” is a carriage return (ASCII code 0x0d) and “\n” is a line feed (ASCII code 0x0a). An attacker can input %0d%0a%0d%0a in a URL. If a web application does not filter %0d%0a%0d%0a and outputs them to the HTTP response header, they will be converted to \r\n\r\n as in my boldfaced section above. Although the HTTP response header is an integrated header, it is divided by \r\n\r\n. Because \r\n\r\n represents the end of the HTTP response header, the content after it will be handled by the web browser as the content of a web page, and the attacker’s JavaScript code will run. This is an old attack method, but it can still be found in websites today.

The %0d%0a problem can also allow exploits in other situations. For example, it can be used to divide the T-SQL in SQL-injection attacks such as “select * from testable%0d%0aexec xp_cmdshell ‘command.’ ” It also can be used to make commented code run. For example, if you have this code in a web page:

<script>
// alert($_GET["var"]);
</script>

The alert line has been commented. But when an attacker provides this to it:

var=%0d%0aalert(‘xss’);

the code will become this:

<script>
// alert(\r\n
alert(‘xss’);
</script>

And an XSS attack has been created.

So web programmers: Don’t forget to filter %0d%0a in your code.

I have some advice for how you can protect yourselves from this new threat. For Firefox users, I suggest the latest version of the NoScript add-on for Firefox 3. You can find it here. For IE users, unfortunately, I haven’t found a patch. But I can recommend a good article that talks about clickjacking in multiple web browsers. You’ll find advice on what you can do with IE, Safari, Chrome, and Opera. Some web browsers allow users to disable the IFRAME element, but that will affect normal functions because some sites use IFRAME. You’ll need to take care if you are not using Firefox and NoScript.

Lately, the topic of “clickjacking” has gained popularity in discussions on the Internet. It is a new type of web attack. I decided to find out what it’s all about.

I found an online video from OWASP NYC AppSec 2008 here. In the video, Jeremiah Grossman and Robert “RSnake” Hansen reported this new vulnerability in a presentation titled “New Zero-Day Browser Exploits-–ClickJacking.” I also found a demo of this attack here.

In the videos they describe only parts of the vulnerability, but we can learn enough to gain a basic idea of what clickjacking is.

To explain, I’ll use an example. You have a web page A controlled by an attacker. A contains an IFRAME element B. In a clickjack attack, B would be set to transparent and the z-index property of the layer set to higher than other elements of page A via cross-site scripting. The area of B will also need to be so big that the user can easily click its content. The attacker places a button in B that leads to any action he wants. Then the attacker places some buttons on page A that will attract users. The location of the buttons in B must match the buttons in A so when users appear to click a button on page A, they are actually clicking the button in B because the z-index property of B’s buttons are higher than A’s buttons. This attack uses DHTML and does not require JavaScript, so disabling JavaScript will not help.

This vulnerability affects multiple web browsers. Unfortunately, no patch for it is currently available, so users should be careful. The vulnerability has also been found to affect Adobe Flash Player, the most popular rich-media Internet application today. Adobe has released a security advisory and provided a workaround.

We will continue to watch for new information about this vulnerability.