Blog|Login|中文Deutsche日本語
January 16, 2012
 IE Bug Exposes Users to XSS Attacks
Pin It

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): 

Wireshark

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.

 


Comments

This issue can be solved by either of the following:
• Deploy a custom encoding to queries originating from IE ,based on the user agent string. However, writing a custom server-side code may defeat the original purpose of using CMS system such as ColdFusion.
• Deploying a WAF that properly that knows how to handle such web peculiarities including this IE bug encoding. That way you don’t need to make any changes to your application.

Hi, we are facing the same issue in one of our ColdFusion pages. I am even facing this issue on IE10. Can you suggest any workaround we can implement to overcome this issue????

Verify your Comment

Previewing your Comment

This is only a preview. Your comment has not yet been posted.

Working...
Your comment could not be posted. Error type:
Your comment has been saved. Comments are moderated and will not appear until approved by the author. Post another comment

The letters and numbers you entered did not match the image. Please try again.

As a final step before posting your comment, enter the letters and numbers you see in the image below. This prevents automated programs from posting comments.

Having trouble reading this image? View an alternate.

Working...

Post a comment

Comments are moderated, and will not appear until the author has approved them.

« Davos and Hacking | Main | Oracle’s Q1 CPU Release »

Find Us Online
RSS Feed - Subscribe Twitter Facebook iTunes LinkedIn YouTube
Authors
Monthly Archives
Email Subscription
Sign up here to receive our blog: