k at scale (i.e. for broad
rather than targeted attacks), but domains are cheap. I'd rather see standards
try to fix this, than patch it with phishing filters.
Thanks,
Will
From: OAuth On Behalf Of Brian Campbell
Sent: Friday, December 17, 2021 1:44 PM
To: Hans Zandbelt
Cc: oauth
Subject: Re: [
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
Agreed. Most of dyn reg cases we were thinking about occurred because there was
a need to register each copy of the same client software. The software
statement was intended to allow the registration endpoint recognize software
and to fix things like endpoints.
Automatic registration of
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
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
> On Dec 17, 2021, at 2:44 PM, Brian Campbell
> 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
Phishing filters can simply handle all OAuth AuthZ request like URLs in emails
malicious.
> 2021/12/18 6:45、Brian Campbell
> のメール:
>
>
> Yeah, I think it has been discussed before. And if I'm understanding
> correctly, it is unfortunately a tricky area. It sounds like more or less the
>
Yeah, I think it has been discussed before. And if I'm understanding
correctly, it is unfortunately a tricky area. It sounds like more or less
the same thing as "Abuse: The Authorization Server As Open Redirector"
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 wrote:
> The problem isn’t invalid URLs but malicious ones. Given a choice between
> a sub-optimal user experience
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
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
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
12 matches
Mail list logo
