But what would encrypt or sign that redirect information? How will we decrypt/validate it after redirection from the auth server?
1. The client takes the page from which the login was triggered, stores it in a JWT, signs the JWT using a private key stored on the client. 2. The client redirects the user to the authorization server with the authorization request and adds the JWT as the value of the state parameter. 3. When the authorization server redirects the user back to the client (more precisely to the redirect URI), the state parameter (containing the JWT) is sent along with the code. 4. The client verifies the signature of the JWT in the state parameter to ensure it was originally issued by itself. 5. The client redeems the code for tokens and OAuth flow is finished. 6. The client can finally redirect the user to the page stored in the JWT and be sure the page stored within was not tampered but added to the JWT by itself. Therefore, the client cannot be abused as an open redirector. This is the main goal of protecting the state with a signature.
If the key is stored somewhere (browser storage, backend, whatever), then no need to pass that state information anyway.
I don't understand this statement. The benefit of not storing the state of all users on the server-side is still present. The client only needs to store and use *one *key-pair for all JWTs.
And we're back to our first problem: why would my application trust that stored information more than the redirect_uri, both needing validation anyway?I am not sure what your "application" 's role is in this case. The client or the authorization server?
The validation of the JWT in the state is the responsibility of the client; the validation of the redirect URI is the responsibility of the authorization server.
The client trusts the JWT in the state parameter because it has a valid signature created by itself. The authorization server does not inspect the state parameter at all, but simply sends it back to the client.
If the authorization server allows wildcards in redirect URIs you *could *also include the JWT in the redirect URI instead of using the state parameter. However, as you noted in your initial question, authorization servers should not allow wildcards.
On 07.03.2023 14:25, Yannick Majoros wrote:
But what would encrypt or sign that redirect information? How will we decrypt/validate it after redirection from the auth server? If the key is stored somewhere (browser storage, backend, whatever), then no need to pass that state information anyway. And we're back to our first problem: why would my application trust that stored information more than the redirect_uri, both needing validation anyway?Could be me, but I'm not seeing a solution for my problem yet.Le mar. 7 mars 2023 à 09:55, Karsten Meyer zu Selhausen <karsten.meyerzuselhau...@hackmanit.de> a écrit :- In a context where all redirect URIs are under our control, how is passing state and validating it back after login better, from a security point of view, than validating redirect uri in the routing implementation of the application? Both sound equally secure to me, though redirect_uri seems much easier to implement.There have been multiple problems in the past with non-strict redirect URIs. In short: Validation of flexible redirect URIs is complex and error prone. For example, this presentation shows many past issues in URL parsers: https://i.blackhat.com/asia-19/Fri-March-29/bh-asia-Wang-Make-Redirection-Evil-Again.pdf The advantage of using the state parameter for redirect information was mentioned by Vittorio: You can sign (and optionally encrypt) the redirect information to protect it against tampering (e.g., by using a JWT in the state parameter).- How can I implement that use case easily: after login, redirecting the user back to the originally requested page, including parameters? Is that somehow covered in the document you provided, or somewhere else?One possible solution: Store the redirect information in a signed JWT and place the JWT in the state parameter. I don't think this is written somewhere in the security BCP but I think this is a solutions used in the wild by multiple clients.- And regarding that document, isn't 4.1.1 easily mitigated by PKCE anyway?PKCE mitigates that an attacker can redeem a stolen code, but there are other issues. As Aaron pointed out open redirectors are a severe issue for web applications in general, not just in OAuth-related attacks like stealing codes or tokens. Think of the following example: Assume a user receives a phishing email. They are aware of such threats and inspect the URLs in the email before visiting them. Therefore, the user does not visit links to unknown website such as https://attacker.example. However, this link is to a legitimate website the user knows and the user clicks on the link: https://somesite.example/auth?response_type=code&...&redirect_uri=https://attacker.example <https://somesite.example/auth?response_type=code&...&redirect_uri=https://attacker.example> When the user is redirected to https://attacker.example a malicious copy of the legitimate site is shown. The user might not recognize the redirect to a different domain and ends up using the phishing website of an attacker. Best regards, Karsten On 06.03.2023 23:34, Yannick Majoros wrote:Hi Rodrigo, Thanks for the link. I'm already familiar with that document, but maybe you can point me to some part that I missed. My questions are: - In a context where all redirect URIs are under our control, how is passing state and validating it back after login better, from a security point of view, than validating redirect uri in the routing implementation of the application? Both sound equally secure to me, though redirect_uri seems much easier to implement. - How can I implement that use case easily: after login, redirecting the user back to the originally requested page, including parameters? Is that somehow covered in the document you provided, or somewhere else? - And regarding that document, isn't 4.1.1 easily mitigated by PKCE anyway? I'm currently under the impression that this is a very common and legitimate use case, but that it is somehow underspecified and that everyone is reimplementing a variant of state passing + custom redirection after login. I'm failing to understand how such an implementation, besides being non-standard anyway, would be better than redirect URI patterns, in a controlled context. More thoughts on that? Thanks, Yannick Le lun. 6 mars 2023, 22:08, Rodrigo Speller <rspel...@primosti.com.br> a écrit : Hi Yannick, There is a work-in-progress draft that touches many threats and best practices when implementing OAuth 2 [https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/21/]. I recommend that you read entire document, but, especially, about your questions, you may understand the threats about wildcards URL validation in section 4.1.1. This document also addresses some state threats and best practices. Rodrigo Speller Em seg., 6 de mar. de 2023 às 17:06, Yannick Majoros <yann...@valuya.be> escreveu: Hey Aaron, Sure, this is some kind of open redirector. I had a similar example with Uber. Still, those examples involve integrations with 3rd party applications. It also seems to me that they either imply implicit flow, or an authorization code not protected by PKCE. Aren't we mitigating these use cases anyway? So, I'm wondering: - How should I implement a redirection to the page which was requested before login (which optionally takes parameters)? I understand I can use some persisted state for that, but what then? Should the portal or company web site know about all application URLs underneath it, with all their parameters, to be able to validate them against a list? - How is that better, from a security point of view, than having a redirect to our domain, with a wildcard, making all applications that need some form of routing to validate their URLs? Le lun. 6 mars 2023 à 20:38, Aaron Parecki <aa...@parecki.com> a écrit : There is no situation in which supporting arbitrary redirects (whether from the OAuth redirect URI or within your own app) is a good idea. This is known as an Open Redirector, and is the basis of many attacks on OAuth as well as other things unrelated to OAuth. OWASP has a cheat sheet about this as well: https://cheatsheetseries.owasp.org/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.html There was an example published just last week of combining a wildcard redirect_uri with another open redirector to accomplish an account takeover. It's worth reading the writeup if you're curious about the implications of wildcard redirects within and outside of OAuth. https://salt.security/blog/traveling-with-oauth-account-takeover-on-booking-com Aaron On Mon, Mar 6, 2023 at 11:31 AM Yannick Majoros <yann...@valuya.be> wrote: Thanks for your input. All of that would be quite common indeed, but in what way is it better, from a security perspective, than redirect URIs with wildcards? Yannick Le lun. 6 mars 2023 à 18:28, Vittorio Bertocci <vitto...@auth0.com> a écrit : In my experience the most common solution, adopted by many SDKs, is based on 2. Where you redirect after you concluded the token acquisition ceremony is a private consideration for your app, that shouldn’t interfere with how the client is registered. Oauth offers you the chance to store and retrieve state, you can use that to save the initial requested URL and redirect to it after the fact. If you are concerned with injections, you can always sign/encryp the state to protect it from tampering. All of the above is mainstream, you can observe the traffic from popular SDKs to see how that works. HTH V. On Mon, Mar 6, 2023 at 09:12 Yannick Majoros <yann...@valuya.be> wrote: *This message originated outside your organization.* ------------------------------------------------------------------------ Hello, From my understanding, OAuth 2 as well as 2.1 do not allow for wildcards in redirect_uri . Now, a common requirement for a portal or company-wide website, where multiple applications are deployed, is to be able to login and come back to the page from which the login was triggered. How can this be achieved securely with OAuth? Some options: 1) passing a parameter, say /callback_uri/, around from auth request back to redirect from auth server. 2) storing some state, e.g. in session storage, and redirect after login 3) violating the specifications and just use a redirect uri with a wildcard in the last part (some implementations, like keycloak, allow that) 1) and 2) are kind of similar IMO: the application has to validate whatever context comes and redirect to the right page, akin to deep linking But then, outside of some extra validation, I'd prefer to have a standard mechanism (less bypassing the restrictions) as redirect uri than to reinvent the wheel for each application, which is what that kind of callback url does. Also, I'm not sure why that extra validation would improve things in practice: if there is a vulnerability in the application routing code leading to some vulnerable redirect, wouldn't it just be duplicated in that validation step? So, I'm tempted to go for 3, knowing we would have those mitigations: - checking at authorization server whether the redirect is to the same uri the request originally came from - PKCE will restrict reuse of the authorization code anyway What are your thoughts on how to implement that quite common feature? Best regards,-- Yannick MajorosValuya sprl _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth-- Yannick MajorosValuya sprl _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth-- Yannick MajorosValuya sprl _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth-- Karsten Meyer zu SelhausenSenior IT Security Consultant Phone: +49 (0)234 / 54456499 Web: https://hackmanit.de | IT Security Consulting, Penetration Testing, Security Training Save the date: 11.-12.5.2023. Join us in celebrating the 5th anniversary of RuhrSec - the IT security conference in Bochum:https://www.ruhrsec.de/2023 Hackmanit GmbH Universitätsstraße 60 (Exzenterhaus) 44789 Bochum Registergericht: Amtsgericht Bochum, HRB 14896 Geschäftsführer: Prof. Dr. Jörg Schwenk, Prof. Dr. Juraj Somorovsky, Dr. Christian Mainka, Prof. Dr. Marcus Niemietz -- Yannick Majoros Valuya sprl
-- Karsten Meyer zu Selhausen Senior IT Security Consultant Phone: +49 (0)234 / 54456499 Web: https://hackmanit.de | IT Security Consulting, Penetration Testing, Security Training Save the date: 11.-12.5.2023. Join us in celebrating the 5th anniversary of RuhrSec - the IT security conference in Bochum:https://www.ruhrsec.de/2023 Hackmanit GmbH Universitätsstraße 60 (Exzenterhaus) 44789 Bochum Registergericht: Amtsgericht Bochum, HRB 14896 Geschäftsführer: Prof. Dr. Jörg Schwenk, Prof. Dr. Juraj Somorovsky, Dr. Christian Mainka, Prof. Dr. Marcus Niemietz
OpenPGP_0x4535C0E7DB16F148.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
