Hi Nat, I have a few text suggestions for the abstract and the intro.
FROM:
Abstract
The OAuth 2.0 public client utilizing Authorization Code Grant (RFC
6749 - 4.1) is susceptible to the code interception attack. This
specification describes a mechanism that acts as a control against
this threat.
TO:
Abstract
OAuth 2.0 public clients utilizing the Authorization Code Grant are
susceptible to the authorization code interception attack. This
specification
describes the attack as well as a technique to mitigate against the
threat.
New text for the into:
1. Introduction
OAuth 2.0 [RFC6749] public clients are susceptible to the
authorization code interception attack.
The attacker thereby intercepts the authorization code returned
from the authorization endpoint within communication path not
protected by TLS, such as inter-app communication within the
operating system of the client.
Once the attacker has gained access to the authorization code it
can use it to obtain the access token.
Figure 1 shows the attack graphically. In step (1) the native
app running on the end device, such as a smart phone, issues
an authorization request via the browser/operating system, which
then gets forwarded to the OAuth 2.0 authorization server in
step (2). The authorization server returns the authorization code
in step (3). The malicious app is able to observe the
authorization code in step (4) since it is registered to the
custom URI scheme used by the legitimate app. This allows the
attacker to reguest and obtain an access token in step (5)
and step (6), respectively.
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
| End Device (e.g., Smart Phone) |
| |
| +-------------+ +----------+ | (6) Access Token +----------+
| |Legitimate | | Malicious|<--------------------| |
| |OAuth 2.0 App| | App |-------------------->| |
| +-------------+ +----------+ | (5) Authorization | |
| | ^ ^ | Grant | |
| | \ | | | |
| | \ (4) | | | |
| (1) | \ Authz| | | |
| Authz| \ Code | | | Authz |
| Request| \ | | | Server |
| | \ | | | |
| | \ | | | |
| v \ | | | |
| +----------------------------+ | | |
| | | | (3) Authz Code | |
| | Operating System/ |<--------------------| |
| | Browser |-------------------->| |
| | | | (2) Authz Request | |
| +----------------------------+ | +----------+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
Figure 1: Authorization Code Interception Attack.
A number of pre-conditions need to hold in order for this attack
to work:
1) The attacker manages to register a malicious application on
the client device and registers a custom URI scheme that is
also used by another application.
The operating systems must allow a custom URI schemes to
be registered by multiple applications.
2) The OAuth 2.0 authorization code grant is used.
3) The attacker has access to the client id. All native app
client-instances use the same client id. No client secret is
used (since public clients cannot keep their secrets
confidential.)
4) The attacker (via the installed app) is able to observe
responses from the authorization endpoint. As a more
sophisticated attack scenario the attacker is also able
to observe requests (in addition to responses) to the
authorization endpoint. The attacker is, however, not
able to act as a man-in-the-middle.
While this is a long list of pre-conditions the described attack
has been observed in the wild and has to be considered in
OAuth 2.0 deployments. While Section 4.4.1 of [RFC6819] describes
mitigation techniques they are, unfortunately, not applicable
since they rely on a per-client instance secret or aper client
instance redirect URI.
Ciao
Hannes
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
