Jonas + Filip given his expertise
I tried to follow this thread but got lost. My understanding is you are suggesting we recommend response_mode=form_post over response_mode=redirect If session cookies are sameSite=lax, they won't to be sent via form_post -- so client web sites would have to set session cookies to sameSite=none -- which is susceptible to CSRF of course, and while there are other ways to protect against CSRF, your attack is CSRF -- so it would seem that if the site has protected against CSRF then the attack can't happen. What am I missing? /Dick On Wed, Nov 5, 2025 at 3:56 AM Primbs, Jonas <[email protected]> wrote: > Hi Neil, > > Am 04.11.2025 um 09:53 schrieb Neil Madden <[email protected]>: > > > > On 4 Nov 2025, at 13:37, Primbs, Jonas <[email protected]> > wrote: > > 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. > > > Attackers with real-time access to logs are generally already quite > privileged (eg they have ssh access to the servers or access to a SIEM). > The risk from logs mostly comes from them being copied into support tickets > or archived to insecure S3 buckets and similar things. Those things don't > generally happen in 10 minutes. > > > I don’t agree here. > Having read-only access to a SIEM system, which provides you real-time > access to logs being collected from a client application or any involved > reverse proxy, load balancer, middleware etc, should not enable you taking > over the client session of any user. > This is a behavior, which many service providers will not expect from an > OAuth-compliant software. > > Moreover, this increases the criticality of misconfigured HTTP servers, > e.g., an NGINX or Apache web server which allow you to access the server’s > logs in real-time by browsing something like > /../../../../var/logs/nginx/access.log > I agree, such misconfigurations should not be in scope of OAuth. However, > this increases the criticality of such a finding from an information leak > to a medium or even high - and OAuth could improve that by slightly > changing the specs. > > > 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. > > > Re-reading my old blog post ( > https://neilmadden.blog/2019/01/16/can-you-ever-safely-include-credentials-in-a-url/) > reminds me of a drawback of using the fragment: if you don't explicitly > clear it, then it is carried over on redirects, potentially leaking the > auth code to other pages/sites. (At least, that used to be the case - I > don't believe that behaviour has changed). > > > Yes, but we have the same issue with query parameters too, right? > Fragment however has the advantage of reducing the attack surface with > respect to logging from an entire landscape down to the client. > > > > 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 agree in general, but (a) the situation is a lot less bad than it used > to be and (b) the short-lived nature of auth codes does IMO mitigate a lot > of these issues. According to > https://www.oauth.com/oauth2-servers/authorization/the-authorization-response/, > most auth codes are in fact only valid for 30–60 seconds, which would > further reduce the opportunity to exploit this. > > > That’s right, maybe we should recommend a validity period of 1 instead of > 10 minutes in OAuth 2.1. > > By the way, Aaron and I had a discussion on that today and we figured out > that the „implicit flow“ of OIDC might also be affected. Probably things > are much more critical here than in OAuth. > > We also discovered an alternative fix for that by enforcing PKCE for every > flow and sending a token request from client to AS even if state parameters > don’t match. > This promises to simplify the specs in general with the nice side effect > that it also sufficiently fixes browser-swapping attacks without breaking > changes. > I will discuss that with Aaron and Mike and will send an update. > > I'm sympathetic to the idea that query mode is not great, but it's pretty > well established at this point and we've spent a long time telling people > to use it. I don't find this a compelling enough reason to suggest a > change. > > > I get your point. However, I’m not a friend of leaving things as they are, > just for not having to correct previous statements, especially if we > could do better. > > 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 > > > — Neil > > > Independently of whether browser-swapping attacks are a realistic attack > or not — does anyone disagree with adding or at least referencing response > modes in the OAuth 2.1 spec in general? > I personally would have been glad to have had any reference to them from > another document instead of being lucky that I accidentially stumbled over > this spec. > > Greetings, > Jonas > > > _______________________________________________ > OAuth mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
