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

Torsten Lodderstedt <> Sun, 19 December 2021 09:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8C1343A00E0 for <>; Sun, 19 Dec 2021 01:09:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Status: No, score=-2.087 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, MIME_QP_LONG_LINE=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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OslzxJcj7iob for <>; Sun, 19 Dec 2021 01:08:56 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::32c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 10D163A00E1 for <>; Sun, 19 Dec 2021 01:08:56 -0800 (PST)
Received: by with SMTP id i12so4807812wmq.4 for <>; Sun, 19 Dec 2021 01:08:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=eRIa7KwWRcLkLgF3k9mVXFhmJ/6/fRo7YK53v0wJcbg=; b=mtnvM3Eg8NTE6CSF8cSumayBN4KlvutQ6xdpA8kpxTnStGI5zw+KBB8hzk/HYD+nuz Ouh6df+b7z5GVBYT2PVHcdcyIY8sqpWRTbdYN54NDbixzqHStU7GPRGBMFX7SsgJqhC2 RqsLJSjwsuWDapnq7tpHbqN1F3mHtnbHXdiORsaGRqqtSX90gCvo2pMYnQpiG7dFaPBj cbg3S6yV3opLWMlBti5avfGSn3cO0cYgMLNgibncZ5G1JzGzCIAmz/Vqnjny0hgyFcUD CFDAU8KEhf1M5uSYOHeFQjdwLcmFL5V2ME0jfwHVGxOZ+8S24kV7G7RMcORvoxLENem3 qqDw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=eRIa7KwWRcLkLgF3k9mVXFhmJ/6/fRo7YK53v0wJcbg=; b=gNTZO0q45CUvwKDHk8COz3+PYqtaOTjD/tnzcCyjTSwSch+RrOf4iuuoGLHx5KFQz8 IP29vrzElBygIfcpUrJaDpJxtnQjLgNIDjdtE8aFNpHsN0oaPIYwrwYkUx8JXhtMJEq7 59jPiCchlZ5bV/N4j79sn6xw+cGqCtYxj1z3qGh1PnEklrBk55SHvBXhRRMDY0ms7rb+ uZxgU//vDvoz9FaN74F2BQIcv7jWEx7cZRwanruN0RE+BkLNV/pIA8SR2h+8WDsbBU3F GvMDYEJNbnnGH5owQnxPRSp9k/bjsz5lrOF7ZruFYMbsi7YKFoYaxfpmW5a9VYfc5tf8 pd+w==
X-Gm-Message-State: AOAM530CrX+2eWUGlR3TvPnNi1ejpqo3TnOyx+pJI3Fp5fDYd2x6FfGz BkpzSjlgU8UZxIwBmMhA3g3TcA==
X-Google-Smtp-Source: ABdhPJyBdWW01cXjov+4DXuR88OEV5wlK1QQG+dDgJ7JPEmSg4UMibhgxBcwz+oGmehi6lxuwOWuzA==
X-Received: by 2002:a1c:1dd0:: with SMTP id d199mr16704956wmd.150.1639904933193; Sun, 19 Dec 2021 01:08:53 -0800 (PST)
Received: from ( []) by with ESMTPSA id 10sm15071159wrb.75.2021. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 19 Dec 2021 01:08:52 -0800 (PST)
Content-Type: multipart/alternative; boundary=Apple-Mail-9AACA11F-59A4-45C6-BFD0-22E8B9186972
Content-Transfer-Encoding: 7bit
From: Torsten Lodderstedt <>
Mime-Version: 1.0 (1.0)
Date: Sun, 19 Dec 2021 10:08:52 +0100
Message-Id: <>
References: <>
Cc: George Fletcher <>, David Waite <>, Brian Campbell <>, oauth <>
In-Reply-To: <>
To: Warren Parad <>
X-Mailer: iPhone Mail (19C56)
Archived-At: <>
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: OAuth Redirection Attacks
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 19 Dec 2021 09:09:02 -0000

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 <>:
> 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 <> 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 <> 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 mailing list
> _______________________________________________
> OAuth mailing list