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 list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
