OAuth 2.0 : Implementation crimes Part 1
If at some point in your career as web developer you encounter the need of implementing a Social Login using OAuth 2.0 for your website you may want to be aware of the following implementation flaws. If not, you are exposing your users to all kind of security vulnerabilities that may end up exposing their data and potentially get your fired from the company where you are currently working on.
Implicit Flow : Authentication bypass
During a implicit flow the access token is sent directly from the OAuth service API to the Client Application over the browser after the user consents on the scope of the application.
If the web application wants to keep the session after the user closes the browser it will need to store relevant information (access token and user ID for example) to re-generate a new session when the user comes back later.
If the user wants to open the application again without the need of logging in again it will need to re-submit the stored information (usually using a POST request) to the server to get a new session and set it as a cookie in the user’s browser.
However, when submitting this information, the server has no extra parameters such as secrets or passwords to compare with the request. This means that this request is assumed to come from a trusted source.
This requested is exposed in the user’s browser and can be intercepted using a proxy. If the server does not properly checks that the access token sent matches the other parameters in the request an attacker can modify the other parameters and impersonate any other user.
Regular request to refresh the session when the user opens the app again
{
“email”:”regular-user@regular.com”,
”username”:”Robert”,
”token”:”efI3_EGDCyDC_6FGQjxSxhzuwf-hoGsH-i-nnjxPlMd”
}
Modified request to impersonate a different user
{
“email”:”target-user@target.com”,
”username”:”Robert”,
”token”:”efI3_EGDCyDC_6FGQjxSxhzuwf-hoGsH-i-nnjxPlMd”
}
In this case, if the server is only checking that the access token is correct and does not compare it to the email, we can just provide a valid token from any user and replace the email field to get access to the user registered to that email.
Account hijacking via ‘redirect_url’ GET parameter
When implementing a OAuth flow the first request that starts the flow it will usually look like this
GET https://my.webapp.com/auth?
client_id={web_app_client_id}&
redirect_uri=https://my.webapp.com/oauth-callback&
After the user consents to the scope specified in the request a redirection will occur and it will lead to the ‘redirect_uri’.
If the servers does not have a whitelist of URL that the response can be redirected to, an attacker can modify this parameter and redirect the response (that may contain an access token or an authorization code depending on the ‘response_type’ parameter) to a domain controlled by him/her.
GET https://my.webapp.com/auth?
client_id={web_app_client_id}&
redirect_uri=https://domain.controlled.by.attacker/oauth-callback&
Conclusion
Be sure to properly check of the values submitted along with your access token to verify if they actually belong to the user before granting a new session and whitelist your callback uri on the server side to prevent attackers to redirect the access tokens to their own domains.
Reference and source : PortSwigger Web Security Academy
