Weakness: partial 0Auth redirect_uri path
- While Testing one of the Target on Hackerone ,I’m gonna call it as REDACTED.COM
Following Test Case Tried for OAuth redirect_uri :
- Only Modified Thing’s Accepted at thridParty Site OAuth:
- Scheme Protocols
- Pre Subdomain Under *.connect.REDACTED.com
- Possibilites Here:
- I Need to find any Valid Subdomain under https://*.connect.REDACTED.COM to see what i can do further for exploitation.
- So I Started Bruteforcing for any available Pre-Subdomain’s under connect subdomain and Came across
https://pages.connect.REDACTED.COM which is Nothing but hosted with Static Page .
~Tried Bruteforcing for Directories or Any other Open Redirect Possibilities But Failed~
- Then i checked the Header For pages.connect.REDACTED.com and found HSTS Missing .
For Those Who Don’t Know what HSTS :
- It Redirect from HTTP to HTTPS on the same host first , before making valid Request to HOST to ensure not to leak Anything in HTTP.
- Final Exploit :
- End up Making Request to :
- We have Leak the Token to HTTP on Invalid Path to keep the Token Usable.
- Since Most of the Program Includes Man In Middle Attacks as OUT OF SCOPE.
- They have Fixed the Redirect_uri Path to Strict Path , And Reopened my Report and Marked it as Resolved for Detailed Explanation .
- How to Avoid This Type of Bugs Situation:
- Simply by Enforing HSTS Header :
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
- Here includeSubDomains; Tag will instruct to Serve all subdomains over HTTPS.
- By Setting Strict Redirect_uri in OAuth Callbacks.