full-disclosure - Re: [WEB SECURITY] Cross Site Scripting in Google

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Wed Jul  5 18:59:37 2006
From: rsnake at shocking.com (RSnake)
Subject: Re: [WEB SECURITY] Cross Site Scripting in Google

Just for the record, I should clarify. Google was not notified of this
exploit prior to full disclosure. As I said, they are notoriously slow
(or completely delinquent) in fixing these issues historically. If you
need proof click here to see four redirect issues disclosed nearly 6
months ago that are still not fixed.

http://seclists.org/lists/webappsec/2006/Jan-Mar/0066.html

Here's another one:

http://www.google.com/url?sa=D&q=http://www.fthe.net

Typically I don't believe in full disclosure as a release methodology
(for instance, if I found a remote vulnerability in Microsoft, I
wouldn't disclose that without giving Microsoft months to release a
patch as they have taken their patching process very seriously as of
late and their responsibility in this matter has been far improved).
Either Google was not convinced when they were used as a phishing relay
last time, or they do not take this seriously.  Either way, it takes all
but a few days to patch these issues in a website, QA them and releast
them, and Google has not done so, making contacting the vendor a useless
excersize to date, in my opinion.

On Wed, 5 Jul 2006, bugtraq@...security.net wrote:

> Did you even bother to email them and let them know? Being that they're still vulnerable probably not....
>
> - z
>
>>
>>
>> Google is vulnerable to cross site scripting attacks.  I found a
>> function built off their add RSS feed function that returns HTML if a
>> valid feed is found.  It is intended as an AJAXy (dynamic JavaScript
>> anyway) call from an inline function and the page is intended to do
>> sanitation of the function.  However, that's too late, and it returns
>> the HTML as a query string, that is rendered, regardless of the fact
>> that it is simply a JavaScript snippet.
>>
>> Here is the post that explains the whole thing:
>>
>> http://ha.ckers.org/blog/20060704/cross-site-scripting-vulnerability-in-google/
>>
>>
>> -RSnake
>> http://ha.ckers.org/
>> http://ha.ckers.org/xss.html
>> http://ha.ckers.org/blog/feed/
>>
>> ----------------------------------------------------------------------------
>> The Web Security Mailing List:
>> http://www.webappsec.org/lists/websecurity/
>>
>> The Web Security Mailing List Archives:
>> http://www.webappsec.org/lists/websecurity/archive/
>> http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
>>
>
>
> -------------------------------------------------------------------------
> Sponsored by: Watchfire
>
> Securing a web application goes far beyond testing the application using
> manual processes, or by using automated systems and tools. Watchfire's
> "Web Application Security: Automated Scanning or Manual Penetration
> Testing?" whitepaper examines a few vulnerability detection methods -
> specifically comparing and contrasting manual penetration testing with
> automated scanning tools. Download it today!
>
> https://www.watchfire.com/securearea/whitepapers.aspx?id=701500000008Vmm
> --------------------------------------------------------------------------
>

-R