Re: [OAUTH-WG] [EXTERNAL] Re: OAuth Redirection Attacks

Warren Parad <wparad@rhosys.ch> Sat, 18 December 2021 15:25 UTC

Return-Path: <wparad@rhosys.ch>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4446D3A0FC4 for <oauth@ietfa.amsl.com>; Sat, 18 Dec 2021 07:25:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.088
X-Spam-Level:
X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rhosys.ch
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eHRuiKFyx9QQ for <oauth@ietfa.amsl.com>; Sat, 18 Dec 2021 07:24:58 -0800 (PST)
Received: from mail-yb1-xb34.google.com (mail-yb1-xb34.google.com [IPv6:2607:f8b0:4864:20::b34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DC613A0FC7 for <oauth@ietf.org>; Sat, 18 Dec 2021 07:24:57 -0800 (PST)
Received: by mail-yb1-xb34.google.com with SMTP id q74so14917605ybq.11 for <oauth@ietf.org>; Sat, 18 Dec 2021 07:24:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhosys.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bJ2yD2bKXOf/mTlPf5tlTavgbhWgj2zKHm6Ilb3hNE4=; b=U4BIhK8pklY51tIFvc0aBVdoyH/idp8/bOcSQZHQEi0uDE2HxzFWrDlqb6kskVR8FN PixPexrhQ7NwdWv/g/xAw1SqVV9cYXT+duv6QvtKNmKRsisthMtuKXJLEp9fxdihYGtg qRetAt75fROUJeuS7cJeslXSvVEKJjLg6IR3sxBtMXcKi+uCjsqA0e+Wa8BEIA4jBDVW PAoTyd7E9Z0UbmgVbshp0KONiU8JqRB+cljQwtFKdFtRLSFoZzVUlgon2qkY7dn8kle6 HJTU9QRGsUuTI4IBWh8ioERDYR2teNUn8S9vwgaC5C6QN6nca9Vl7smyPuH7i2v1rdan jnGQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bJ2yD2bKXOf/mTlPf5tlTavgbhWgj2zKHm6Ilb3hNE4=; b=S8tEAt7yY8ip25g+hYH2a7rVOJ4/9C9/Qk1Tp8gk+8jyo77gn+1IpJIZWsSB3ynxIQ /PTkfyfU4GXP+BvEKJH6Byz96TZTtDZTTIofZGzYxNCFP+n5ereKjVMpcPJBYFe5aNUa wrkt6rm/J5eL0CK+mx+lYIlwLPTf/GBcR3BXv40X7W3LZBBAi5PhMiVRL/3ScPXHo5uD QJqVNjG4X1PuZWmNOI29giomhaod2pdT8tbpWaO4bw3+QjsgFLbDumgxpZXdK/Rx6FFm D1qSZnrLU+C13NKzhLHMvoQZiP2xATeekHUX2ojYoFLiu3DDf6TagtuNRHzsCHU6z7du ICyw==
X-Gm-Message-State: AOAM531J+Bs0xtFotP0SHrCe4R2gDNddpnD/j+0F+GZDl2Xh8Ew5W7gk EQzFHbbw61O6HhulLFn5riojZSJkIb3qH1vyzDD8
X-Google-Smtp-Source: ABdhPJxLBgQxzVDTt8FUXon+F3/xgz+76fc6uJJX5z/Zf8EVRtpFCeR0lVYwzUMNrEMlrfqKVp+hMCQ8H8nF6LGF5Y4=
X-Received: by 2002:a25:6b4a:: with SMTP id o10mr10642839ybm.660.1639841095835; Sat, 18 Dec 2021 07:24:55 -0800 (PST)
MIME-Version: 1.0
References: <CADNypP_AJFBc+HzKfFZ8d0hk7BZc=fYTDLNP6MroHUg-=r7FvQ@mail.gmail.com> <CAJot-L2X+Ma5BnXJ6Ys3UPJgHc_WnYtU33ast-myT2PN6rU5OQ@mail.gmail.com> <CAO_FVe5fUgS+=FoB9fJN7V0ujG+tDSb_20CgU2ffcPO3kENC=w@mail.gmail.com> <AM7PR83MB04521F9B225816B5D4D1A8F891789@AM7PR83MB0452.EURPRD83.prod.outlook.com> <CAJot-L2jB63K9RVK8F8PFEtOSXjJk+Eg4iJxs9qm7jt7zq1nMw@mail.gmail.com> <AM7PR83MB0452B729482E04F9B333D37791789@AM7PR83MB0452.EURPRD83.prod.outlook.com> <CA+iA6ujXrAqm5bY-akQyB3seD7zhZg1K26AnViOE2cHGEAvEoA@mail.gmail.com> <CA+k3eCS2jNEj4nePQ4kzsvERGnTAw_kimkym1v=a=xFQJG78NA@mail.gmail.com> <FB2B5751-C124-4400-953D-202C8D726350@alkaline-solutions.com> <4bb64d61-6e79-3c3a-1166-a322dd3089a1@aol.com>
In-Reply-To: <4bb64d61-6e79-3c3a-1166-a322dd3089a1@aol.com>
From: Warren Parad <wparad@rhosys.ch>
Date: Sat, 18 Dec 2021 16:24:45 +0100
Message-ID: <CAJot-L3Sc2RaUtQGMjd9As7=ACBrXiVXSp-pRKQrLYdroXD8UA@mail.gmail.com>
To: George Fletcher <gffletch=40aol.com@dmarc.ietf.org>
Cc: David Waite <david=40alkaline-solutions.com@dmarc.ietf.org>, Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>, oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000000179ed05d36d4235"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/DmUaP_okR6uQivshw5PnoLoLkOM>
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: OAuth Redirection Attacks
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 18 Dec 2021 15:25:04 -0000

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 <https://authress.io/>.


On Sat, Dec 18, 2021 at 4:11 PM George Fletcher <gffletch=
40aol.com@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.com@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
>