AFAIK this topic has been discussed before, e.g.: https://mailarchive.ietf.org/arch/msg/oauth/gIuIrxeXudRBg8L6RYGDElxrc4s/
Hans. On Fri, Dec 17, 2021 at 9:44 PM Pieter Kasselman <pieter.kasselman= 40microsoft....@dmarc.ietf.org> wrote: > The problem isn’t invalid URLs but malicious ones. Given a choice between > a sub-optimal user experience and a phished end-user, perhaps an option > that allows the authorization server to handle the error, rather than > redirecting can serve end-users better. But as Vittorio points, out, there > are probably other options as well to consider. URL reputation services is > another option, but problematic since they are imperfect and I expect hard > to standardise to a point that creates a common minimum level of assurance > (similar to any fraud calculation or risk score). > > > > *From:* Warren Parad <wparad=40rhosys...@dmarc.ietf.org> > *Sent:* Friday 17 December 2021 20:27 > *To:* Pieter Kasselman <pieter.kassel...@microsoft.com> > *Cc:* Vittorio Bertocci <vitto...@auth0.com>; oauth <oauth@ietf.org> > *Subject:* Re: [EXTERNAL] Re: [OAUTH-WG] OAuth Redirection Attacks > > > > You want to redirect on some errors because the last thing an AS wants is > to leave the user in the AS because the user can't do anything there and > the AS can't do anything either. It's just bad UX. But if the redirect url > isn't valid, this is absolutely the time that the AS should keep the user > there for user's protection. Any AS redirecting the user to an invalid > redirect url, isn't doing the right thing. > > > > But that only solves the illegitimate phishing urls, it doesn't solve the > class of problem where a phishing application is legitimately registered. > > > [image: Image removed by sender.] > > *Warren Parad* > > Founder, CTO > > Secure your user data with IAM authorization as a service. Implement > Authress > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthress.io%2F&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C10cc087500b9437ac09408d9c19b9d90%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637753696441984307%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=bD0m3JF8HeDpcw65ZHO4H29FaU2Lc6rvGwxr%2FzF52w0%3D&reserved=0> > . > > > > > > On Fri, Dec 17, 2021 at 9:23 PM Pieter Kasselman <pieter.kasselman= > 40microsoft....@dmarc.ietf.org> wrote: > > Agreed that the attackers goal is to bypass phishing filters and they > found a way to achieve this by using an IdP that adheres to the standards. > I don’t have the context for the design choice to redirect on an error > condition, but am curious why the IdP should not be allowed to handle the > error condition, rather than redirect (or at least have the option to do > so)? > > > > *From:* OAuth <oauth-boun...@ietf.org> *On Behalf Of *Vittorio Bertocci > *Sent:* Friday 17 December 2021 19:55 > *To:* Warren Parad <wparad=40rhosys...@dmarc.ietf.org> > *Cc:* oauth <oauth@ietf.org> > *Subject:* [EXTERNAL] Re: [OAUTH-WG] OAuth Redirection Attacks > > > > The attack doesn't rely on redirecting to unregistered URLs, that's the > problem. > > The goal of the attack is to circumvent phishing filters, by presenting a > URL from a legitimate domain (the AS) that eventually redirects to the > actual phishing URL. The actual phishing page doesn't need to target the > same authorization server, or an authorization server at all for that > matter. > > An attacker can register a legitimate app on any authorization server as a > service, on their own tenant. The goal is just to have a starting URL that > phishing filters won't block, and the attacker is in full control of the > redirect URIs they register in their own tenant. > > > > My take: it might be tricky to change the redirect on error behavior at > this point, but we should at least note the issue in the security > considerations/BCPs and possibly give some advice. For example, on top of > my head: AS should expose their endpoints on a domain dedicated to > OAuth/OIDC operations, and avoid using its top level domains (different > area/service, but think herokuapp.com > <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fherokuapp.com%2F&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C10cc087500b9437ac09408d9c19b9d90%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637753696441984307%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=6oiRh6TMVJnXYUGdDJt%2BLQQI0gCtOs7au%2BU7ctOd%2Bjo%3D&reserved=0> > vs heroku.com > <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fheroku.com%2F&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C10cc087500b9437ac09408d9c19b9d90%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637753696441984307%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=egS2AEI1FmpbL09upMutgGCUtpgyEn2l1FtdDb7WCdI%3D&reserved=0>) > so that if a phishing filter decides to block direct links to the issuing > endpoints will only impact things like IdP initiated flows (solvable by > adding jumpstart endpoints on the RP anyway, just like IdP initiated sign > in works in OIDC). I am sure there are lots of other things we can come up > with that can make the problem better. > > > > On Fri, Dec 17, 2021 at 5:00 AM Warren Parad <wparad= > 40rhosys...@dmarc.ietf.org> wrote: > > I think this just falls into the category of never redirect the user to a > url that doesn't match one of the preregistered redirect urls (or logout > urls for that matter). Any application that has redirects anywhere provides > an opportunity for this attack vector, OAuth isn't unique in that way, it > just is consistent and documented. And the 2.1 draft is pretty clear on > this front: > > > > > https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-04#section-4.1.2.1 > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-oauth-v2-1-04%23section-4.1.2.1&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C10cc087500b9437ac09408d9c19b9d90%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637753696441984307%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=M7ZtR%2BTYVIVzXZmHaeJS6rGVLC84RUisnfl5KCF0rHg%3D&reserved=0> > > If the request fails due to a missing, invalid, or mismatching > redirect URI, or if the client identifier is missing or invalid, the > authorization server SHOULD inform the resource owner of the error > and > *MUST NOT automatically redirect the user agent to the invalid redirect > URI*. > > > > I want to call this attack vector "*illegitimate* phishing applications" > which is easily blocked by preregistration and/or PARs. And is only a very > small subset of phishing attacks with OAuth, of which the larger group is " > *legitimate* phishing applications". An app can be registered correctly, > and still issue a phishing attack as phishing attacks through OAuth are > actually indistinguishable from standard user delegation. There is no way > to prevent these without an application review before registration is > completed, here's an example that cloned Google apps y creating a fake app > called *google defender*: > https://www.trendmicro.com/en_us/research/17/d/pawn-storm-abuses-open-authentication-advanced-social-engineering-attacks.html > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.trendmicro.com%2Fen_us%2Fresearch%2F17%2Fd%2Fpawn-storm-abuses-open-authentication-advanced-social-engineering-attacks.html&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C10cc087500b9437ac09408d9c19b9d90%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637753696441984307%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=9kKah9zgc66ew2AD5iGhgX2Qnzbnq3UJ%2FHoHsuzUU5w%3D&reserved=0> > > > > If we can't protect against these latter ones, I hardly think protecting > against the former is useful/interesting/valuable. > > > [image: Image removed by sender.] > > *Warren Parad* > > Founder, CTO > > Secure your user data with IAM authorization as a service. Implement > Authress > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthress.io%2F&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C10cc087500b9437ac09408d9c19b9d90%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637753696441984307%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=bD0m3JF8HeDpcw65ZHO4H29FaU2Lc6rvGwxr%2FzF52w0%3D&reserved=0> > . > > > > > > On Thu, Dec 16, 2021 at 9:05 PM Rifaat Shekh-Yusef < > rifaat.s.i...@gmail.com> wrote: > > All, > > > > An article was recently published discussing some *OAuth Redirection > Attacks* to try to bypass *phishing* detection solutions. See the details > of these attacks in the following link: > > > > > https://www.proofpoint.com/us/blog/cloud-security/microsoft-and-github-oauth-implementation-vulnerabilities-lead-redirection > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.proofpoint.com%2Fus%2Fblog%2Fcloud-security%2Fmicrosoft-and-github-oauth-implementation-vulnerabilities-lead-redirection&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C10cc087500b9437ac09408d9c19b9d90%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637753696441984307%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=itNmcvlkuKrPzG6%2F23Iod8zyH%2FqSjhcNuxJMw3dZslU%3D&reserved=0> > > > > > > The article discusses attacks on Microsoft and GitHub, but these attacks > are not unique to these companies. > > The attacks take advantage of how OAuth handles error responses, which > sends responses to the application’s redirect URL. > > > > I would like to get the thoughts of the working group on these types of > attacks. > > What is the best way to mitigate these attacks? > > Do we need a new approach for handling errors with OAuth? > > > > Regards, > > Rifaat > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C10cc087500b9437ac09408d9c19b9d90%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637753696442034307%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=9S1YCx61RDItp9TtylYb4bgxMTABCZJ9MbjwUHV%2FStM%3D&reserved=0> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C10cc087500b9437ac09408d9c19b9d90%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637753696442034307%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=9S1YCx61RDItp9TtylYb4bgxMTABCZJ9MbjwUHV%2FStM%3D&reserved=0> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- hans.zandb...@zmartzone.eu ZmartZone IAM - www.zmartzone.eu
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
