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] [day] [month] [year] [list]
Message-ID: <44AC98C1.3050609@securax.org>
Date: Thu, 06 Jul 2006 07:59:45 +0300
From: Javor Ninov <drfrancky@...urax.org>
To: RSnake <rsnake@...cking.com>
Cc: full-disclosure@...ts.grok.org.uk, websecurity@...appsec.org,
	bugtraq@...urityfocus.com, webappsec@...urityfocus.com,
	bugtraq@...security.net
Subject: Re: Re: [WEB SECURITY] Cross Site Scripting in
	Google



RSnake wrote:
> 
> 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.
> 
my opinion is that full disclosure is not for vendors .. it's for users.
full disclosure is for us to know how to react on certain threads. i
personally don't care about the vendors , although my company is a
vendor itself . we also produce software and we also care about security
of our software. but i expect users to post to security groups instead
of mailing me personally. If the vendor cares about his users he should
watch the security groups.

I believe in FULL disclosure
And i think this is the better way.

--
Javor Ninov aka DrFrancky
securitydot.net

> 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
> 
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/


Download attachment "signature.asc" of type "application/pgp-signature" (190 bytes)

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ