I think there are two options: 1) validation of the organization/person behind a certain client in order to be able to go after them in case of abuse 2) don’t redirect in an error condition
However, even a successful OAuth process can result in a phishing attack. So I don‘t think (2) will help entirely. Treating OAuth authorization links as phishing attempts sounds reasonable to me. > Am 18.12.2021 um 16:25 schrieb Warren Parad > <wparad=40rhosys...@dmarc.ietf.org>: > > > I also 100% with the recommendation for phishing detectors treat all > perceived OAuth links as malicious in emails. It actually isn't hard to know > that there is a link embedded in a url query parameter. So I would just take > the next step of treating all urls with urls as query parameters as malicious. > > There are exactly zero reasons why a site can't use it's own javascript > redirection unless it's domain has been marked as malicious. The only > conceivable reason is a third party is providing tracking as a service, and > then that's even a better reason to potentially block these. > > Phishing can still use PKCE and PAR, nor does WebAuthN provide protection > from this problem. > > > Warren Parad > Founder, CTO > Secure your user data with IAM authorization as a service. Implement Authress. > > >> On Sat, Dec 18, 2021 at 4:11 PM George Fletcher >> <gffletch=40aol....@dmarc.ietf.org> wrote: >> Given the attack is based on a successfully registered callback URL that >> is malicious, we can also look to the Authorization Server to run more >> checks on the registered callback URLs (e.g. check against the "unsafe" >> URL list). Not a 100% solution by any means but could help with reduce >> the impact. Additionally, making sure the AS can easily revoke any >> client_id and have that take effect quickly. >> >> Another potential option would be to not allow prompt=none (or automatic >> redirects) from contexts where the user hasn't first gone through a full >> authentication flow or at least allow the AS to display UI at it's >> discretion. Though this will definitely break some flows :( >> >> This at least illuminates one of the dangers of allowing a wide open >> dynamic client registration model :) >> >> Thanks, >> George >> >> On 12/18/21 1:11 AM, David Waite wrote: >> > >> >> On Dec 17, 2021, at 2:44 PM, Brian Campbell >> >> <bcampbell=40pingidentity....@dmarc.ietf.org> wrote: >> >> >> >> Relax how aggressively OAuth demands that the AS automatically redirect >> >> in error conditions. And either respond with a 400 directly (which just >> >> stops things at that point) or provide a meaningful interstitial page to >> >> the user before redirecting them (which at least helps users see >> >> something is amiss). I do think OAuth is a bit overzealous in >> >> automatically returning the user's browser context to the client in error >> >> conditions. There are some situations (like prompt=none) that rely on the >> >> behavior but in most cases it isn't necessary or helpful and can be >> >> problematic. >> > The problem is that if prompt=none still requires redirection without >> > prompt or interstitial, someone wishing to treat dynamic registrations of >> > malicious sites as clients will just start using prompt=none. Likewise, a >> > site could still attempt to manipulate the user to release information by >> > imitating an extension to the authentication process, such as an "expired >> > password change" prompt. >> > >> > I agree with Nov Matake's comment - phishing link email filters should >> > treat all OAuth URLs as suspect, as OAuth has several security-recommended >> > features like state and PKCE which do not work as expected/reliably with >> > email. Filters integrated into the browser (such as based on the unsafe >> > site list in Chrome) should not need changes, as they will warn on >> > redirect to the known malicious site. >> > >> > We should also continue to push as an industry for authentication >> > technologies like WebAuthn (as well as mutual TLS and Kerberos) which are >> > phishing resistant. We are really talking about failure of a single >> > phishing mitigation for _known_ malicious sites - the opportunity to use >> > any unknown malicious site or a compromised legitimate site remains open >> > even if we do suggest changes to error behavior. >> > >> > -DW >> > >> > _______________________________________________ >> > 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 > _______________________________________________ > 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
