The interesting part of this post is the utilization of an external API to result in SSRF, specifically the Google Drive API.

It takes advantage of the fact that the API by default returns a JSON payload that includes downloadURL that users of the API would then request to download the file itself. However, if one can include the alt=media query parameter and value in the request, rather than serving the metadata it would serve the file content itself. Allowing an attacker to control the downloadURL which applications would trust by serving a file containing the relevant JSON.

First Finding - Partial SSRF in Private Bounty

In this private application, the fileId field could be abused for path traversal on the Drive API to hit other API endpoints, but the main issue was a CRLF Injection in the Authorization header as it would inject the attacker controlled authorization token into that header. This was abused to inject two blank lines leading the Google Server into thinking it was a second request, where the attacker then controlled the entire request and could do the alt=media trick.

The result was an SSRF however as the downloaded file was parsed as a PPTX the full contents could not be read.

Second Finding - Full-Read SSRF

We are not provided a lot of details here, just a link to the HackerOne report. Though I think the summary gives you a good idea of what happened.

This researcher pointed out that HelloSign’s Google Drive doc export feature had a URL parsing issue that could allow extra parameters to be passed to Google Drive API.