# SECURITY REVIEW: Chromium Extension APIs
REAL THREATS
CRITICAL: Server-Side Request Forgery (SSRF) Attack Surface
Findings 69-77, 3, 7, 8 - These are legitimate SSRF vectors in the identity and auth flow APIs.
• Finding 69-70: Token requests with user-controlled parameters can be redirected to internal services. An attacker could probe internal metadata endpoints (169.254.169.254), internal auth servers, or exfiltrate tokens to attacker-controlled domains.
• Finding 71-75: Multiple auth dialog URLs are constructed from user input without sufficient validation. This lets extensions hit arbitrary internal endpoints during OAuth flows.
• Finding 3: The downloads API accepts arbitrary URLs. This is a classic SSRF - extensions can probe internal networks, port scan, and access cloud metadata services.
• Finding 7-8: Auth flow URLs are user-controlled. Attackers can redirect authentication flows through internal services.
Impact: Full internal network reconnaissance, cloud metadata theft (AWS keys, GCP tokens), bypass of firewall rules, potential RCE via exploiting internal services.
CRITICAL: Open Redirect Vulnerabilities
Findings 75, 76, 77, 6, 9 - Open redirects in authentication flows are especially dangerous.
• Finding 75-77: Consent and redirect URLs aren't validated against allowlists. Attackers can redirect users from trusted Google domains to phishing sites.
• Finding 6, 9: OnAuthFlowURLChange callbacks don't validate redirect targets.
Impact: Credential phishing (looks like google.com redirecting to evil.com), OAuth token theft, bypass of CSRF protections that trust Google domains.
CRITICAL: Command Injection / Arbitrary Process Execution
Findings 1, 10, 11, 78 - Native messaging hosts are launched with insufficient input validation.
• Finding 1: Native host names aren't sanitized before process launch. Could allow path traversal or shell metacharacters.
• Finding 10-11: Command line arguments passed unsanitized to spawned processes.
• Finding 78: The entire native messaging launch mechanism is flagged as insecure.
Impact: Full system compromise. A malicious extension can execute arbitrary code on the host system with user privileges. This is RCE.
HIGH: Sensitive Information Disclosure
Finding 35 - Account enumeration via identity.getAccounts is a real privacy leak. Attackers can determine which Google accounts are logged in, enabling targeted attacks.
Impact: Privacy violation, targeted phishing, tracking across sites.
MODERATE: Potentially Dangerous API Configurations
Findings 0, 2, 12 - These are powerful APIs that need careful review:
• Finding 0: Debugger API gives full tab control - can inject scripts, steal data from any page
• Finding 2: Desktop capture allows screen recording - can capture passwords, private messages
• Finding 12: Native messaging allows arbitrary process launch (related to command injection above)
Impact: These aren't vulnerabilities per se, but they're extremely high-privilege capabilities. If extension permission models are weak, these become attack vectors.
ATTACK CHAINS
Chain 1: SSRF → Metadata Theft → Privilege Escalation
1. Use Finding 3 (downloads SSRF) or Finding 70 (token request SSRF) to hit cloud metadata endpoint
2. Steal AWS/GCP credentials from 169.254.169.254
3. Use stolen credentials to access cloud resources, potentially escalating to full infrastructure compromise
Chain 2: Open Redirect → OAuth Token Theft
1. Use Finding 75-77 (consent URL redirect) to redirect from legitimate Google auth flow
2. Victim sees google.com in address bar, then gets redirected to attacker site
3. Attacker captures OAuth tokens or credentials in transit
4. Use tokens to access victim's Google account
Chain 3: Native Messaging → RCE
1. Use Finding 1 or 78 (unsanitized native host launch) to inject shell commands
2. Execute arbitrary code on victim's machine
3. Install persistent backdoor, keylogger, or ransomware
Chain 4: Account Enumeration → Targeted Phishing
1. Use Finding 35 to enumerate logged-in accounts
2. Identify high-value targets (corporate emails)
3. Use Finding 75 (open redirect) to phish those specific accounts with convincing Google-originated redirects
VERDICT
THIS IS NOT SAFE TO DEPLOY.MUST FIX IMMEDIATELY (P0 - Deploy Blockers):
1. SSRF vulnerabilities (69-77, 3, 7, 8): Implement strict URL allowlisting. All token endpoints, auth URLs, and download URLs MUST be validated against a hardcoded allowlist of permitted domains. Reject any URL with private IP ranges (RFC 1918), localhost, link-local addresses, or cloud metadata IPs.
2. Command injection (1, 10, 11, 78): Never pass unsanitized input to process spawn. Use allowlists for native messaging hosts - only permit explicitly registered, cryptographically verified binaries. Escape all command-line arguments or better yet, use parameterized execution APIs.
3. Open redirects in auth flows (75, 76, 77, 6, 9): Implement strict redirect URL validation. Auth flows should ONLY redirect to explicitly allowlisted Google domains. No user-controlled redirect targets in OAuth flows - this is a fundamental security principle.
FIX SOON (P1):
4. Account enumeration (35): Require explicit user consent before exposing account information. Consider rate limiting.
5. High-privilege APIs (0, 2, 12): Audit extension permission models. These APIs should require explicit user consent and be restricted to known, audited extensions only.
Risk Assessment:
• Current state: Multiple critical RCE and credential theft vectors
• Exploitability: HIGH - SSRF and command injection are well-understood attack patterns
• Impact: CRITICAL - Full system compromise, credential theft, internal network access
• Recommendation: BLOCK DEPLOYMENT until findings 1, 3, 69-78 are remediated and independently verified
The SSRF and command injection issues are textbook critical vulnerabilities. Any one of these could lead to complete compromise of user systems or cloud infrastructure. This needs immediate remediation by the security team.