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."
Get off my launchpad!
Although the article details an interesting exploit, Google fixed this on the 1st of this month--The title is somewhat misleading. It is useful to know that Google fixed this vulnerability 2 weeks after it was discovered, on November 15th.
Also, for those of us unaccustomed to DD/MM/YYYY date format, that's the format of all dates in the article.
Grammar Lesson: you're is a contraction of "you are"; your means you possess something; yore means days gone by.
From the message:
--[ Discovery Date: 15/11/2005
--[ Initial Vendor Response: 15/11/2005
--[ Issue solved: 01/12/2005
Message posted: 21/12/2005
They did give them a chance to fix it first.
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
If there ever was an endorsement for web-based applications, this is it. When a bug is fixed in Windows or Linux, it stays active in the wild for months or years because many users don't update. With web apps the user basically gets an "update" each time they visit the site. If Google fixed the problem on December 1, the vulnerability could have been announced the same day without any kind of negative impact.
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.
I'm always blown away by how the Internet security market works and self-correct itself without any regulation.
A major web site has a flaw. White hat and black hat "hackers" find that flaw, exploit it, and either abuse it or let the web site know about it. The web programmers go in and close the exploit because it affects how their customers use the service and could open them up to some liability.
This is the way the free market works. I'm a huge fan of how quickly the Internet (anthropomorphically) adapts to the changing needs of the billion of users. Some exploits that aren't fixed by the owners of code are fixed by third parties -- sometimes for profit and sometimes for free. Before we can even write one law to attempt to solve problems, others are already attacking the problems.
I'd like to see it stay this way. Every time we move forward to create legislation to protect the end user (see CAN-SPAM and a myriad of other laws), we see failure time and again. The loopholes in the laws make them irrelevant quickly, and all we get out of that is wasted money and wasted time.
Let the growth and expansion occur freely. We'll see some bad times (new viruses and new spam exploits) but we'll see those fixed in short order. If they don't get fixed, why is the Internet still chugging along and growing every day?
"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
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
Someone is trying to get their Pagerank up by submitting the story with a name of "Security Test" and linking to their shoddy website. The site has only a few links, no content, and it says the page is for sale. Will slashdot ever get their shit together and stop posting submissions with blatent pagerank-whoring links like this?
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").
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.
I've found dozens of XSS problems on sites, and have made news for one on Citibank. I've only received a few threatening legal letters from companies.
-- these are only opinions and they might not be mine.
Sounds like preloading.
Firefox (and other Mozilla derivatives) support a preloading link. When they encounter such a link in one page, they begin downloading the content for the linked page, so they have it ready. Google assumes that you're reasonably likely to click on the first link they've sent you for some types of search result (probably where there's a very high search ranking for one particular site for the term you searched for), so sends Mozilla/firefox users a preload warning along with the search result page, with the URL of the first search result page. Firefox does its thing and starts downloading the page content for the first search result before you even click on it - including any cookies.