Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Cross Site Scripting Discovered in Google

CmdrTaco posted more than 8 years ago | from the hate-when-that-happens dept.

Google 158

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."

Sorry! There are no comments related to the filter you selected.

but this was resolved three weeks ago. (4, Informative)

Artifex (18308) | more than 8 years ago | (#14309026)

From TFA:
-[ Solution

Google solved the aforementioned issues at 01/12/2005, by using=20
character encoding enforcement.

--[ Acknowledgement

The author would like to commend the Google Security Team for their=20
cooperation and communication regarding this vulnerability.

Re:but this was resolved three weeks ago. (0, Redundant)

op12 (830015) | more than 8 years ago | (#14309043)

More like 11 months ago! </american> :)

Re:but this was resolved three weeks ago. (0)

Anonymous Coward | more than 8 years ago | (#14309228)

No kidding. Europeans and their 12-day-long 31-month years...Sheesh!

Re:but this was resolved three weeks ago. (0, Troll)

Nutria (679911) | more than 8 years ago | (#14309468)

Europeans and their 12-day-long 31-month years...Sheesh!

Dammit! They should be more like Us!

Re:but this was resolved three weeks ago. (0)

Anonymous Coward | more than 8 years ago | (#14310159)

Then who would we take the piss out of?

Re:but this was resolved three weeks ago. (4, Insightful)

mwvdlee (775178) | more than 8 years ago | (#14309044)

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 .

Re:but this was resolved three weeks ago. (0)

Artifex (18308) | more than 8 years ago | (#14309078)

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 .


Yes, I know. I was referring to the use of the word "allows" in the description. :)

Re:but this was resolved three weeks ago. (0)

Anonymous Coward | more than 8 years ago | (#14309385)

With the exception of companies that are on the "Evil List".

Re:but this was resolved three weeks ago. (3, Informative)

Pinky3 (22411) | more than 8 years ago | (#14309139)

"Google solved the aforementioned issues at 01/12/2005, by using
character encoding enforcement."

12/01/2005 for those in the US.

Re:but this was resolved three weeks ago. (5, Funny)

@madeus (24818) | more than 8 years ago | (#14309231)

Ob-ISO International Date Format advocation ( 2005-12-01 for the win! :-)

Re:but this was resolved three weeks ago. (1)

araemo (603185) | more than 8 years ago | (#14309551)

I prefer 01-12-2005 for logfile names, so in a directory list, they appear by date even when sorting by name.

Not a requirement, to be sure, but it sure is convenient.

Re:but this was resolved three weeks ago. (4, Informative)

Artifex (18308) | more than 8 years ago | (#14309604)

I prefer 01-12-2005 for logfile names, so in a directory list, they appear by date even when sorting by name.

Unless you cross a year in your directory, like logs going from September, 2004, to August, 2005. :) I've found YYYY-MM-DD to be the easiest way to ensure chronological consistency.

Re:but this was resolved three weeks ago. (5, Funny)

Flunitrazepam (664690) | more than 8 years ago | (#14309570)

Stardate 481.23.587 for the extra credit

Re:but this was resolved three weeks ago. (1)

Kiaser Zohsay (20134) | more than 8 years ago | (#14309428)

"Google solved the aforementioned issues at 01/12/2005, by using
character encoding enforcement."

12/01/2005 for those in the US.


This is why since high school I have used alpha abbrevs for the month when I write dates, like Dec 21, 2005, even when filing in forms that have pre-printed slashes.

Re:but this was resolved three weeks ago. (1)

darkmeridian (119044) | more than 8 years ago | (#14309158)

Gee. They bought AOL today and they already had an insecurity? Quick workers, those Google Engineers.

Re:but this was resolved three weeks ago. (-1)

Anonymous Coward | more than 8 years ago | (#14309609)

Baahaaa!

that was dumb.

Could have been announced 3 weeks ago too. (4, Interesting)

kawika (87069) | more than 8 years ago | (#14309167)

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.

Re:Could have been announced 3 weeks ago too. (1)

mobiux (118006) | more than 8 years ago | (#14309362)

This is one of the reason I love terminal services on Windows.
Have to patch 20 servers over the course of a week instead of patching 400 client PC's over the course of a year.

Re:Could have been announced 3 weeks ago too. (0)

Anonymous Coward | more than 8 years ago | (#14309476)

400 over a year? Jeez. What company has you as a slow ass admin? A dead squirrel would move faster than you.

Re:Could have been announced 3 weeks ago too. (4, Insightful)

b1t r0t (216468) | more than 8 years ago | (#14309426)

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.

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.

Web Services (1)

PerlPenguin (802434) | more than 8 years ago | (#14309757)

Agree with the grandparent, but still an interesting point. This aspect is probably the most pertinent topic related to this story. You could say this makes a case not simply for web-apps but for centrally hosted web services and APIs. (Like the Google Maps API, for example)

Re:Could have been announced 3 weeks ago too. (2, Insightful)

wraith0x29a (565168) | more than 8 years ago | (#14310017)

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.

Re:Could have been announced 3 weeks ago too. (1)

Chmarr (18662) | more than 8 years ago | (#14310065)

Ummm.... this isn't a double edged sword at all.

Bug in a web application? Millions of users are exposed to the bug until a patch is released.
Bug in a locally run application? Millions of users are exposed to the bug until a patch is released.

Where's the difference here?

Re:Could have been announced 3 weeks ago too. (2)

Whafro (193881) | more than 8 years ago | (#14310138)

The difference is that you didn't include everything necessary here... it should be:

Bug in a web application? Millions of users are exposed to the bug until a patch is released.
Bug in a locally run application? Millions of users are exposed to the bug until a patch is released and they hear about it and they actually apply it.

Re:but this was resolved three weeks ago. (0, Redundant)

minus_273 (174041) | more than 8 years ago | (#14309222)

" Google solved the aforementioned issues at 01/12/2005, by using=20
character encoding enforcement"

actaully, it looks like it was resolved almost ayear ago. Why is this even news? are we going to post old MS bug reports now?

Re:but this was resolved three weeks ago. (0)

VJ42 (860241) | more than 8 years ago | (#14309333)

It's using the date format dd/mm/yyyy, not the American mm/dd/yyyy

Re:but this was resolved three weeks ago. (1)

Nutria (679911) | more than 8 years ago | (#14309449)

It's using the date format dd/mm/yyyy

Which is very similar to the OpenVMS and Eeeeevil American Military
dd-aaa-yyyy format.

Re:but this was resolved three weeks ago. (0)

Anonymous Coward | more than 8 years ago | (#14309357)

what's =20 character encoding enforcement? sounds like some tough new encryption or something? is =20 cooperation like when you work with someone using this =20charencenf thing in your comms?

Re:but this was resolved three weeks ago. (1)

Ashley Bowers (932552) | more than 8 years ago | (#14309851)

I read this was fixed about a month ago to. Read that another Google hack was just discovered via the O"Reiley network that allows workers to view websites banned by company computers using the langauges tanslator!

FRISTY PSOT!!!! (-1, Troll)

Anonymous Coward | more than 8 years ago | (#14309033)

FRISTY PSOT!!!! Micro$o$$ can't buy one of theze for they're $-box!!!!!

Re:FRISTY PSOT!!!! (0, Flamebait)

_EternaL_ (99362) | more than 8 years ago | (#14309685)

retard

Re:FRISTY PSOT!!!! (0)

Anonymous Coward | more than 8 years ago | (#14309764)

> retard

Or shall we say tarded again?

Hmm (-1, Redundant)

omeg (907329) | more than 8 years ago | (#14309041)

Shouldn't they have waited for Google to create a fix for it before outlining this bug?

Re:Hmm (1, Insightful)

Bwian_of_Nazareth (827437) | more than 8 years ago | (#14309046)

Maybe you should have read TFA. It was fixed some time ago.

Re:Hmm (1, Insightful)

Malc (1751) | more than 8 years ago | (#14309051)

Did you RTFA?

Re:Hmm (0)

Anonymous Coward | more than 8 years ago | (#14309114)

How is this insightful? Someone please tell me?

Re:Hmm (4, Informative)

op12 (830015) | more than 8 years ago | (#14309073)

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.

Re:Hmm (3, Insightful)

Ostien (893052) | more than 8 years ago | (#14309081)

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.

Re:Hmm (0)

Anonymous Coward | more than 8 years ago | (#14309285)

You must be new here.

Re:Hmm (0)

Anonymous Coward | more than 8 years ago | (#14310152)

the problem with irony is that it is often too subtle.

Fixed (-1, Redundant)

Anonymous Coward | more than 8 years ago | (#14309048)

--[ Discovery Date: 15/11/2005

      --[ Initial Vendor Response: 15/11/2005

      --[ Issue solved: 01/12/2005

As the message says the flaw was fixed in 1/12.

It's been fixed (4, Informative)

b4k3d b34nz (900066) | more than 8 years ago | (#14309061)

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.

Re:It's been fixed (0)

Anonymous Coward | more than 8 years ago | (#14309456)

I hate that date format --- at least yyyymmdd is sortable.
Don't get me started on mmddyyyy

Re:It's been fixed (1, Funny)

Midnight Thunder (17205) | more than 8 years ago | (#14309501)

I think proponents of mmddyyyy would love my mm:hh:ss format ;)

Re:It's been fixed (2, Funny)

Hawke666 (260367) | more than 8 years ago | (#14310195)

and the proponents of ddmmyyyy would love your ss:mm:hh format. Go ISO!

No real news here (-1, Redundant)

Silver Sloth (770927) | more than 8 years ago | (#14309071)

Apart from mentioning the magic /. buzzword 'Google' - from TFA

Websites from FBI.gov, CNN.com, Time.com, Ebay, Yahoo, Apple computer, Microsoft, Zdnet, Wired, and Newsbytes have all had one form or another of XSS bugs.

so Google getting one is not exactly a major ocurrence. TFA also mentions

The author would like to commend the Google Security Team for their=20
cooperation and communication regarding this vulnerability.


So we can expect the hole to be repaired real soon now (and probaly quicker than our friends from Seattle!)

Re:No real news here (0)

Albio (854216) | more than 8 years ago | (#14309140)

It's already been fixed!

Others.. (5, Informative)

slashkitty (21637) | more than 8 years ago | (#14309074)

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 [devitry.com] in various sites that have gone unresolved. (CSS, insecure logins, etc)

It show a strength of webbased applications (1)

jurt1235 (834677) | more than 8 years ago | (#14309368)

By fixing this bug, everybody is save from it. No one needs to keep their software up to date, great!

Re:Others.. (2, Informative)

openSoar (89599) | more than 8 years ago | (#14309539)

Not long after GMail was launched I inadvertently discovered a serious issue they had with some over-aggressive caching - sometimes when people in the same office as me logged onto their Gmail accounts they would see my Inbox - quite worrying, although they weren't able to actually open any of the messages.

I spent quite some time explaining things to the GMail devs but no freebies for me..

Javascript is a security problem? (2, Informative)

Anonymous Coward | more than 8 years ago | (#14309086)

Noooo, say it ain't so, Who'd 'a thunk it?

I turned javascript off in 1999, just one less glaring security issue for me to address. Before anyone starts talking smack about responsive web apps, just remind me what Ed Felton said about flying pigs.

That's right, disable js and fix the web!

Re:Javascript is a security problem? (5, Informative)

tuffy (10202) | more than 8 years ago | (#14309193)

Rather than turn off JavaScript entirely, I use the NoScript extension [noscript.net] 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.

Re:Javascript is a security problem? (2, Insightful)

slashkitty (21637) | more than 8 years ago | (#14309469)

Uhm, yeah, that is still a problem though. Have you allowed Google.com? have you allowed other sites that you trust, but still may have XSS problems? When the script is executed, it's done so under the google.com domain. This is the main problem w/ xss.

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.

Re:Javascript is a security problem? (1, Funny)

joelsanda (619660) | more than 8 years ago | (#14309194)

That's right, disable js and fix the web!

Gosh, you make it sound like the Web started as a text content medium or something!

Re:Javascript is a security problem? (1)

ninja_assault_kitten (883141) | more than 8 years ago | (#14309244)

Actually javascript isn't the source of the security issue, improper data sanitization was.

Re:Javascript is a security problem? (4, Insightful)

Billosaur (927319) | more than 8 years ago | (#14309302)

That's right, disable js and fix the web!

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.

Re:Javascript is a security problem? (1)

TobiasSodergren (470677) | more than 8 years ago | (#14309567)

Yes indeed!
All this radioactive data is why my server is encapsulated in lead and buried in solid rock. Step 2 is to convert the radioactivity into current and make a self-contained UPS.

Re:Javascript is a security problem? (1)

Midnight Thunder (17205) | more than 8 years ago | (#14309594)

I must admit I used to be in that camp, until I realised that JS does have uses. The problem is not so much JS itself as it being used for the wrong reasons. If it blocks accessability then it is being used in the wrong way. If something cool feature is added, but the important stuff is still visible and navigable without JS active then it is being used well.

It should be noted while Google uses a lot of JavaScript, all the services, that I have used to far, are accessible with it turned off. Take a look at Google Maps without JS activated and you will notice that while you can't drag the page around you can still view the maps.

XSS in my banks website (5, Informative)

thr0n (835565) | more than 8 years ago | (#14309151)

I told them about the XSS (CSS) security holes 2 months ago -
response was something like: "We will work on it; or we wont - but we wont tell you ;)".
Which sucks...

Here we go:

Original:
https://www.vr-ebanking.de/index.php?RZBK=0280 [vr-ebanking.de]
MY Version (XSS):
https://www.vr-ebanking.de/help;jsessionid=XA?Acti on=SelectMenu&SMID=EigenesOrderbuch&MenuName=&Init Href=http://www.consti.de/secure [vr-ebanking.de]
/Fälschung --> Imitation /

... Hope they change their mind, sometime. :)

Consti / thr0n

Re:XSS in my banks website (1)

Solra Bizna (716281) | more than 8 years ago | (#14309700)

Blast. My mod points expired a few seconds before I tried to mod this up.

-:sigma.SB

What bullshit... (3, Interesting)

ninja_assault_kitten (883141) | more than 8 years ago | (#14309160)

Now we're going to start posting every freaking XSS we find? This is a VERY low impact XSS vul. Hell it's not even persistent. Who freaking cares? Are we going to post the slew of recent Yahoo XSS bugs too? WHat about the bug in Google Analytics which allowed you to iterate through all the customer domains?

Re:What bullshit... (1)

slashkitty (21637) | more than 8 years ago | (#14309245)

do you know of any xss bugs in yahoo?

Re:What bullshit... (1)

ninja_assault_kitten (883141) | more than 8 years ago | (#14309965)

bzzzt. (1)

slashkitty (21637) | more than 8 years ago | (#14310019)

none of those qualify as XSS. The javascript in the first example must be entered by the USER, it can't be done by a third party. While they should filter this input, it's not a security hole. Allowing yourself to run JS on any site in your own browser is not a security hole (in fact, it's easy to do). It's only a problem when it can be done by someone else.

Re:What bullshit... - Are you out of your mind??? (1)

jonnyfairplay (940502) | more than 8 years ago | (#14309257)

This XSS problem is serious because Google cookies persist for about 2 weeks. You should think a bit before posting bullshit!

Re:What bullshit... - Are you out of your mind??? (1, Troll)

ninja_assault_kitten (883141) | more than 8 years ago | (#14309301)

I have and it's not serious. At best it's a medium risk. It's not like you can exploit the XSS vul without any user intervention. You still have to get the user to go to the malicious URL. That immediately says to me, 'not serious'. But I guess you're down with infosec marketing propaganda.

Do you work for Watchfire by chance?

Re:What bullshit... - Are you out of your mind??? (2, Insightful)

slashkitty (21637) | more than 8 years ago | (#14309407)

It's easy to force a user to go to a url. If you go to a website, they can include a frame and load the the error.

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.

Re:What bullshit... - Are you out of your mind??? (1)

ninja_assault_kitten (883141) | more than 8 years ago | (#14309940)

I'm not saying it's a technical challenge. I'm saying that the impact is dramatically reduced by having to take that step verus something like an XSS vul in the GMail interface which could be exploited by a malicious email.

Re:What bullshit... - Are you out of your mind??? (1)

jonnyfairplay (940502) | more than 8 years ago | (#14309505)

Web applications are like wicker furniture and fat women - meant to be broken by Jonny Fairplay!

I don't work at all dude!

Re:What bullshit... (0)

Anonymous Coward | more than 8 years ago | (#14309321)

you won't be posting shxt, if you don't like it don't read :P

Re:What bullshit... (1)

ninja_assault_kitten (883141) | more than 8 years ago | (#14309328)

How can you know if you don't like it if you haven't read it? By the time you know, it's too late.

Re:What bullshit... (1)

Sheepdot (211478) | more than 8 years ago | (#14309430)

I have to agree with parent here. This is a low impact vuln that was already fixed.

From the disclosure:

Therefore, when sending an XSS attack payload, encoded in UTF-7, the payload will return in the response without being altered.

For the attack to succeed (script execution), the victim's browser should treat the XSS payload as UTF-7.


This is a complicated vulnerability to have exploited in practice, but now that it has been mentioned, it makes me wonder just how many other encoded XSS vulns could be done with UTF-7 assuming the user's had the ability to get the victims to obtain the pages in that format.

You FaiL It (-1, Troll)

Anonymous Coward | more than 8 years ago | (#14309162)

to thE original

Advantage of online applications (5, Interesting)

G4from128k (686170) | more than 8 years ago | (#14309188)

This example illustrates the advantages of web applications. Google was able to patch the flaw and roll it out to 100% of the user base in a short time period. Providing applications online means centralized version control and patching -- there's no waiting for all the users to patch.


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.

Re:Advantage of online applications (0)

Anonymous Coward | more than 8 years ago | (#14309378)

So just make your desktop applications automagically redownload and install themselves whenever the user runs it and check periodically for new releases during runtime.

This is a benefit of automated patching systems. Not of web apps. You zealot.

This is amazing. (4, Interesting)

dada21 (163177) | more than 8 years ago | (#14309201)

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?

Re:This is amazing. (1)

elpapacito (119485) | more than 8 years ago | (#14309836)

Yeah you're blown away, without any doubt.

Market doesn't work, market doesn't eat, market doesn't do crap except market exist only as an abstact entity, a theoretical construct.

Techies, geeks, hackers, whatever label .. it is knowledgable skilled people that do the fixing !
Some of them are motivated primarily by money and secondarily by showing the company they're good at
resolving upcoming problem...in hope somebody will notice when it's firing time again..but it's just daydreaming. Others, a minority, do the fixing for fixing shake..because they like to see tight well working system and like to work on them.

Also free market theory wouldn't allow an entity such as Google to exist but for a very short amount of time as competitors would enter google market to compensate and get a cut of Google extraprofits. As a matter of FACT and not theoretical model this hasn't happened yet (and google wasn't invented yesterday) neither is it going to happen quickly as there are some strong barriers to entry in this market.

So please don't give the freemarket bullcrap credit when credit is due to WORKERS, techies who are those who sustain most if not all of the competition stress and problems, yet receive dimes and see their future more uncertain then it ever was.

Certainly Google staff is to be praised for quickfixing potentially serious problems

Encoded post.. (1, Insightful)

slashkitty (21637) | more than 8 years ago | (#14309279)

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?

Re:Encoded post.. (1, Informative)

Anonymous Coward | more than 8 years ago | (#14309649)

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?

I think that the authors of the report did the responsible thing in informing Google first, waiting until the problem was fixed (within a reasonable amount of time) and then describing the vulnerability without providing an exploit.

The message gives enough clues about how to create an exploit, though. You just have to know a bit about the UTF-7 encoding. Hint: this is not the same as UTF-8 or iso-8859-1. Once you know that, think about how one could fool a filter that is trying to remove "dangerous" characters from a text, knowing that the filter expects these characters to be encoded in iso-8859-1, while they are interpreted by the browser as UTF-7. Second hint: think about how a single character is encoded in multiple characters and how the bit shifting is done. Your goal in this case would be to encode some text in such a way that the filter expecting the default encoding would only see garbage, while the browser decoding the same text as UTF-7 would see something like "<script ...>". Writing the exploit is left as an exercise to the reader.

MS anyone? (-1, Troll)

CDPatten (907182) | more than 8 years ago | (#14309282)

first screwing the authors/copyright law with google print, next buying aol, and now big security holes.

Is google tring to be evil like MS?

Re:MS anyone? (0)

Anonymous Coward | more than 8 years ago | (#14309651)

How is letting people search through texts of books evil? I say it sounds more like what Gutenburg did with writing, liberate it with the printing press.

And if they want to buy AOL that is their business. Google isn't a charity, they still need to be profitable.

The bigger you are the bigger a target you are for all the shit slingers.

XSSholes! (5, Funny)

digitaldc (879047) | more than 8 years ago | (#14309294)

"How common are XSS holes?"
I had to laugh at that one.

Only an XSShole would steal your cookies.

Re:XSSholes! (0)

Anonymous Coward | more than 8 years ago | (#14309763)

"How common are XSS holes?" I had to laugh at that one.

Only an XSShole would steal your cookies.


About as common as AHoles!

Another Beatles Beatles (4, Informative)

Phosphor3k (542747) | more than 8 years ago | (#14309319)

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?

Cross-Site Scripting for Internet Explorer (5, Interesting)

Anonymous Coward | more than 8 years ago | (#14309352)

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").

Re:Cross-Site Scripting for Internet Explorer (1)

Chmarr (18662) | more than 8 years ago | (#14310137)

I don't think this is a IE-only misfeature. Having a look at the browsers I use:

Camino: Default setting is "Automatically Detect Character Encoding"
Firefox: Default setting is UTF-8
Safari: Doesn't explicitly say, but I just fed UTF-8 into a text file, no encoding, and Safari picked it up. So, I assume that it's default is also 'automatically detect'.

Google is my Bitch (-1, Troll)

Anonymous Coward | more than 8 years ago | (#14309448)

I always suspected. I've been running a project I call Google is My Bitch [damnednice.com] . It shows promising results, and the other major engines are keeping pace, but I've aimed the project toward the uber-secretive GoogleBot engine.

The response by Google..... (2, Insightful)

8127972 (73495) | more than 8 years ago | (#14309499)

..... 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?

Re:The response by Google..... (1)

Packet Pusher (231564) | more than 8 years ago | (#14309568)

Setting a html content type on a web page is hardly a difficult fix

Msn Ebay Paypal and Amazon (0)

Anonymous Coward | more than 8 years ago | (#14309641)

I discovered flaws in all of the above mentioned, that are still unresolved. I actually managed to get a phone call out of amazon but the person on the other end didn't seem to care much.

Most of them were http response splitting attacks, but some others too.

Ive found that google, symantec and cnet have been great companies to help out. They all provided quick responses and even resolved issues as soon as possible in the past with me.

Though, even with the high shopping time right now, ebay and amazon could bother less. Paypal, barely lets you even email a rep without having to go through tons of form filling.

If anyone has any contacts with any of these organization and can possibly get someone to talk to me about them I can be contacted at admin@dbtech.org

Thanks.

How do they find these things . . . legally? (2, Insightful)

chunews (924590) | more than 8 years ago | (#14309642)

IANAL, but I am always amazed at how these security issues are found and resolved since the exploratory phase for white and black hats are, essentially, the same. (I have a similar pet peeve around journalists, who with their hidden cameras, are able to investigate the mysteries of illicit acts without any recompense).

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?

Re:How do they find these things . . . legally? (4, Informative)

slashkitty (21637) | more than 8 years ago | (#14309745)

Well, with XSS, you don't have to "break into" anything to discover the vulnerability. All you do is throw the webservers a few strings and see what they send back.

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.

Cookies (3, Interesting)

kernelfoobar (569784) | more than 8 years ago | (#14309683)

I don't know if it's related, but I've noticed a couple of times that when I get the search result page, I get asked to set a cookie from one of the sites in the results, without clicking on them. (my Firefox is configured to ask me to set cookies.). This is somewhat disturbing, I mean if my FF was set to accept cookies automatically, I would have cookies for sites I have never visited...

Did anyone else notice this?

Re:Cookies (4, Informative)

aziraphale (96251) | more than 8 years ago | (#14309854)

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.

Re:Cookies (1)

kernelfoobar (569784) | more than 8 years ago | (#14310162)

Thanks for the info, sounds interesting. It looks like I'll have to look into this, I'm gonna put a sniffer on this...

Re:Cookies (1)

jcuervo (715139) | more than 8 years ago | (#14309855)

I think it's either Javascript or images in the Adsense ads.

Re:Cookies (1)

kernelfoobar (569784) | more than 8 years ago | (#14310116)

I know it's not the ads because the cookies' domain matches the result links. I don't think is Javascript either.

Google vulnerable? (5, Insightful)

Anonymous Cowhead (95009) | more than 8 years ago | (#14309698)

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.

Re:Google vulnerable? (1)

http101 (522275) | more than 8 years ago | (#14309777)

I'm definitely with you on this one. The browser itself should be blamed for automatically assuming the encoding. It's like IE assumes anyone from Mexico is Italian; sure the languages share common words, but it doesn't make them the makers of spicy sausage, shoes, and Ducati motorcycles.

As for Google going the extra 0.621371192 miles to make sure the end user is protected against this, I do praise them for their efforts. The part in the article that caught my eye was the segment near the bottom showing when this problem was fixed (see below). This is hardly news.
--[ Solution

=20

Google solved the aforementioned issues at 01/12/2005, by using=20

character encoding enforcement.

=20

Re:Google vulnerable? (1)

pembo13 (770295) | more than 8 years ago | (#14309976)

Yah, but then people will call you a Google fan boy
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?