OAuth account takeover doesn't need leaked tokens.

[rsgbengi@infosec.exchange]

OAuth account takeover doesn't need leaked tokens. No state param = CSRF to forced account linking. Loose redirect_uri matching = code theft via open redirect chains. Implicit flow puts tokens in browser history and Referer headers. PKCE bypass when not enforced server-side. SSRF via OpenID dynamic client registration. Six patterns, all with labs. https://www.kayssel.com/newsletter/issue-43/ #OAuth #BugBounty #Pentesting #websecurity #Offsec #InfoSec

[hacksilon@infosec.exchange]

@rsgbengi Hey. Thanks for the writeup. I feel like there is either an error or a missing attack type in the redirect_uri section, when it comes to subdomain confusion. The trick I know is using the entire domain as a subdomain to your own domain, so to use legitimate.com.evil.com as the redirect_uri to attack a wildcard like legitimate.com* (without a slash before the wildcard).

I'm not aware of any OAuth issues that would allow you to add an extra subdomain to a redirect URI - is that a thing as well? Keycloak does not expand wildcards that aren't the final character of the redirect URI, so *.legitimate.com would not be a working wildcard, but other implementations may differ.