Interesting that it's *not* choosing a tld different to ".com" what
triggers the bug, but rather the language field ("hl").

In other words, if we change
[http://www.google.ae/search?hl=ar&q=<script>alert("1")</script>&meta=]
to [http://www.google.com/search?hl=ar&q=<script>alert("1")</script>&meta=]

the bug *still* works, but it *stops* working when you change the
language to English for instance:
[http://www.google.com/search?hl=en&q=<script>alert("1")</script>&meta=]

Very nice observation. Good reminder that sometimes you don't need to
go fancy using different encodings and so on. Sometimes, changing a
simple field value can make a difference (such as in this case). Many
people have tried really hard to find XSS bugs in the main English
version of the Google search page (there are several examples that
went public), but this guy was much smarter and tried something
different (changing the language parameter in this case).

Good post!

On 4/10/06, Andy Meyers <andy.meyers (at) hushmail (dot) com [email concealed]> wrote:
> My BlackICE stops this from XSS from happening, however changing the URL
> from a .ae domain to a .com and leaving the rest in tact, I am then
> prompted.
>
> http://www.google.com/search?hl=ar&q=<script>alert("1")</script>&meta=
>
> Ashes
>
> -----Original Message-----
> From: almfnod (at) gawab (dot) com [email concealed] [mailto:almfnod (at) gawab (dot) com [email concealed]]
> Sent: Tuesday, April 04, 2006 2:35 PM
> To: bugtraq (at) securityfocus (dot) com [email concealed]
> Subject: google xss
>
> http://www.google.ae/search?hl=ar&q=<script>alert("1")</script>&meta=
>
>
>
>

[ reply ]