2010
12.21

Google Vulnerability Reward Program: XSS in Google Support Contact Form

Category: Vulnerability Writeups / Tag: google, google vulnerability reward program, security, web application security, xss / Add Comment

Summary

One page in Google’s Help Center was vulnerable to a reflected cross-site scripting attack.

How did it work?

The page in question contained the following snippet of JavaScript embedded within its HTML:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
/*
function fileCartReport(form) {
    var comment = form.elements['body'].value;
    var entityStrEscaped = 'entity text';
    var entityStr = entityStrEscaped.replace(/"/g, '"');
    var client = '0' * 1;
    cartReporter().fileCartReport(entityStr, getAbuseType(), comment, client, function () {
        form.submit();
    });
}
*/

function fileCartReport(form) {
    var entityStrEscaped = 'entity text';
    var entityStr = entityStrEscaped.replace(/"/g, '"')
    var report = {
        entityId: entityStr,
        abuseCategory: getAbuseType(),
        comment: form.elements['body'].value,
        applicationId: '0' * 1,
        language: 'en'
    }
    cartReporter().fileCartReport(report, function () {
        form.submit();
    });
}

In the real code, the string entity text was actually the value of a parameter named entity passed in the URL. In normal links to the page, the entity parameter was a JSON-encoded string, which the rest of the JavaScript would then submit back to Google. However, since the data was being passed in the URL, it was possible to change the value placed in the JavaScript.

Of course, the value wasn’t fully under my control: for instance, there was still some input escaping that turned single quotes and double quotes into HTML entities. As a result, I couldn’t find a way to inject arbitrary JavaScript into the uncommented function. However, I realized that it was possible to inject it into the commented function: all I needed to do was begin my payload with */ and end it with /*, to preserve the existing block comment. At that point, I could write just about any JavaScript I wanted in the middle (keeping in mind the restrictions imposed by input escaping).

The vulnerability in action

I remembered to grab a screenshot of the vulnerability as I was testing for it, and I’ve reproduced it below;

The XSS vulnerability in action (in Google Chrome)

The XSS vulnerability in action (in Google Chrome)

More Information

The vulnerability mentioned here has been confirmed patched by the Google Security Team. I owe them a ton of thanks for organizing this program and giving me a chance to improve my skills. :-)

Interested readers are encouraged to take a look at other vulnerabilities I’ve reported under Google’s Vulnerability Reward Program.

Comments