|
|
Recently, xiaonei.com (a Chinese social-networking site, similar to Facebook) fixed a cross-site scripting (XSS) vulnerability known as “HTTP Response Splitting.” This flaw occurs when a web application does not properly filter carriage returns and linefeeds (%0d%0a). This allows an attacker to split the HTTP response header like so:
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.
|
|
Very nice, Zhu.
So how do we align your (Avert Labs) common sense approach to filtering for an easily preventable web app vuln with the McAfee Secure service?
After all, there are dozens, if not hundreds, of websites that continuously display the McAfee Secure trustmark that suffer from this flaw, or others similar to it.
Submit your own comments / message for this post