When integrating an application with Google Drive, there are 3 ways: client side embedding, CDN URL then download the data on the server side or fetch the file via the GDrive API. The first two are what we normally see from a user perspective. The final one is where the fun beings.
When applications use this endpoint, they typically add a file parameter to access the information with the Authorization of this user. Then, a link is given back to the application to make another request to get the actual file. Since the file parameter is provided to the user, we can not only include the file but other parameters associated with this file. Would this be useful?
The parameter alt=media on the request to get an element from Google Drive. By placing this parameter, the contents of the file are returned instead of a JSON blob to make the next request. Now, if we can control this file on Google Drive we can control the JSON blob being returned for the next request. This could be used for a deadly SSRF attack.
Using this implicit trust of the application data being returned, the author found some other bugs. First, in a private program using the Google Drive API they used a path traversal to get fully control the item being grabbed. However, it did not suffer from the parameter injection but DID suffer from CRLF injection. Using the CRLF injection to alter the body of the request, they were able to get a limited SSRF.
Dropbox has a similar vulnerability as well. Using the exploit, they were able to make requests in the AWS EC2 instance to steal credentials.
Overall, this is an interesting piece of technology that is all over the place! This vulnerability is likely in many different applications that have yet to be discovered.