Google's vulnerability reward programme gets a lot of attention, and includes not just Google's main websites, but also those of acquisitions older than 6 months. With this in mind, I thought I'd venture off the beaten path and take a look at Admob,
one of the world's largest mobile advertising platforms according to Wikipedia.
Admob was acquired by Google for $750 million in November 2009, putting it well beyond the 6 months Google ask to patch up new arrivals, but also giving plenty of time for vulnerabilities to be found and fixed. At first glance things looked fairly good for Admob, but there was a nice little stored XSS waiting a little way under the surface.
The process of creating an Admob advert is as follows:
- Create a new advert, set dates and daily budget and add any notes
- Target the advert by mobile platform and give the ad group a name
- Select specific devices, set the advert's geographic and demographic scope and minimum per-click bid
- Choose an advert type, either Text or Image, and upload any creatives
The interesting part of the process is the last step, uploading creatives. The process follows a pattern I've seen before, which is to perform an AJAX image upload when a file is selected, then take the image path returned by the AJAX script and store it in a hidden input field ready to be saved when the form is submitted.
With this knowledge in hand, I uploaded an image and started manipulating the form data to test different image URLs.
Because this is a static cross-site scripting attack (i.e. the server is providing the content, not the browser), no browser-side XSS filters are triggered and the code is executed regardless of browser security settings. The moral of the story? Don't hand your data to the browser and expect it to get sent back to the server without any tampering!
- 2013-05-28 Vulnerability reported to Google
- 2013-05-29 Bug filed by the Google security team
- 2013-06-04 Notification that the bug qualified for a reward