Slashdot Mirror
Cross Site Scripting Discovered in Google
Security Test writes "Yair Amit posted a message early this morning to The Web Security Mailing List outlining a Cross Site Scripting flaw in Google that allows an attacker to carry out Phishing Attacks."
They've had others in the past, but were quick to fix them. They have even sent t-shirts as thanks for the help. Other sites are not so friendly or fast. This site shows active security holes in various sites that have gone unresolved. (CSS, insecure logins, etc)
-- these are only opinions and they might not be mine.
response was something like: "We will work on it; or we wont - but we wont tell you
Which sucks...
Here we go:
Original:i on=SelectMenu&SMID=EigenesOrderbuch&MenuName=&Init Href=http://www.consti.de/secure
/Fälschung --> Imitation /
https://www.vr-ebanking.de/index.php?RZBK=0280
MY Version (XSS):
https://www.vr-ebanking.de/help;jsessionid=XA?Act
... Hope they change their mind, sometime. :)
Consti / thr0n
The downside is that this only works if the app provider is a proprietary vendor with a closed architecture. If 3rd parties are allowed to create extensions or if users can create their own utilities/add-ons then centralized patching would likely introduce the same types of incompatibilities and breakages that current OS patches can introduce. Worse, centralized control might mean that users have no choice but to live with the patched version.
Two wrongs don't make a right, but three lefts do.
Rather than turn off JavaScript entirely, I use the NoScript extension to turn it off everywhere but on the sites I allow. The only adjustment needed was to turn off the "NoScript has blocked JavaScript" message in the extension options since it occured so frequently.
Ita erat quando hic adveni.
Ob-ISO International Date Format advocation ( 2005-12-01 for the win! :-)
"How common are XSS holes?"
I had to laugh at that one.
Only an XSShole would steal your cookies.
He who knows best knows how little he knows. - Thomas Jefferson
This is reported as a Google.com bug, which is partially true. But this is only one half of the problem. The other half of the problem (mentioned in the full article) is due to a dubious feature in Internet Explorer: when it gets a page without a specified character encoding, it does not rely on default values for the encoding (which should be iso-8859-1 for HTML or UTF-8 for XHTML).
Instead, Internet Exploerer tries to guess the encoding of the contents by looking at the first 4096 bytes of the page and checking the non-ASCII characters. In the case of the cross-site scripting attack decribed here, the problem is that IE would silently set the encoding of a page to UTF-7 in case some characters in the first 4096 bytes looked like UTF-7. This silent conversion to UTF-7 by Internet Explorer in a text that Google assumed to use the default encoding allowed the attackers to bypass the way Google was filtering "dangerous" characters in some URLs.
The article puts the full blame for the vulnerability on Google.com. I think that a part of the blame should also be shared by the Internet Explorer designers (and any other browser that does unexpected things while trying to guess what the user "really meant").
Stardate 481.23.587 for the extra credit
1) Your analysis is based on bad assumptions so your result is way off. 2) You're a sick bastard for fucking a horse.
It seems odd to blame this on Google. According to the linked mailing list posting, the problem is caused by the "auto detect character set" feature in IE (and probably other browsers,) and the lack of a "charset" parameter in the HTTP response from Google. The HTTP spec is pretty clear that a missing charset parameter means ISO-8859-1, not "browser should guess", and certainly not UTF-7.
So isn't it really the "auto detect" feature in the browser that causes the vulnerability, and not Google's lack of "charset encoding enforcement" as the mailing list posting from Watchfire Research claims? Let's put the blame where it belongs. I say we should applaud Google for going the extra kilometer to protect users with non-compliant browsers.