Combine Open Redirect in exploiting security vulnerabilities
Google's Bug Bounty program (VRP) regularly receives error reports that mention the open redirect . Although they themselves are not considered security holes , we found that open redirect can be used to exploit other vulnerabilities such as XSS or OAuth Token Disclosure.
That's exactly what happened with a new interesting bug report sent to us by Tomasz Bojarski . Tomasz from a small Polish town, joined our bug bounty program in 2013 and now it is an event that changed his life. Tomasz was quite successful when he was currently at # 1 in our Hall of Fame .
He not only used one, but two redirects to trigger an XSS error on events.google.com.
Tomasz's report is quite brief:
Hey there ?
Have got a nice XSS for your in events.google.com
Cheers
Tom
Clicking on the URL will show an alert from events.google.com so we can see quite clearly that Tomasz actually found a valid XSS vulnerability on a Google sandboxed domain. Embedded payloads multiple URL classes, one of them points to an external domain: woops-pocs-apppot.com. Exploiting involves many steps – let's explore step by step details:
Step 1: Photoproxy in the Google I / O website 2015
To exploit, Tomasz selected a page containing images in a previous Google I / O event. These images have been downloaded using the Picasa Web Albums XML feed . However, this XML feed is stored from another domain (picasaweb.google.com) and does not use the Same Origin Policy CORS header to prevent the web application from reading it.
Therefore, the Google I / O team used a workaround to display photos. This site includes a server-side processor / api / v1 / photoproxy, which can retrieve a URL passed into a parameter and an HTTP response proxy. In this way, the application can send XMLHttpRequest to the same source / api / v1 / photoproxy? Url = to access the feed. The Google I / O website 2015 is open source , so you can see for yourself how this has been implemented .
Of course, serving URL content based on your domain name will immediately cause an XSS error – so the server performs the following tests before proceeding:
1 2 3 4 5 | url: = r.FormValue ("url") if! strings.HasPrefix (url, "https://picasaweb.google.com/data/feed/api") { writeJSONError (c, w, http.StatusBadRequest, "parameter url is missing or is an endpoint invalid") return } |
This test is done to ensure that only "trusted" Picasa feeds can be proxy. However, the bypass check is easy if an endpoint redirects through a domain exists in https://picasaweb.google.com.
So does it exist? Of course ?
Step 2: Redirect from picasaweb.google.com to google.com
Tomasz starts by selecting a known navigation endpoint: https://picasaweb.google.com/bye?continue=. In order to bypass the prefix check, he used this simple path transfer wizard: while the string https://picasaweb.google.com/data/feed/api/../../ .. / bye starts with https://picasaweb.google.com/data/feed/api, when the query to the URL is submitted, the URL will return to normal to https://picasaweb.google.com/bye. That's exactly what he needs.
But wait – there's another limitation. Redirecting from the next parameter value is not completely open, because it needs to point to one of Google's domains (for example, www.google.com). To load content freely, Tomasz needed to find an open redirect on www.google.com and associate it with it.
Step 3: Open redirect on www.google.com
www.google.com contains several open redirect – and the latest one related to AMP :
https://www.google.com/amp/
The combination of these two redirects results in a URL that starts from the Picasa source but ends up in an arbitrary domain:
https://picasaweb.google.com/data/feed/api/../../../bye/?continue=https%3A%2F%2Fwww.google.com%2Famp/your-domain.example. com / path? querystring
At this point, we are ready to submit a query to https://events.google.com/api/v1/photoproxy which will retrieve a URL from an arbitrary domain name. So, how do you turn it into an XSS error? Let's take a look at the query handler .
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 27 28 | func servePhotosProxy (w http.ResponseWriter, r * http.Request) { c: = newContext (r) if r.Method! = "GET" { writeJSONError (c, w, http.StatusBadRequest, "method request invalid") return } url: = r.FormValue ("url") if! strings.HasPrefix (url, "https://picasaweb.google.com/data/feed/api") { writeJSONError (c, w, http.StatusBadRequest, "parameter url is missing or is an endpoint invalid") return } req, err: = http.NewRequest ("GET", url, nil) if err! = nil { writeJSONError (c, w, errStatus (err), err) return } res, err: = httpClient (c). Do (req) if err! = nil { writeJSONError (c, w, errStatus (err), err) return } defer res.Body.Close () w.Header (). Set ("Content-Type", "application / json; charset = utf-8") w.WriteHeader (res.StatusCode) io.Copy (w, res.Body) } |
As you can see from the Go function above, the server will try to retrieve content from a certain URL and return the response content (io.Copy). If an attacker can cause the browser to compile the response as an HTML document, all the JavaScript contained there will run in context under events.google.com – a simple XSS error.
However, to block sniff MIME vulnerabilities, the server specifies a Content-Type application / json to block modern browsers from compiling feedback like HTML.
Tomasz has found a clever trick to overcome this control. You will notice that the Content-Type header is only created when the response is successfully obtained. In case of an error, the writeJSONError function will be called instead.
Step 4: XSS through error handling
WriteJSONError function sets 5xx status code and outputs an error message in a JSON object. But because the function does not set a Content-Type header, sniff MIME will occur. In short, when an HTTP response is not received, a browser tries to identify an HTML fragment and if it finds it will compile the response as an HTML document, allowing XSS to occur. out.
To enable XSS on events.google.com, Tomasz needs to make sure that the error message that comes out contains HTML code, which turns out to be quite easy to do:
When Photoproxy approached Tomasz's web application, he redirected the HTTP client to an invalid URL containing the HTML code, triggering a Go HTTP client error. This causes endpoint Photoproxy to export the following JSON segment:
1 | {"error": "Get http://woops-pocs.appspot.com: failed to parse Location header "//><img src=x onerror='alert(document.domain)'": parse //><img src=x onerror='alert(document.domain)': invalid character " " in host name"} |
The browsers compile this JSON segment as HTML and execute the embedded JavaScript code, enabling the XSS error:
Very good, Tomasz!