Cenzic 232 Patent
Paid Advertising
web application security lab

Widespread XSS for Google Search Appliance

Well, maluc has done it again; he’s found a cross site scripting hole in Google’s search appliance. For a paltry $2000-30000 people can buy an appliance to search their site. Unfortunately maluc has discovered that if you keep it on your domain your whole domain is at risk of information leakage, session theft, etc…

The hole uses the selected encoding issue I’ve been talking about, but instead of using the US-ASCII encoding issue, he used the UTF-7 hole. Fantastic! He also disclosed a number of vulnerable websites including Stanford, the Food and Drug Administration and the National Institute of Standards and Technology.

This is the problem with adding outside applications onto your trusted domain. If they weren’t on the same domain the problem wouldn’t be nearly as bad from a security and public relations standpoint. Google will probably need to issue a patch to all of it’s customers. I’m not sure if the boxes are managed or not - my guess is not. So this will probably take a while to completely fix on all sites that use it. Expect this one to be around for at least a little while.

4 Responses to “Widespread XSS for Google Search Appliance”

  1. pdp Says:

    quite interesting i must say. this proves that XSS will become a lot more dangerous in the future. The only problem with this kind of vulnerabilities is that they are a bit passive. This is the reason why I believe that non-persistent XSS attacks will remain part of every phisher or social engineer toolkit, but nothing more.

    Yes, there are persistent XSS… not many though. The other thing is to use media formats, rss feeds, web pages that are under control of the attacker. Sure, you cannot get the domain cookies unless the infected content is somehow transported to the desired domain but we need to stop thinking of XSS as a transport mechanism for steeling cookies.

  2. Google Appliance making Sites XSS Vulnerable Says:

    […] Rsnake at hackers is reporting: maluc has discovered that if you keep [Google Sarch Appliance] on your domain your whole domain is at risk of information leakage, session theft, etc…. The hole uses the selected encoding issue I’ve been talking about, but instead of using the US-ASCII encoding issue, he used the UTF-7 hole. Fantastic! He also disclosed a number of vulnerable websites including Stanford, the Food and Drug Administration and the National Institute of Standards and Technology.   […]

  3. Tontonq Says:

    http://www.google.com/search?hl=en&q=Tontonq&oe=utf7

    So u may use utf7 encoding @ google.com but i coudlnt get a good result

  4. maluc Says:

    yeah, as i said in the sla.ckers post.. google.com uses the same API/script but it filters dangerous characters before converting to UTF-7 as opposed to afterwards. that also means that all + get changed to +- which prevents any use of UTF-7. basically, the exact solution their Search Appliance should use.