OAuth
SUMMARY
OAuth is a framework commonly used by websites and web applications for authorization purposes. It is common nowadays to come across websites that allows users to share their data without exposing their login credentials to the requesting application. For example, an application might use OAuth to request access to your email contacts list so that it can suggest people to connect with.
Although it was designed for authorization, OAuth has evolved recently into a means of authenticating users as well. For example, it is used in many websites to allow user logins using their social media account rather than having to register with the site in question. Whenever you see this option, there's a good chance it is built on OAuth 2.0.
KEYWORDS
OAuth, authorization, authentication, implicit flow.
OAUTH-01: Authentication bypass via OAuth implicit flow
In OAuth implicit flow, access tokens are sent insecurely right after the user grants its consent.
Open the lab and initiate session as wiener . Capture the traffic with Burpsuite and analyze the frames. First you see the request to the authorization server, and the response with the redirection URI and a code.
The supplied code is used as cookie _interaction_resume and sent in the next request. The application replies with the access token as commonly done in implicit flow.
Finally the token is used to authenticate the user.
The app is vulnerable since it fails to properly check that the access token matches the username. Therefore, we can send this request to Repeater, just changing the username to whatever value we choose. We will get authenticated even though the token was requested by another username.
You are logged as carlos and the lab is solved.
How to verify this vulnerability in real life: when an application uses in implicit flow, authenticate with valid username and password. Once the access token is received, just try it with another user. If the application is vulnerable, you will get authenticated with the same token.
OAUTH-02: Forced OAuth profile linking
We are prompted to use a CSRF attack to attach our own social media profile to the admin account on the blog website, then access the admin panel and delete carlos account.
Login with your admin credentials, then click on "Attach social media profile". In the next screen, login with your social media credentials and grant the client application access to your profile and email.
Click on "Continue" and inspect the traffic with Burpsuite.
When the authorization is granted, a request to /auth is sent, which is responded with a 302 redirection to /oauth-linking with the code for the linking authorization.
Notice it does not include a state parameter. This is needed since the HTTP protocol is stateless, and now we can reuse this request. This is similar to CSRF attacks, where we trick victims to click on a malicious URL from their authenticated sessions.
If we can capture this URL and deliver it to the admin, the admin's account will get linked to our social profile. Exit the lab and enter again to start the process again. Follow the same procedure as before until access authorization is requested, then intercept the traffic with Burpsuite. When the request with the code is received, drop the request (so the code is not used) and copy the URL.
Now, to send the request to the admin, the lab provides an exploit server where we can attach the copied URL. It will be sent to the admin, and the exercise says the admin will always click on the links from his session.
How to identify this vulnerability in real life: log in with credentials and inspect the traffic, verify if the application fails to include a state parameter (or similar) to track the request.
OAUTH-03: OAuth account hijacking via redirect_uri
To identify the vulnerability, capture a request to /auth and notice it contains the authorization code.
Send to Repeater and verify the vulnerability by adding an arbitrary value in the redirect_uri
The application fails to validate the URL and the authorization code is provided no matter what the redirect_uri is.
This means we can add our exploit server URL in this field and capture the authorization code.
To solve the lab you just need to deliver the exploit the same way as in the lab before. At some point someone will click on it and you will receive a code in the server access log. Use the code to log in as admin by navigating to this URL: https://YOUR-LAB-ID.web-security-academy.net/oauth-callback?code=STOLEN-CODE
How to verify this vulnerability in real life: capture the redirection message and manipulate the redirect_uri to whatever value you want. If the application is vulnerable, it will fail to validate the URI.
REFERENCES
Last updated