1. Alter the redirect_uri URL with TLD aws.console.amazon.com/myservice -> aws.console.amazon.com
2. Finish OAuth flow and check if you're redirected to the TLD, then is vulnerable
3. Check your redirect is not to Referer header or other param
ffuf -w words.txt -u https://www.target.com/endpoint?u=https://www.FUZZ.com/
# Path traversal: https://yourtweetreader.com/callback/../redirect?url=https://evil.com
# HTML Injection and stealing tokens via referer header
Check referer header in the requests for sensitive info
# Access Token Stored in Browser History
Check browser history for sensitive info
# Improper handling of state parameter
Check lack of state parameter and is in url params and is passed to all the flow
Check state is not reused
Remove state and URI and check request is invalid
If not email verification is needed in account creation, register before the victim.
If not email verification in Oauth signing, register other app before the victim.
# Access token passed in request body
If the access token is passed in the request body at the time of allocating the access token to the web application there arises an attack scenario.
An attacker can create a web application and register for an Oauth framework with a provider such as twitter or facebook. The attacker uses it as a malicious app for gaining access tokens.
For example, a Hacker can build his own facebook app and get victim’s facebook access token and use that access token to login into victim account.
# Reusability of an Oauth access token
Replace the new Oauth access token with the old one and continue to the application. This should not be the case and is considered as a very bad practice.