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
