A bug in IE allows hackers to conduct XSS attacks. The flaw in IE gets a little techie but it is essentially this: the way double quotes are encoded by IE isn’t properly done. This oversight has a significant downstream effect for websites supporting IE (and there’s a lot). Since website developers assume requests from IE are properly done, hackers can sneak XSS attacks into websites.
Here are the technical details. Internet Explorer (IE) doesn’t encode double quote characters (“) in the query part of the uniform resource identifier (URI). This behavior, besides being non standard (as stated by RFC and implemented by other browsers including Chrome or Firefox) may expose IE users to reflected XSS attacks. How? Websites may assume that the URI in the request is properly encoded by the browser and embed it “as is” in the HTML response. Since double quotes are not properly encoded by IE it may break the websites HTML structure and allow an attacker to smuggle an XSS attack against the IE user.
According to RFC 3986 (http://www.ietf.org/rfc/rfc3986.txt) which defines the URI syntax, the proper syntax of the query part of the URI is as follows:
pchar = unreserved / pct-encoded / sub-delims / ":" / "@"
query = *( pchar / "/" / "?" )
pct-encoded = "%" HEXDIG HEXDIG
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
reserved = gen-delims / sub-delims
gen-delims = ":" / "/" / "?" / "#" / "[" / "]" / "@"
sub-delims = "!" / "$" / "&" / "'" / "(" / ")"
/ "*" / "+" / "," / ";" / "="
It’s easy to verify that double quote should be “pct-encoded” and therefore represented as %22.
Furthermore, IE behavior is inconsistent across the different parts of the URL – double quote gets encoded on the “path” part of the URI but not on the “query” part.
For example, typing the following URI in IE’s address bar– ‘http://example.com/Sea”rch.asp?q”=”b“‘ over the wire it will be ‘GET /Sea%22rch.asp?q”=”b” ‘
See the following wireshark screenshot (click to BIGGIFY):
If a website embeds the request’s URI directly into the source of the page, assuming that it was properly encoded by the browser, it would break the HTML.
Consider the following scenario:
A web designer wants to dynamically embed the URL as a parameter in request for an image. The following JSP code implements just that:
out.println(” <Img src=”http://www.example.com/pic.asp?ref=” + request.getRequestURL() + “?” + request.getQueryString() +””>”);
Now the hacker can create a reflected XSS attack by convincing the victim to follow the following link:
hxxp://vulnerablesite.com/vulnerablepage.jsp?”onmouseover=alert(1)//
On IE the victim gets the following HTML
<Img src=”http://www.example.com/pic.asp?ref=hxxp://vulnerablesite.com/vulnerablepage.jsp?”onmouseover=alert(1)//”>
And the event handler is now running a javascript on the victims browser.
When the same URI is accessed with a different browser (Chrome), the request is properly encoded and the script is not smuggled into the request.
<Img src=”http://www.example.com/pic.asp?ref=http://10.1.1.190/decodeTest/showquery2.jsp?%22onmouseover=alert(1)//“>
We have seen such vulnerable applications over the internet – so the threat is very actual and not theoretical.
We have contacted Microsoft and got the following response:
Thank you for writing to us. The behavior you are describing is something that we are aware of and are evaluating for changes in future versions of IE, however it’s not something that we consider to be a security vulnerability that will be addressed in a security update.
We beg to differ. In fact, on XSSed.com (a site for public disclosure of XSS vulnerabilities), the vulnerability’s presence is beginning to be felt. We have seen reported sites that are exposed to XSS attacks on IE users only, due to its encoding bug.
Try Imperva for Free
Protect your business for 30 days on Imperva.
