Blog | G5 Cyber Security

Chrome Extension OAuth Token Theft

G5 Cyber Security

TL;DR

Yes, Chrome extensions can steal OAuth tokens if they have access to the redirect URI during the authorization flow. This is a serious security risk. Mitigations involve careful registration of redirect URIs, Content Security Policy (CSP), and regular auditing.

Understanding the Risk

OAuth 2.0 relies on redirect URIs to return control back to your application after a user grants permissions. If a malicious Chrome extension can intercept or modify this redirect URI, it can steal the authorization code (and subsequently the OAuth token) intended for your legitimate application.

How an Extension Can Steal Tokens

  1. Intercepting Redirects: An extension with the correct permissions (e.g., webRequest and host permissions matching your authorization server domain) can observe network requests, including the redirect URI after authentication.
  2. Modifying Redirects: A more sophisticated attack involves modifying the redirect URI to point to a malicious endpoint controlled by the attacker. This requires careful manipulation of HTTP headers and potentially bypassing browser security features.
  3. Content Script Injection: If your application uses JavaScript on the page where the redirect happens, an extension can inject a content script that intercepts the token before it’s sent back to your server.

Mitigation Steps

  1. Strict Redirect URI Registration:
    • Be Specific: Register only the exact redirect URIs you need with your OAuth provider. Avoid using wildcards if possible (e.g., prefer https://example.com/callback over https://example.com/*).
    • HTTPS Only: Always use HTTPS for redirect URIs.
  2. Content Security Policy (CSP):

    Implement a strong CSP to restrict the sources from which your application can load resources. This helps prevent malicious extensions from injecting scripts.

    meta http-equiv="Content-Security-Policy" content="default-src 'self'; script-src 'self' https://trusted-cdn.example.com;">
  3. State Parameter:

    Always use the state parameter in your OAuth requests. This is a randomly generated value that you verify upon receiving the redirect URI to prevent Cross-Site Request Forgery (CSRF) attacks and ensure the response is from a legitimate request.

  4. PKCE (Proof Key for Code Exchange):

    Use PKCE, especially for public clients (like single-page applications or mobile apps). This adds an extra layer of security by requiring a code verifier to be exchanged for the authorization code.

  5. Regular Auditing:
    • Extension Permissions: Regularly review the permissions requested by any Chrome extensions you use. Be wary of extensions requesting broad permissions that aren’t necessary for their functionality.
    • Network Monitoring: Monitor network traffic to your authorization server for unexpected redirect URIs or suspicious activity.
  6. Subresource Integrity (SRI):

    Use SRI tags when including external JavaScript files to ensure they haven’t been tampered with.

    <script src="https://example.com/script.js" integrity="sha384-..."></script>>
  7. Consider Browser Extensions Security Reviews: If you are developing a browser extension, conduct thorough security reviews and penetration testing to identify potential vulnerabilities.

Example Attack Scenario (Simplified)

Imagine your application uses https://example.com/callback as the redirect URI.

  1. A malicious extension injects a script into your page.
  2. When you click an OAuth authorization link, the extension intercepts the redirect URI in the network request.
  3. The extension modifies the redirect URI to https://attacker.com/callback.
  4. Your OAuth token is sent to https://attacker.com/callback instead of your legitimate application.
Exit mobile version