I’ve reported an interesting Cross-Site Scripting flaw on the official website of ICQ, the world’s probably best known and most used Cross-Platform Messaging application to the developers in February. This flaw potentially allowed an attacker to steal the cookies from authenticated users, which could lead to account hijacking in the end.
The coordination process was a bit messy at the beginning, because I had to explain the issue and the consequences multiple times to many different people of the official support (well,at least, it felt like this). It took some time but the issue has been finally forwarded to the administration of the project and is now fixed. Nothing else matters 🙂
But what’s so special about a Referer-based XSS flaw? Some may ask how a Referer – based XSS attack can be successful if you’re not able to modify the Referer on the target page itself. Answer: You don’t need to. All you have to do is to trick your victim to visit another page you control!
Take a look at the following example:
<form method="GET" action="http://www.vulnerable.com/">
<input type="submit" value="Exploit">
These few lines will do the trick. The attacker only needs to place this in a .html file on a webserver he controls and then tricks the victim (via some awesome social engineering methods) to visit a random URL which includes the XSS payload like:
Clicking on the Submit button will issue a GET request to the site www.vulnerable.com with the HTTP Referer field set to the URL which includes the fancyhacker – payload! This is what GET simply does. Ofc, this can also be automated to issue the request silently without user interaction too.
There’s also one limitation: This attack scenario only works using the Internet Explorer (bad boy) on all versions up to v10, but not using Chrome or Firefox (good boys) because they encode the bad payload chars :-).