<![CDATA[OAuth account takeover doesn't need leaked tokens.]]>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/

]]>https://board.circlewithadot.net/topic/4dd5d45d-6cd0-407d-9e97-575ef5e45cce/oauth-account-takeover-doesn-t-need-leaked-tokens.RSS for NodeMon, 06 Apr 2026 04:02:42 GMTSun, 29 Mar 2026 08:44:21 GMT60<![CDATA[Reply to OAuth account takeover doesn't need leaked tokens. on Mon, 30 Mar 2026 06:55:07 GMT]]>@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.

]]>https://board.circlewithadot.net/post/https://infosec.exchange/users/hacksilon/statuses/116316812550300365https://board.circlewithadot.net/post/https://infosec.exchange/users/hacksilon/statuses/116316812550300365Mon, 30 Mar 2026 06:55:07 GMT