Thanks Hannes! Nat On Wed Nov 19 2014 at 21:49:07 John Bradley <ve7...@ve7jtb.com> wrote:
> Hannes, > > Thanks for the feedback. I will go over it today. > > > > On Nov 19, 2014, at 7:44 AM, Hannes Tschofenig < > hannes.tschofe...@gmx.net> wrote: > > > > 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 > > > > > > _______________________________________________ > > 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 >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
