Re: [OAUTH-WG] OAuth Redirection Attacks

Vittorio Bertocci <> Fri, 17 December 2021 19:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2FC583A09A6 for <>; Fri, 17 Dec 2021 11:55:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.086
X-Spam-Status: No, score=-2.086 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_NONE=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 jq2W2-mXAo72 for <>; Fri, 17 Dec 2021 11:55:37 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::b2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C2C583A09D4 for <>; Fri, 17 Dec 2021 11:55:37 -0800 (PST)
Received: by with SMTP id e136so9559768ybc.4 for <>; Fri, 17 Dec 2021 11:55:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rZi+k1wDF7I0vR/lePL4Bc5iOQD95uKFqldMVHB71Kw=; b=obuIsUFlbRrf8EbPrrMZNjMD20y0646pm4u73Ks5PlRPbpUKhun96h93/ZLJ6SIa2c Fvb6jv9i2dAjpubtwgXuoHyUydVCn82CncRBGdOyIlvUqXyFtapQ2EoMjWb6SSQ+Jq8L ETN9zpY6KasKzt0z0dKqlZf+9xkiF+6ADrlQ+7dVzZq06ZZPoPD7L29POZlEAuCEcHBm hdh8S8J4f7uRvQgz/Ss4kHcWWlmZbSaRLF0YBCmdDMh8jQBMaVvKHRihKS04E3SZuJPL 90QCWTleBzNoxLBdg+nO99znw8NXr6Gn18AG/xBNbHmqrU/rdBxaVWa9mnLEtfWOM6/6 VYvw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rZi+k1wDF7I0vR/lePL4Bc5iOQD95uKFqldMVHB71Kw=; b=FFVeRrbecclsZoluTJr8rkIXb2KdRAWFvGkh71/OqFWeat3aVi2MnE0bCMoKfzanQi WGsNbPVuHmV/Ns1ljP39Axk51fzCr8mBOhTHcVo0fgAENKGDS6MriGuYwRiKr1/EJMKO CIPzGylO62Cy6XICGZKSkHXp4yc5PCoGucEs2YstRec5KNfnPHh8hcOP7DHM1rQM3gHI WQZAiA8N607iG2/pSbee70eLVcS4ls479R4rdEFLgWBf5OIgeiFvpUu9YmaBJtO7t3Q5 9GmH+jO+YP+rrbiPfaajJTzZ0DRrI4lr0I3onSpzg4ExffELo+TEkdVQj+QW375QObL8 xgnw==
X-Gm-Message-State: AOAM533gmGaGSqAKbbD1DwfSkiVY8/Ov1/GyW0+hsfObHH0QdhbsCV+t FtKTIVmY3bzSIsudpmFVLvA0QfDtP11S5DpvoSM5GIgiBmo=
X-Google-Smtp-Source: ABdhPJzOpUnOydxzNS39DpEX1twVGp4IEN195L+uuZP9VNePADH7grtAw9AaZqg3Nqg3OF/dU6E6jcOO8AV76FQK548=
X-Received: by 2002:a25:8711:: with SMTP id a17mr6227034ybl.323.1639770935507; Fri, 17 Dec 2021 11:55:35 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Vittorio Bertocci <>
Date: Fri, 17 Dec 2021 11:55:24 -0800
Message-ID: <>
To: Warren Parad <>
Cc: Rifaat Shekh-Yusef <>, oauth <>
Content-Type: multipart/alternative; boundary="0000000000001fd53e05d35cec5c"
Archived-At: <>
Subject: Re: [OAUTH-WG] 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: Fri, 17 Dec 2021 19:55:48 -0000

The attack doesn't rely on redirecting to unregistered URLs, that's the
The goal of the attack is to circumvent phishing filters, by presenting a
URL from a legitimate domain (the AS) that eventually redirects to the
actual phishing URL. The actual phishing page doesn't need to target the
same authorization server, or an authorization server at all for that
An attacker can register a legitimate app on any authorization server as a
service, on their own tenant. The goal is just to have a starting URL that
phishing filters won't block, and the attacker is in full control of the
redirect URIs they register in their own tenant.

My take: it might be tricky to change the redirect on error behavior at
this point, but we should at least note the issue in the security
considerations/BCPs and possibly give some advice. For example, on top of
my head: AS should expose their endpoints on a domain dedicated to
OAuth/OIDC operations, and avoid using its top level domains (different
area/service, but think vs so that if a phishing
filter decides to block direct links to the issuing endpoints will only
impact things like IdP initiated flows (solvable by adding jumpstart
endpoints on the RP anyway, just like IdP initiated sign in works in OIDC).
I am sure there are lots of other things we can come up with that can make
the problem better.

On Fri, Dec 17, 2021 at 5:00 AM Warren Parad <wparad=> wrote:

> I think this just falls into the category of never redirect the user to a
> url that doesn't match one of the preregistered redirect urls (or logout
> urls for that matter). Any application that has redirects anywhere provides
> an opportunity for this attack vector, OAuth isn't unique in that way, it
> just is consistent and documented. And the 2.1 draft is pretty clear on
> this front:
>>    If the request fails due to a missing, invalid, or mismatching
>>    redirect URI, or if the client identifier is missing or invalid, the
>>    authorization server SHOULD inform the resource owner of the error
>>    and
>> *MUST NOT automatically redirect the user agent to the invalid   redirect
>> URI*.
> I want to call this attack vector "*illegitimate* phishing applications"
> which is easily blocked by preregistration and/or PARs. And is only a very
> small subset of phishing attacks with OAuth, of which the larger group is "
> *legitimate* phishing applications". An app can be registered correctly,
> and still issue a phishing attack as phishing attacks through OAuth are
> actually indistinguishable from standard user delegation. There is no way
> to prevent these without an application review before registration is
> completed, here's an example that cloned Google apps y creating a fake app
> called *google defender*:
> If we can't protect against these latter ones, I hardly think protecting
> against the former is useful/interesting/valuable.
> Warren Parad
> Founder, CTO
> Secure your user data with IAM authorization as a service. Implement
> Authress <>.
> On Thu, Dec 16, 2021 at 9:05 PM Rifaat Shekh-Yusef <
>> wrote:
>> All,
>> An article was recently published discussing some OAuth Redirection
>> Attacks to try to bypass phishing detection solutions. See the details
>> of these attacks in the following link:
>> The article discusses attacks on Microsoft and GitHub, but these attacks
>> are not unique to these companies.
>> The attacks take advantage of how OAuth handles error responses, which
>> sends responses to the application’s redirect URL.
>> I would like to get the thoughts of the working group on these types of
>> attacks.
>> What is the best way to mitigate these attacks?
>> Do we need a new approach for handling errors with OAuth?
>> Regards,
>>  Rifaat
>> _______________________________________________
>> OAuth mailing list
> _______________________________________________
> OAuth mailing list