Re: [OAUTH-WG] OAuth Redirection Attacks

Warren Parad <> Fri, 17 December 2021 13:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 793363A0E41 for <>; Fri, 17 Dec 2021 05:00:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.088
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=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lEMoK9tnXWjE for <>; Fri, 17 Dec 2021 05:00:11 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::b36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 98F833A0E3C for <>; Fri, 17 Dec 2021 05:00:11 -0800 (PST)
Received: by with SMTP id d10so6216169ybe.3 for <>; Fri, 17 Dec 2021 05:00:11 -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=5nW4f0At8oP1PFG7Zc6wCx6D4bLQ1blfDXhvoAaRpEg=; b=WCzx3NxckRoaysS5ZIwgcZ6W2zm+OQQsMTuciC9OzRJA3s3bynRAb/akM9tqKOFo2E vwQHKVHqZZQONPektRI+Yv98pDB43b5syByXIrUZkX44JrgS0TMpU9Jtbxd2GV6xD+KJ ZoqVln12zszEzMQErQTBJwtOdB8ctpl3WOkAdaHbIRyVXHkKdI7jbq6jOi3P9EASBWLG 6Z1aHzAzFfN8jEwpnwe9xr2Ni6rTtCZLjHiGArbIoD/xgG4SqKz/fWwWnzgg0kqRAYVh YIRDDwoxmdKsOkcs9uCrxouCGweRMxRrJFFl9ZmJlOLkzAD1hJLgh166aVR0eZYanyY1 UWuA==
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=5nW4f0At8oP1PFG7Zc6wCx6D4bLQ1blfDXhvoAaRpEg=; b=S5CmGZIbZi4+I0PWRBZ34rKb09Q2/KkYTDQ6oAcbHr9G3YRQe/Wc9rYJDXWGma8FmC vGvRgHx4vjLvpgdfbMKjB5QUkn2REc296zvE31ww9X4ac7Jk82HTHo2co1AjI5Ji1brJ Wk23t7GIcBWDASQbHItGC9rAw1Yh0QsrzwpGemJOcRnpdNDs0kZIFgSJ6hFDygq6+5Cr vk8pZvDnGb1/xFblGtUXfyuPqbUBukIsj9cJCeqnUtUpglFexjlZQF/Tvg1LIYedAmIw h6Ic5zhnr8P7f2NjTXyc76Aj5QiZQrD8GrSk6T9agMCdutkvA5Gj/dy7wYYcRuj/xxKt 3ytQ==
X-Gm-Message-State: AOAM530/SCZxGDTQR8+3nyj8vZE42g1OJ65tXTlsXJWArfMMfTNCv1al qJlgWx7dS2978I99TDx41S2omjXC+gy4CDeg+Dch8sAVq4QE
X-Google-Smtp-Source: ABdhPJzbUH0WiOquSYdgQH9pDL3ZBVaFu2S5siazRlpSiyLfoN2WQB90OvvCpTLR7r04ZB0LjfKl8HeyE6GYGFyMh+8=
X-Received: by 2002:a25:6744:: with SMTP id b65mr3995651ybc.57.1639746007417; Fri, 17 Dec 2021 05:00:07 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Warren Parad <>
Date: Fri, 17 Dec 2021 13:59:56 +0100
Message-ID: <>
To: Rifaat Shekh-Yusef <>
Cc: oauth <>
Content-Type: multipart/alternative; boundary="0000000000004b643805d3571eff"
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 13:00:17 -0000

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 <>

> 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