True Tales About Vulnerabilities in Google Services

Story 1. The Little Content Type that Could

The vulnerability was found in Feedburner. First, I created a feed and tried to inject malicious data. No success there. Injected data just wouldn’t show up, only harmless links were presented. I took a few more attempts and then I found lots of messages from PodMedic. PodMedic examines links in every feed. If it finds troubles in creating a feed, it reports the cause of such troubles. The messages read that links are incorrect because the content type returned was a text type.

Hmm. Ok. I bet the content type on this page isn\’t filtered. A simple script for my server:

; charset=UTF-8\’); ?>

And here it is:

Story 2. The Little Callback that Could

The Feedburner vulnerability was not satisfying. It was quite simple, actually. So I decided to try something else. After some searching, APIs Explorer on caught my attention. Google’s APIs Explorer is a tool that helps you to explore various Google APIs interactively. Google also says that with the APIs Explorer, you can browse quickly through available APIs and versions, see methods available for each API and what parameters they support along with inline documentation, etc. In fact I was interested in cross-domain messaging based on postMessage. A link to the Google API that we are testing can be given in the Base parameter:

The Base parameter is filtered by certain regular expressions (not quite accurately though) but it is easy to bypass them using a %23 symbol:

As a result, an iframe with is created and now we’re waiting for messages from it. Every message should have two tokens. The first token is in of the iframe and the second is given in location.hash. I sniffed messages from and wrote a page that would send the same messages with valid tokens. It worked nicely, and I tried to inject some HTML data. No success, though. I could change text and image locations but it would not be enough for XSS. There was a documentation link, the location of which could be changed. So I changed it to javascript:alert(document.domain) and it worked perfect.

Still not enough. It required user interaction, but I really don\’t like it. Users never do what you want them to do (click that wrong link, for instance). So I found a page on with the callback function (almost all developers think that callbacks are secure). I added redirection to this page with the callback ‘parent.document.links[0].click’ to my exploit after creating the documentation link via postMessage. Symbols [ and ] were filtered, so actually the callback was as follows:


Let’s try it:

Done! Works fine and no need for user interaction. The exploit was as follows:

token_1 = location.hash.split(\’rpctoken=\’)[1];
token_2 =;
window.setTimeout(\’document.location=callback_url;\’,3000); // Paused because of slow internet connection…

And of course I made a cool screenshot 😉

I liked that method of exploiting and tried to use it in other services. I used it to steal an OAuth token to be able to buy any app at Google Play using users’ payment details. Besides, the app could automatically be installed on user’s android device.

The Google Security Team also liked that technique and they described it on OWASP AppSec Eu as Reverse Clickjacking.

Author: Pavel Toporkov, Positive Research

2 thoughts on “True Tales About Vulnerabilities in Google Services

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.