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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
