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."
It's considered good practice to report security issues to the responsible parties in order to give them sufficient time to fix the problem well before disclosing it to the public .
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
Maybe you should have read TFA. It was fixed some time ago.
Did you RTFA?
A known issue is better then an unknown issue. With a known issue people will be more aware and be less likly to fall victum.
Reality is a big nasty dragon. Fortunately I don't believe in dragons.
Does anyone have the real post that hasn't been mangled by the mailing list? What are these characters that they used? Does anyone have a working exploit of this type (encoded xss) on another site?
-- these are only opinions and they might not be mine.
And then what happens to AJAX?
JavaScript is not the issue; the issue is sites/providers not treating data from the "real world" as suspect and doing a rigorous examination of it before allowing it in or executing anything based on it. When I'm writing Perl CGIs that are accessible from outside my system, I always have the taint mode (-T) switch enabled. You have to be suspicious of data coming in and treat it as radioactive until you can verify its integrity.
GetOuttaMySpace - The Anti-Social Network
They can even go to multiple problems at the same time. If this problem were more prevelant, a hacker could craft a page that steals ALL your online logins/cookies/etc from any site that had the problem. They would just need to craft a page with multiple framesets that load up all the vunlerable pages.
XSS is also making news because it's being used by phishers to forge stuff from the target domain. All the anti phishing stuff relies on which domain a link is going to.. but in a sense, XSS allows phishers to put their own page (ie. fake login) on the target domain! It is very much a problem for any site that deals with personal information, or has trusted content.
-- these are only opinions and they might not be mine.
This is great when there is only one site to update. But when everybody is running their own copy of the web app on their web server, you get problems like the recent epidemic of PHP-based bulletin board exploits.
--
"Open source is good." - Steve Jobs
"Open source is evil." - Microsoft
What needs to happen is sites need to use LESS javascript, and shoud degrade gracefully when js is disabled. Unfortunately, with AJAX, it's more common than ever.
-- these are only opinions and they might not be mine.
..... seems to be very good. They acknowledged the problem quickly (the same day if I recall correctly) and fixed it within days. Maybe instead of treating this posting as if there is a bug out there that is a clear and present danger, perhaps we should be talking about how good their response was and why other software companies aren't as responsive?
This is my opinion. To make sure you don't steal it, it's covered by the DMCA.
While it may be one thing to pull apart IE and Windows XP (they can be done remotely, in an unconnected lab, with zero impact to a larger community), where does one acquire the balls to go and tinker with a hugely popular online site like google, where the mere act of investigation -may- impact the operational stability of the site.
Now, I know that XSS is benign but whose to say that there wouldn't be some ping-of-death like characteristic with a bizarre UTF-7 encoding? While it's doubtful that google would have such poor quality in their applications, why does the white-hat security community get carte blanche access to test it out?
I could be bitter because I sent a similar email to google (regarding their gmail login account and the 'continue=' varaiable) in March but never heard a reply. But to google's credit, and my defense, I only indicated that it looked highly suspicious and never took the next step to craft an actual attack and send them the code.
If a security engineer should happen across the logs and start to see a bunch of unusual encodings, or what appears to be a recon of the website's characteristics, what level of forgiveness would be applied if the source of such network activity was from eEye, or Watchfire? And what if it was bankofamerica.com instead of google?
I am all for giving vendors a reasonable amount of time to fix a defect and then provide full disclosure but I'm not keen to keep paying for watchfire (eEye, iss, etc..) to go to school and get free press based on unauthorized accesses to my production systems - where is the balance?
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.
Well, yes, a bug-fix in a web application can be rolled out to a billion users - but so can the original vulnerability. Double-edged sword.
~ Better a freak than a sheep. ~