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 > > 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 Majoros >>>>>>> Valuya sprl >>>>>>> >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> >>>>>> >>>>> >>>>> -- >>>>> Yannick Majoros >>>>> Valuya sprl >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>> >>> >>> -- >>> Yannick Majoros >>> Valuya sprl >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > -- > 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 > > -- Yannick Majoros Valuya sprl
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
