Hi Neil, thanks for your valuable feedback. You will find my thoughts inline.
> Am 04.11.2025 um 04:19 schrieb Neil Madden <[email protected]>: > > Thanks for sharing your slides. Although this is an interesting theoretical > attack, I do not think it is much of a concern in practice. If we take your > attack vectors from slide 12: > > * Referer header leaks: the default policy in browsers since 2019 is > strict-origin-when-cross-origin, which prevents this leak [1]. I still think it is worth to mention in the draft because even if it’s the default, it does not mean that client implementors do not change it in a bad way. Moreover, in modern infrastructures, reverse proxies are often used for path-based routing, which results resources (images, favicons etc) being referenced on the same host but requests will be routed to external parties like CDNs. > * URL sharing and analytics tools are already addressed by [2] in the > original OAuth RFC 6749, which already says to avoid 3rd party analytics on > the redirect endpoint and to redirect immediately after collecting the > credentials. I think most providers do in fact do this? Yes, I have never seen the issue with the analytics tools in the wild before, I just added it for completeness. Out of the last 10 oauth client penetration tests, of which 6 were affected by the browser swapping attack (the other 4 did not even implement the CSRF protection), only one was affected by the URL sharing. However, redirecting to another URL, not including scripts, and ensuring that referrer-policies are applied correctly are all mitigation strategies, but not solve the general issue of sending a secret (the authorization code) as a query parameter, which is a bad practice in general [1]. > That leaves leakage via logs, which IMO is adequately addressed by (a) use of > TLS (minimising on-path observers) and (b) using short-lived auth codes. a) That’s correct. b) According to RFC 6749, the maximum validity period is 10 minutes. Today, many logging happens in real-time, so my impression was that 10 minutes is enough for attackers with access to logs. Think of a shell script which polls every minute for the logs and greps for the keyword „code“, extracts the authorization code and automatically resolves that. > Using fragments or form_post both have significant downsides. Fragments only > work with Javascript, which introduces new failure cases and attack surface > (ideally the redirect endpoint would be served with CSP script-src=none). Yes, that’s why I recommend this for web apps running in the user’s browser with javascript anyways, or for mobile apps. > Form post requires use of samesite=none cookies, weakening CSRF protections. > I don’t think we should be recommending weakening protections against very > real threats (XSS, CSRF) to protect against something that seems unlikely. Thanks a lot for that hint with the CSRF protection with samesite=none. I think samesite=none works perfectly fine, if the „session“ cookie is not a real session cookie, but the state parameter instead, because then the „state“ cookie, which contains the state parameter combined with the identical state parameter reflected by the AS in the POST body parameter apply the double submit cookie pattern [2], which is also a well-known CSRF protection mechanism. The real session cookie (if you even need one before you are logged in) could still use samesite=strict or lax. But I get the point that maybe I should mention this in the draft. > We can perhaps improve the wording around existing countermeasures if there > is evidence they are being ignored, but I think that is enough. I could be > persuaded otherwise, but I’d need to see more evidence that this is a problem > in practice and that the countermeasures do more good than harm. I think the problem with response_mode=query in general is that the authorization code is transferred in the URL which opens up many attack vectors that all need to be fixed. The most critical one are logs because there is no general fix for that, exept not providing the authorization code as a query parameter. My impression was that our customers were really surprised that this is still the default behavior of OAuth and they didn’t expect that from such a big large-scale deployed standard. Especially our customers, which just deploy existing client implementations, did not expect that they have to care that much about logs of, e.g., their reverse proxies, and they were shocked that these logs which are sometimes audited by external partners enable the log auditor to start a browser-swapping attack and take over, e.g., administrator accounts. I totally agree, that we cannot simply deprecate response_mode=query for legacy reasons. However, I think we should ensure that client developers and providers are aware of the risk that authorization codes can get logged and can be used to take over user sessions. [1] https://owasp.org/www-community/vulnerabilities/Information_exposure_through_query_strings_in_url [2] https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html#alternative-using-a-double-submit-cookie-pattern Greetings, Jonas > > [1]: https://github.com/whatwg/fetch/pull/952 > [2]: https://datatracker.ietf.org/doc/html/rfc6749#section-3.1.2.5 > > Best wishes, > > Neil > >> On 4 Nov 2025, at 04:10, Primbs, Jonas <[email protected]> wrote: >> >> Hi all, >> >> according to Aaron’s recommendation, I have created a PR for OAuth 2.1: >> https://github.com/oauth-wg/oauth-v2-1/pull/230 >> >> It references OpenID Connect’s response modes (fragment and form_post) as >> solutions for Browser-Swapping attacks, which I have presented in today’s >> OAuth WG meeting. >> If you have missed my presentation, but are still interested, here are my >> slides: >> https://datatracker.ietf.org/meeting/124/materials/slides-124-oauth-sessa-browser-swapping-01 >> >> I’m interested in your feedback on this first draft, which currently covers >> only recommendation #2 from my slides, because this is probably the least >> controversial change. >> If you are attending onsite, also feel free to speak to me in the hallway. >> My company gave me enough of the „No, PKCE…“ t-shirts for the rest of the >> week, so that it’s easier for you to find me. @Brian & Mike: I have learned >> from the best ;-) >> >> Greetings, >> Jonas >> >> >> Jonas Primbs M.Sc. >> University of Tübingen >> Faculty of Science >> Department of Computer Science >> Sand 13, 72076 Tübingen, Germany >> Tel.: (+49) 7071 / 29-70512 >> Mail: [email protected] >> Web: https://kn.inf.uni-tuebingen.de >> >> _______________________________________________ >> OAuth mailing list -- [email protected] >> To unsubscribe send an email to [email protected]
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
