You are not stealing the authorization code from a redirect chain. The browser is calling the callback endpoint, which has a state check that throws an error (https://github.com/anador/oauth-demo-poc/blob/ab0378a2275ea4ab3226a7df640b65c9ed0d3cb0/oauth_poc/routes/callbacks.py#L87). In a user-facing application, it is highly unlikely that this will result in an error dump with a 400 status code. What you are reading right now is the authorization code that is available once the browser has rendered the JSON response with status 400 in the iframe.
Additionally, this failure is only there because you are using state for flow integrity purposes. RFC 9700 already favors PKCE and nonces instead of the state parameter. When not using state, wouldn't the client try to exchange the code, which will then fail because of PKCE/nonce mismatches? Philippe > On 6 Nov 2025, at 12:55, Andrey Kuznetsov <[email protected]> wrote: > > If that's what you mean, there is another quick recording > <https://youtu.be/RtI-Jd5PujM>. > This time I have not changed response mode and preserved the original "query" > mode and accessed the authorization response from the JS executed in the > user's browser. > In this case the app prevented from using the authorization response because > the returned state does not match the cookie. > > ---------------- > Кому: Andrey Kuznetsov ([email protected]); > Копия: [email protected]; > Тема: [OAUTH-WG] Re: Question: Form Post Response Mode in OAuth/OIDC Security > Best Practices; > 06.11.2025, 14:00, "Philippe De Ryck" <[email protected]>: > Hi Andrey, > > Something does not add up here. In the manual demo, you have response_mode > set to fragment. In the short demo, you use 4.js as the payload, which is > configured to read the code from the fragment of the URL (hash). As Neil > Madden pointed out in the browser swapping discussion (different thread), > fragments are preserved across redirects. This means you would be able to > read the fragment after the redirect chain has completed and a page is loaded > in the iframe. > > IIRC I tried out reading the query parameters of an intermediate URL during a > redirect chain (as I mentioned earlier) and this did not work. I > unfortunately don’t have time to look into this now, but I’d be greatly > interested to see if you can read the parameters of URL B in this scenario: > > 1. Request to start the flow to the backend client > 2. Client responds with a redirect to AS with URL A > 3. Request with URL A to AS > 4. AS responds with a 302 with Location: URL B > 5. Request with URL B to the callback endpoint (<— the one you need to access > from your JS code) > 6. Client responds with URL C (to load the main application) > 7. Request with URL C to load the main application > 8. Regular HTML response > > Looking forward to hear your thoughts > > Philippe > > > > On 6 Nov 2025, at 11:30, Andrey Kuznetsov <[email protected] > <mailto:[email protected]>> wrote: > > Philippe, > Yes, i suppose, i do. > I have a short video demonstration <https://youtu.be/AFsrm02tC6c> for the > described attack. Also there is another demo <https://youtu.be/asEBPOs9ys8> > for the same attack but done manually for clarity. > The source code for applications used in those examples is available on > GitHub <https://github.com/anador/oauth-demo-poc>. The app may take some > setup but can be used with any OAuth/OIDC-compatible authorization server. > > Warren, > Perhaps, i may misunderstand your questions, but with the necessary > preconditions met it's not an assumption, but a statement. > > > ---------------- > Кому: Philippe De Ryck ([email protected] > <mailto:[email protected]>); > Копия: [email protected] <mailto:[email protected]>; > Тема: [OAUTH-WG] Re: Question: Form Post Response Mode in OAuth/OIDC Security > Best Practices; > 06.11.2025, 12:46, "Warren Parad" <[email protected] > <mailto:[email protected]>>: > Would someone be able to state the obvious for me? > > Is the assumption that there is a code injection attack present where an > attacker has access to javascript running in the application's interface? Is > that the core assumption or is it something else? > > On Thu, Nov 6, 2025 at 8:18 AM Philippe De Ryck > <[email protected] > <mailto:[email protected]>> wrote: > Hi Andrey, > > It seems that with this high degree of control, the attacker would indeed be > able to manipulate the flows. > > However, I’m curious to know if you have an actual working demo of step > 9-10-11. I remember from a private discussion a while ago that someone > pointed out that intermediate redirects are not observable in the browser. So > if response 9 triggers a redirect to the backend (10), and the backend > handles it and then redirects back to the main application (as a BFF would > do), then the request in 10 is not observable from JS, and would prevent an > attacker from stealing the authz code. > > Kind regards > > Philippe > > — > Pragmatic Web Security > Security for developers > https://pragmaticwebsecurity.com/ > > > On 6 Nov 2025, at 06:33, Andrey Kuznetsov <[email protected] > <mailto:[email protected]>> wrote: > > I'm sorry for the delayed response. > > Filip, i agree with your statements and you provided reasonable examples of > cookie that might be needed on the request to the redirect URI. > > There is also a reply from Dick with the similar reasoning: > As Filip stated, cookies are the main reason. There is almost always some > session state that the app wants to maintain between making the authorization > request and getting the authorization response. It can be as simple as where > the user was in the app so they are redirected to the original place, to what > is already in the shopping cart, or even existing authentication context as > the user is linking another account. With the use of PKCE, the threats of > intercepted query parameters are reduced. > > If we were to make a recommendation, it would be the redirect and not form > post as session hijacking is the larger threat now from my understanding. > > Also there's been another thread started about Browser Swapping attack which > discusses the related topic. However, i would like to clear things up. > 1. There is a real attack scenario in which the attacker can steal the > authorization code from the user's browser and use it even if the client > implements confidential client, PKCE, state and nonce (please, consult the > diagram 1.png attached) > 2. The ways of authorization code stealing are not hypothetical or ephemeral: > basically it can be done if the attacker is able to execute JS on any page of > the legitimate application that has an origin matching the origin of the > redirect URI . Full preconditions are listed here > <https://medium.com/@anador/attacks-via-a-new-oauth-flow-authorization-code-injection-and-whether-httponly-pkce-and-bff-3db1624b4fa7#cd2e>. > 3. The only complete mitigation for the attack is form post response mode > (please, consult the diagram 2.png attached). Other additional mitigations > are listed here > <https://medium.com/@anador/attacks-via-a-new-oauth-flow-authorization-code-injection-and-whether-httponly-pkce-and-bff-3db1624b4fa7#6da0>. > 4. The attack is possible because of the nature of OAuth flows (please, > consult the diagram 3.png attached). All additional protection measures such > as PAR/JAR/JARM don’t prevent the attack. > 4. When we use query/fragment/web message response modes we cannot prevent > the attacker that executes JS on the app's origin from accessing the > authorization response. However, form post response mode does not allow > access to the authorization response from the origin of the application > itself. But the authorization server must be able to limit the available > response modes at some level. > > On the other hand we have downsides of using form post response mode: if we > need cookies to be received on the redirect URI page, those cookies (not > actual session cookies!) must have SameSite=None attribute. I agree that for > some cases it can be crucial, but for some it can add no risks. > Also close attention should be paid to the values of the redirect URI that > the authorization server considers valid to prevent XSS at the AS side. > > > I suggest we should point out that form post response mode protects from the > stated attack, while it should be considered if CSRF at client's side is > going to be possible because of marking some cookies with SameSite=None. > > ---------------- > Кому: Andrey Kuznetsov ([email protected] > <mailto:[email protected]>); > Копия: [email protected] <mailto:[email protected]>; > Тема: [OAUTH-WG] Re: Question: Form Post Response Mode in OAuth/OIDC Security > Best Practices; > 26.10.2025, 10:54, "Filip Skokan" <[email protected] > <mailto:[email protected]>>: > > That is why I emphasized "significant". > > Are they not significant? > > I may not have read your blog post but i did read and quote the question I > was answering to. While these may appear as insignificant reasons at first > glance they are both blockers encountered at one point in time in my past > experience. > > > sameSite > > Account Linking, Step-up, re-auth, site preferences, shopping carts are all > scenarios where you want/need an existing session loaded (regardless whether > it's preauth or not). > > > FOUC > > User agent that's processing a 30x response with a location header and a 200 > that contains a JS self-submitting form is different when it comes to FOUC. > Of course this problem is exaggerated on unstable or slow connections such as > mobile. > > - Filip > > 25. 10. 2025 v 17:50, Andrey Kuznetsov <[email protected] > <mailto:[email protected]>>: > > > That is why I emphasized "significant". > > UX - FOUC or briefly displayed submit page at the AS when it's sending > responses > - The returning page with the autosubmitted form usually does not contain any > explicit content. In fact, I'm not sure how it's different from any redirect > URI page that might appear briefly, as you mentioned, when other response > modes are in use > > sameSite - the client is required to use sameSite=none for the cookies they > expect to load at the redirect_uri, that may include session related cookies > for which sameSite=none is the exact opposite of what they should strive for. > - I agree with the first part of your statement, that's true. However, we > should define what we mean by a "session" here and determine if it's a > problem. Usually, this applies only to certain cookies that are used to > maintain a "pre-auth session" and for such a case I'm not sure if it's a > significant issue. I considered this nuance in the research i mentioned > previously and explicitly stated that constraint. Could you share your > example, If you have another case where we do need a cookie to be sent to the > redirect URI endpoint? > ---------------- > Кому: Andrey Kuznetsov ([email protected] > <mailto:[email protected]>); > Копия: [email protected] <mailto:[email protected]>; > Тема: [OAUTH-WG] Re: Question: Form Post Response Mode in OAuth/OIDC Security > Best Practices; > 25.10.2025, 16:40, "Filip Skokan" <[email protected] > <mailto:[email protected]>>: > On the other hand, i cannot identify any significant drawbacks to using this > response mode, aside from inconsistent support across implementations. > > What about > - UX - FOUC or briefly displayed submit page at the AS when it's sending > responses > - sameSite - the client is required to use sameSite=none for the cookies they > expect to load at the redirect_uri, that may include session related cookies > for which sameSite=none is the exact opposite of what they should strive for. > > - Filip > > > 25. 10. 2025 v 15:21, Andrey Kuznetsov <[email protected] > <mailto:[email protected]>>: > > On the other hand, i cannot identify any significant drawbacks to using this > response mode, aside from inconsistent support across implementations. > > _______________________________________________ > OAuth mailing list -- [email protected] <mailto:[email protected]> > To unsubscribe send an email to [email protected] > <mailto:[email protected]> > > > -- > Best regards, > Andrey Kuznetsov > Software Architect > Identity & Access Management > Yandex Cloud > > , > _______________________________________________ > OAuth mailing list -- [email protected] <mailto:[email protected]> > To unsubscribe send an email to [email protected] > <mailto:[email protected]> > > > -- > Best regards, > Andrey Kuznetsov > Software Architect > Identity & Access Management > Yandex Cloud > > <1.png><2.png><3.png>_______________________________________________ > OAuth mailing list -- [email protected] <mailto:[email protected]> > To unsubscribe send an email to [email protected] > <mailto:[email protected]>_______________________________________________ > OAuth mailing list -- [email protected] <mailto:[email protected]> > To unsubscribe send an email to [email protected] > <mailto:[email protected]> > > > -- > С уважением, > Андрей Кузнецов > Архитектор, YC IAM & Resource Management > TG: @andreukuznetsov_work <https://t.me/andreukuznetsov_work> > > , > _______________________________________________ > OAuth mailing list -- [email protected] <mailto:[email protected]> > To unsubscribe send an email to [email protected] > <mailto:[email protected]> > > > -- > С уважением, > Андрей Кузнецов > Архитектор, YC IAM & Resource Management > TG: @andreukuznetsov_work <https://t.me/andreukuznetsov_work> >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
