Tech-invite3GPPspaceIETF RFCsSIP
93929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6819

OAuth 2.0 Threat Model and Security Considerations

Pages: 71
Informational
Errata
Part 2 of 3 – Pages 15 to 44
First   Prev   Next

Top   ToC   RFC6819 - Page 15   prevText

4. Threat Model

This section gives a comprehensive threat model of OAuth 2.0. Threats are grouped first by attacks directed against an OAuth component, which are the client, authorization server, and resource server. Subsequently, they are grouped by flow, e.g., obtain token or access protected resources. Every countermeasure description refers to a detailed description in Section 5.
Top   ToC   RFC6819 - Page 16

4.1. Clients

This section describes possible threats directed to OAuth clients.

4.1.1. Threat: Obtaining Client Secrets

The attacker could try to get access to the secret of a particular client in order to: o replay its refresh tokens and authorization "codes", or o obtain tokens on behalf of the attacked client with the privileges of that "client_id" acting as an instance of the client. The resulting impact would be the following: o Client authentication of access to the authorization server can be bypassed. o Stolen refresh tokens or authorization "codes" can be replayed. Depending on the client category, the following attacks could be utilized to obtain the client secret. Attack: Obtain Secret From Source Code or Binary: This applies for all client types. For open source projects, secrets can be extracted directly from source code in their public repositories. Secrets can be extracted from application binaries just as easily when the published source is not available to the attacker. Even if an application takes significant measures to obfuscate secrets in their application distribution, one should consider that the secret can still be reverse-engineered by anyone with access to a complete functioning application bundle or binary. Countermeasures: o Don't issue secrets to public clients or clients with inappropriate security policy (Section 5.2.3.1). o Require user consent for public clients (Section 5.2.3.2). o Use deployment-specific client secrets (Section 5.2.3.4). o Revoke client secrets (Section 5.2.3.6).
Top   ToC   RFC6819 - Page 17
   Attack: Obtain a Deployment-Specific Secret:

   An attacker may try to obtain the secret from a client installation,
   either from a web site (web server) or a particular device (native
   application).

   Countermeasures:

   o  Web server: Apply standard web server protection measures (for
      config files and databases) (see Section 5.3.2).

   o  Native applications: Store secrets in secure local storage
      (Section 5.3.3).

   o  Revoke client secrets (Section 5.2.3.6).

4.1.2. Threat: Obtaining Refresh Tokens

Depending on the client type, there are different ways that refresh tokens may be revealed to an attacker. The following sub-sections give a more detailed description of the different attacks with respect to different client types and further specialized countermeasures. Before detailing those threats, here are some generally applicable countermeasures: o The authorization server should validate the client id associated with the particular refresh token with every refresh request (Section 5.2.2.2). o Limit token scope (Section 5.1.5.1). o Revoke refresh tokens (Section 5.2.2.4). o Revoke client secrets (Section 5.2.3.6). o Refresh tokens can automatically be replaced in order to detect unauthorized token usage by another party (see "Refresh Token Rotation", Section 5.2.2.3). Attack: Obtain Refresh Token from Web Application: An attacker may obtain the refresh tokens issued to a web application by way of overcoming the web server's security controls. Impact: Since a web application manages the user accounts of a certain site, such an attack would result in an exposure of all refresh tokens on that site to the attacker.
Top   ToC   RFC6819 - Page 18
   Countermeasures:

   o  Standard web server protection measures (Section 5.3.2).

   o  Use strong client authentication (e.g., client_assertion/
      client_token) so the attacker cannot obtain the client secret
      required to exchange the tokens (Section 5.2.3.7).


   Attack: Obtain Refresh Token from Native Clients:

   On native clients, leakage of a refresh token typically affects a
   single user only.

   Read from local file system: The attacker could try to get file
   system access on the device and read the refresh tokens.  The
   attacker could utilize a malicious application for that purpose.

   Countermeasures:

   o  Store secrets in secure storage (Section 5.3.3).

   o  Utilize device lock to prevent unauthorized device access
      (Section 5.3.4).


   Attack: Steal Device:

   The host device (e.g., mobile phone) may be stolen.  In that case,
   the attacker gets access to all applications under the identity of
   the legitimate user.

   Countermeasures:

   o  Utilize device lock to prevent unauthorized device access
      (Section 5.3.4).

   o  Where a user knows the device has been stolen, they can revoke the
      affected tokens (Section 5.2.2.4).


   Attack: Clone Device:

   All device data and applications are copied to another device.
   Applications are used as-is on the target device.
Top   ToC   RFC6819 - Page 19
   Countermeasures:

   o  Utilize device lock to prevent unauthorized device access
      (Section 5.3.4).

   o  Combine refresh token request with device identification
      (Section 5.2.2.5).

   o  Refresh token rotation (Section 5.2.2.3).

   o  Where a user knows the device has been cloned, they can use
      refresh token revocation (Section 5.2.2.4).

4.1.3. Threat: Obtaining Access Tokens

Depending on the client type, there are different ways that access tokens may be revealed to an attacker. Access tokens could be stolen from the device if the application stores them in a storage device that is accessible to other applications. Impact: Where the token is a bearer token and no additional mechanism is used to identify the client, the attacker can access all resources associated with the token and its scope. Countermeasures: o Keep access tokens in transient memory and limit grants (Section 5.1.6). o Limit token scope (Section 5.1.5.1). o Keep access tokens in private memory or apply same protection means as for refresh tokens (Section 5.2.2). o Keep access token lifetime short (Section 5.1.5.3).

4.1.4. Threat: End-User Credentials Phished Using Compromised or Embedded Browser

A malicious application could attempt to phish end-user passwords by misusing an embedded browser in the end-user authorization process, or by presenting its own user interface instead of allowing a trusted system browser to render the authorization user interface. By doing so, the usual visual trust mechanisms may be bypassed (e.g., Transport Layer Security (TLS) confirmation, web site mechanisms). By using an embedded or internal client application user interface, the client application has access to additional information to which it should not have access (e.g., UID/password).
Top   ToC   RFC6819 - Page 20
   Impact: If the client application or the communication is
   compromised, the user would not be aware of this, and all information
   in the authorization exchange, such as username and password, could
   be captured.

   Countermeasures:

   o  The OAuth flow is designed so that client applications never need
      to know user passwords.  Client applications should avoid directly
      asking users for their credentials.  In addition, end users could
      be educated about phishing attacks and best practices, such as
      only accessing trusted clients, as OAuth does not provide any
      protection against malicious applications and the end user is
      solely responsible for the trustworthiness of any native
      application installed.

   o  Client applications could be validated prior to publication in an
      application market for users to access.  That validation is out of
      scope for OAuth but could include validating that the client
      application handles user authentication in an appropriate way.

   o  Client developers should not write client applications that
      collect authentication information directly from users and should
      instead delegate this task to a trusted system component, e.g.,
      the system browser.

4.1.5. Threat: Open Redirectors on Client

An open redirector is an endpoint using a parameter to automatically redirect a user agent to the location specified by the parameter value without any validation. If the authorization server allows the client to register only part of the redirect URI, an attacker can use an open redirector operated by the client to construct a redirect URI that will pass the authorization server validation but will send the authorization "code" or access token to an endpoint under the control of the attacker. Impact: An attacker could gain access to authorization "codes" or access tokens. Countermeasures: o Require clients to register full redirect URI (Section 5.2.3.5).
Top   ToC   RFC6819 - Page 21

4.2. Authorization Endpoint

4.2.1. Threat: Password Phishing by Counterfeit Authorization Server

OAuth makes no attempt to verify the authenticity of the authorization server. A hostile party could take advantage of this by intercepting the client's requests and returning misleading or otherwise incorrect responses. This could be achieved using DNS or Address Resolution Protocol (ARP) spoofing. Wide deployment of OAuth and similar protocols may cause users to become inured to the practice of being redirected to web sites where they are asked to enter their passwords. If users are not careful to verify the authenticity of these web sites before entering their credentials, it will be possible for attackers to exploit this practice to steal users' passwords. Countermeasures: o Authorization servers should consider such attacks when developing services based on OAuth and should require the use of transport- layer security for any requests where the authenticity of the authorization server or of request responses is an issue (see Section 5.1.2). o Authorization servers should attempt to educate users about the risks posed by phishing attacks and should provide mechanisms that make it easy for users to confirm the authenticity of their sites.

4.2.2. Threat: User Unintentionally Grants Too Much Access Scope

When obtaining end-user authorization, the end user may not understand the scope of the access being granted and to whom, or they may end up providing a client with access to resources that should not be permitted. Countermeasures: o Explain the scope (resources and the permissions) the user is about to grant in an understandable way (Section 5.2.4.2). o Narrow the scope, based on the client. When obtaining end-user authorization and where the client requests scope, the authorization server may want to consider whether to honor that scope based on the client identifier. That decision is between the client and authorization server and is outside the scope of this spec. The authorization server may also want to consider what scope to grant based on the client type, e.g., providing lower scope to public clients (Section 5.1.5.1).
Top   ToC   RFC6819 - Page 22

4.2.3. Threat: Malicious Client Obtains Existing Authorization by Fraud

Authorization servers may wish to automatically process authorization requests from clients that have been previously authorized by the user. When the user is redirected to the authorization server's end- user authorization endpoint to grant access, the authorization server detects that the user has already granted access to that particular client. Instead of prompting the user for approval, the authorization server automatically redirects the user back to the client. A malicious client may exploit that feature and try to obtain such an authorization "code" instead of the legitimate client. Countermeasures: o Authorization servers should not automatically process repeat authorizations to public clients unless the client is validated using a pre-registered redirect URI (Section 5.2.3.5). o Authorization servers can mitigate the risks associated with automatic processing by limiting the scope of access tokens obtained through automated approvals (Section 5.1.5.1).

4.2.4. Threat: Open Redirector

An attacker could use the end-user authorization endpoint and the redirect URI parameter to abuse the authorization server as an open redirector. An open redirector is an endpoint using a parameter to automatically redirect a user agent to the location specified by the parameter value without any validation. Impact: An attacker could utilize a user's trust in an authorization server to launch a phishing attack. Countermeasures: o Require clients to register any full redirect URIs (Section 5.2.3.5). o Don't redirect to a redirect URI if the client identifier or redirect URI can't be verified (Section 5.2.3.5).
Top   ToC   RFC6819 - Page 23

4.3. Token Endpoint

4.3.1. Threat: Eavesdropping Access Tokens

Attackers may attempt to eavesdrop access tokens in transit from the authorization server to the client. Impact: The attacker is able to access all resources with the permissions covered by the scope of the particular access token. Countermeasures: o As per the core OAuth spec, the authorization servers must ensure that these transmissions are protected using transport-layer mechanisms such as TLS (see Section 5.1.1). o If end-to-end confidentiality cannot be guaranteed, reducing scope (see Section 5.1.5.1) and expiry time (Section 5.1.5.3) for access tokens can be used to reduce the damage in case of leaks.

4.3.2. Threat: Obtaining Access Tokens from Authorization Server Database

This threat is applicable if the authorization server stores access tokens as handles in a database. An attacker may obtain access tokens from the authorization server's database by gaining access to the database or launching a SQL injection attack. Impact: Disclosure of all access tokens. Countermeasures: o Enforce system security measures (Section 5.1.4.1.1). o Store access token hashes only (Section 5.1.4.1.3). o Enforce standard SQL injection countermeasures (Section 5.1.4.1.2).

4.3.3. Threat: Disclosure of Client Credentials during Transmission

An attacker could attempt to eavesdrop the transmission of client credentials between the client and server during the client authentication process or during OAuth token requests. Impact: Revelation of a client credential enabling phishing or impersonation of a client service.
Top   ToC   RFC6819 - Page 24
   Countermeasures:

   o  The transmission of client credentials must be protected using
      transport-layer mechanisms such as TLS (see Section 5.1.1).

   o  Use alternative authentication means that do not require the
      sending of plaintext credentials over the wire (e.g., Hash-based
      Message Authentication Code).

4.3.4. Threat: Obtaining Client Secret from Authorization Server Database

An attacker may obtain valid "client_id"/secret combinations from the authorization server's database by gaining access to the database or launching a SQL injection attack. Impact: Disclosure of all "client_id"/secret combinations. This allows the attacker to act on behalf of legitimate clients. Countermeasures: o Enforce system security measures (Section 5.1.4.1.1). o Enforce standard SQL injection countermeasures (Section 5.1.4.1.2). o Ensure proper handling of credentials as per "Enforce Credential Storage Protection Best Practices" (Section 5.1.4.1).

4.3.5. Threat: Obtaining Client Secret by Online Guessing

An attacker may try to guess valid "client_id"/secret pairs. Impact: Disclosure of a single "client_id"/secret pair. Countermeasures: o Use high entropy for secrets (Section 5.1.4.2.2). o Lock accounts (Section 5.1.4.2.3). o Use strong client authentication (Section 5.2.3.7).
Top   ToC   RFC6819 - Page 25

4.4. Obtaining Authorization

This section covers threats that are specific to certain flows utilized to obtain access tokens. Each flow is characterized by response types and/or grant types on the end-user authorization and token endpoint, respectively.

4.4.1. Authorization "code"

4.4.1.1. Threat: Eavesdropping or Leaking Authorization "codes"
An attacker could try to eavesdrop transmission of the authorization "code" between the authorization server and client. Furthermore, authorization "codes" are passed via the browser, which may unintentionally leak those codes to untrusted web sites and attackers in different ways: o Referrer headers: Browsers frequently pass a "referer" header when a web page embeds content, or when a user travels from one web page to another web page. These referrer headers may be sent even when the origin site does not trust the destination site. The referrer header is commonly logged for traffic analysis purposes. o Request logs: Web server request logs commonly include query parameters on requests. o Open redirectors: Web sites sometimes need to send users to another destination via a redirector. Open redirectors pose a particular risk to web-based delegation protocols because the redirector can leak verification codes to untrusted destination sites. o Browser history: Web browsers commonly record visited URLs in the browser history. Another user of the same web browser may be able to view URLs that were visited by previous users. Note: A description of similar attacks on the SAML protocol can be found at [OASIS.sstc-saml-bindings-1.1], Section 4.1.1.9.1; [Sec-Analysis]; and [OASIS.sstc-sec-analysis-response-01].
Top   ToC   RFC6819 - Page 26
   Countermeasures:

   o  As per the core OAuth spec, the authorization server as well as
      the client must ensure that these transmissions are protected
      using transport-layer mechanisms such as TLS (see Section 5.1.1).

   o  The authorization server will require the client to authenticate
      wherever possible, so the binding of the authorization "code" to a
      certain client can be validated in a reliable way (see
      Section 5.2.4.4).

   o  Use short expiry time for authorization "codes" (Section 5.1.5.3).

   o  The authorization server should enforce a one-time usage
      restriction (see Section 5.1.5.4).

   o  If an authorization server observes multiple attempts to redeem an
      authorization "code", the authorization server may want to revoke
      all tokens granted based on the authorization "code" (see
      Section 5.2.1.1).

   o  In the absence of these countermeasures, reducing scope
      (Section 5.1.5.1) and expiry time (Section 5.1.5.3) for access
      tokens can be used to reduce the damage in case of leaks.

   o  The client server may reload the target page of the redirect URI
      in order to automatically clean up the browser cache.

4.4.1.2. Threat: Obtaining Authorization "codes" from Authorization Server Database
This threat is applicable if the authorization server stores authorization "codes" as handles in a database. An attacker may obtain authorization "codes" from the authorization server's database by gaining access to the database or launching a SQL injection attack. Impact: Disclosure of all authorization "codes", most likely along with the respective "redirect_uri" and "client_id" values. Countermeasures: o Best practices for credential storage protection should be employed (Section 5.1.4.1). o Enforce system security measures (Section 5.1.4.1.1).
Top   ToC   RFC6819 - Page 27
   o  Store access token hashes only (Section 5.1.4.1.3).

   o  Enforce standard SQL injection countermeasures
      (Section 5.1.4.1.2).

4.4.1.3. Threat: Online Guessing of Authorization "codes"
An attacker may try to guess valid authorization "code" values and send the guessed code value using the grant type "code" in order to obtain a valid access token. Impact: Disclosure of a single access token and probably also an associated refresh token. Countermeasures: o Handle-based tokens must use high entropy (Section 5.1.4.2.2). o Assertion-based tokens should be signed (Section 5.1.5.9). o Authenticate the client; this adds another value that the attacker has to guess (Section 5.2.3.4). o Bind the authorization "code" to the redirect URI; this adds another value that the attacker has to guess (Section 5.2.4.5). o Use short expiry time for tokens (Section 5.1.5.3).
4.4.1.4. Threat: Malicious Client Obtains Authorization
A malicious client could pretend to be a valid client and obtain an access authorization in this way. The malicious client could even utilize screen-scraping techniques in order to simulate a user's consent in the authorization flow. Assumption: It is not the task of the authorization server to protect the end-user's device from malicious software. This is the responsibility of the platform running on the particular device, probably in cooperation with other components of the respective ecosystem (e.g., an application management infrastructure). The sole responsibility of the authorization server is to control access to the end-user's resources maintained in resource servers and to prevent unauthorized access to them via the OAuth protocol. Based on this assumption, the following countermeasures are available to cope with the threat.
Top   ToC   RFC6819 - Page 28
   Countermeasures:

   o  The authorization server should authenticate the client, if
      possible (see Section 5.2.3.4).  Note: The authentication takes
      place after the end user has authorized the access.

   o  The authorization server should validate the client's redirect URI
      against the pre-registered redirect URI, if one exists (see
      Section 5.2.3.5).  Note: An invalid redirect URI indicates an
      invalid client, whereas a valid redirect URI does not necessarily
      indicate a valid client.  The level of confidence depends on the
      client type.  For web applications, the level of confidence is
      high, since the redirect URI refers to the globally unique network
      endpoint of this application, whose fully qualified domain name
      (FQDN) is also validated using HTTPS server authentication by the
      user agent.  In contrast, for native clients, the redirect URI
      typically refers to device local resources, e.g., a custom scheme.
      So, a malicious client on a particular device can use the valid
      redirect URI the legitimate client uses on all other devices.

   o  After authenticating the end user, the authorization server should
      ask him/her for consent.  In this context, the authorization
      server should explain to the end user the purpose, scope, and
      duration of the authorization the client asked for.  Moreover, the
      authorization server should show the user any identity information
      it has for that client.  It is up to the user to validate the
      binding of this data to the particular application (e.g., Name)
      and to approve the authorization request (see Section 5.2.4.3).

   o  The authorization server should not perform automatic
      re-authorizations for clients it is unable to reliably
      authenticate or validate (see Section 5.2.4.1).

   o  If the authorization server automatically authenticates the end
      user, it may nevertheless require some user input in order to
      prevent screen scraping.  Examples are CAPTCHAs (Completely
      Automated Public Turing tests to tell Computers and Humans Apart)
      or other multi-factor authentication techniques such as random
      questions, token code generators, etc.

   o  The authorization server may also limit the scope of tokens it
      issues to clients it cannot reliably authenticate (see
      Section 5.1.5.1).
Top   ToC   RFC6819 - Page 29
4.4.1.5. Threat: Authorization "code" Phishing
A hostile party could impersonate the client site and get access to the authorization "code". This could be achieved using DNS or ARP spoofing. This applies to clients, which are web applications; thus, the redirect URI is not local to the host where the user's browser is running. Impact: This affects web applications and may lead to a disclosure of authorization "codes" and, potentially, the corresponding access and refresh tokens. Countermeasures: It is strongly recommended that one of the following countermeasures be utilized in order to prevent this attack: o The redirect URI of the client should point to an HTTPS-protected endpoint, and the browser should be utilized to authenticate this redirect URI using server authentication (see Section 5.1.2). o The authorization server should require that the client be authenticated, i.e., confidential client, so the binding of the authorization "code" to a certain client can be validated in a reliable way (see Section 5.2.4.4).
4.4.1.6. Threat: User Session Impersonation
A hostile party could impersonate the client site and impersonate the user's session on this client. This could be achieved using DNS or ARP spoofing. This applies to clients, which are web applications; thus, the redirect URI is not local to the host where the user's browser is running. Impact: An attacker who intercepts the authorization "code" as it is sent by the browser to the callback endpoint can gain access to protected resources by submitting the authorization "code" to the client. The client will exchange the authorization "code" for an access token and use the access token to access protected resources for the benefit of the attacker, delivering protected resources to the attacker, or modifying protected resources as directed by the attacker. If OAuth is used by the client to delegate authentication to a social site (e.g., as in the implementation of a "Login" button on a third-party social network site), the attacker can use the intercepted authorization "code" to log into the client as the user.
Top   ToC   RFC6819 - Page 30
   Note: Authenticating the client during authorization "code" exchange
   will not help to detect such an attack, as it is the legitimate
   client that obtains the tokens.

   Countermeasures:

   o  In order to prevent an attacker from impersonating the end-user's
      session, the redirect URI of the client should point to an HTTPS
      protected endpoint, and the browser should be utilized to
      authenticate this redirect URI using server authentication (see
      Section 5.1.2).

4.4.1.7. Threat: Authorization "code" Leakage through Counterfeit Client
The attacker leverages the authorization "code" grant type in an attempt to get another user (victim) to log in, authorize access to his/her resources, and subsequently obtain the authorization "code" and inject it into a client application using the attacker's account. The goal is to associate an access authorization for resources of the victim with the user account of the attacker on a client site. The attacker abuses an existing client application and combines it with his own counterfeit client web site. The attacker depends on the victim expecting the client application to request access to a certain resource server. The victim, seeing only a normal request from an expected application, approves the request. The attacker then uses the victim's authorization to gain access to the information unknowingly authorized by the victim. The attacker conducts the following flow: 1. The attacker accesses the client web site (or application) and initiates data access to a particular resource server. The client web site in turn initiates an authorization request to the resource server's authorization server. Instead of proceeding with the authorization process, the attacker modifies the authorization server end-user authorization URL as constructed by the client to include a redirect URI parameter referring to a web site under his control (attacker's web site). 2. The attacker tricks another user (the victim) into opening that modified end-user authorization URI and authorizing access (e.g., via an email link or blog link). The way the attacker achieves this goal is out of scope. 3. Having clicked the link, the victim is requested to authenticate and authorize the client site to have access.
Top   ToC   RFC6819 - Page 31
   4.  After completion of the authorization process, the authorization
       server redirects the user agent to the attacker's web site
       instead of the original client web site.

   5.  The attacker obtains the authorization "code" from his web site
       by means that are out of scope of this document.

   6.  He then constructs a redirect URI to the target web site (or
       application) based on the original authorization request's
       redirect URI and the newly obtained authorization "code", and
       directs his user agent to this URL.  The authorization "code" is
       injected into the original client site (or application).

   7.  The client site uses the authorization "code" to fetch a token
       from the authorization server and associates this token with the
       attacker's user account on this site.

   8.  The attacker may now access the victim's resources using the
       client site.

   Impact: The attacker gains access to the victim's resources as
   associated with his account on the client site.

   Countermeasures:

   o  The attacker will need to use another redirect URI for its
      authorization process rather than the target web site because it
      needs to intercept the flow.  So, if the authorization server
      associates the authorization "code" with the redirect URI of a
      particular end-user authorization and validates this redirect URI
      with the redirect URI passed to the token's endpoint, such an
      attack is detected (see Section 5.2.4.5).

   o  The authorization server may also enforce the usage and validation
      of pre-registered redirect URIs (see Section 5.2.3.5).  This will
      allow for early recognition of authorization "code" disclosure to
      counterfeit clients.

   o  For native applications, one could also consider using deployment-
      specific client ids and secrets (see Section 5.2.3.4), along with
      the binding of authorization "codes" to "client_ids" (see
      Section 5.2.4.4) to detect such an attack because the attacker
      does not have access to the deployment-specific secret.  Thus, he
      will not be able to exchange the authorization "code".
Top   ToC   RFC6819 - Page 32
   o  The client may consider using other flows that are not vulnerable
      to this kind of attack, such as the implicit grant type (see
      Section 4.4.2) or resource owner password credentials (see
      Section 4.4.3).

4.4.1.8. Threat: CSRF Attack against redirect-uri
Cross-site request forgery (CSRF) is a web-based attack whereby HTTP requests are transmitted from a user that the web site trusts or has authenticated (e.g., via HTTP redirects or HTML forms). CSRF attacks on OAuth approvals can allow an attacker to obtain authorization to OAuth protected resources without the consent of the user. This attack works against the redirect URI used in the authorization "code" flow. An attacker could authorize an authorization "code" to their own protected resources on an authorization server. He then aborts the redirect flow back to the client on his device and tricks the victim into executing the redirect back to the client. The client receives the redirect, fetches the token(s) from the authorization server, and associates the victim's client session with the resources accessible using the token. Impact: The user accesses resources on behalf of the attacker. The effective impact depends on the type of resource accessed. For example, the user may upload private items to an attacker's resources. Or, when using OAuth in 3rd-party login scenarios, the user may associate his client account with the attacker's identity at the external Identity Provider. In this way, the attacker could easily access the victim's data at the client by logging in from another device with his credentials at the external Identity Provider. Countermeasures: o The "state" parameter should be used to link the authorization request with the redirect URI used to deliver the access token (Section 5.3.5). o Client developers and end users can be educated to not follow untrusted URLs.
Top   ToC   RFC6819 - Page 33
4.4.1.9. Threat: Clickjacking Attack against Authorization
With clickjacking, a malicious site loads the target site in a transparent iFrame (see [iFrame]) overlaid on top of a set of dummy buttons that are carefully constructed to be placed directly under important buttons on the target site. When a user clicks a visible button, they are actually clicking a button (such as an "Authorize" button) on the hidden page. Impact: An attacker can steal a user's authentication credentials and access their resources. Countermeasures: o For newer browsers, avoidance of iFrames during authorization can be enforced on the server side by using the X-FRAME-OPTIONS header (Section 5.2.2.6). o For older browsers, JavaScript frame-busting (see [Framebusting]) techniques can be used but may not be effective in all browsers.
4.4.1.10. Threat: Resource Owner Impersonation
When a client requests access to protected resources, the authorization flow normally involves the resource owner's explicit response to the access request, either granting or denying access to the protected resources. A malicious client can exploit knowledge of the structure of this flow in order to gain authorization without the resource owner's consent, by transmitting the necessary requests programmatically and simulating the flow against the authorization server. That way, the client may gain access to the victim's resources without her approval. An authorization server will be vulnerable to this threat if it uses non-interactive authentication mechanisms or splits the authorization flow across multiple pages. The malicious client might embed a hidden HTML user agent, interpret the HTML forms sent by the authorization server, and automatically send the corresponding form HTTP POST requests. As a prerequisite, the attacker must be able to execute the authorization process in the context of an already-authenticated session of the resource owner with the authorization server. There are different ways to achieve this: o The malicious client could abuse an existing session in an external browser or cross-browser cookies on the particular device.
Top   ToC   RFC6819 - Page 34
   o  The malicious client could also request authorization for an
      initial scope acceptable to the user and then silently abuse the
      resulting session in his browser instance to "silently" request
      another scope.

   o  Alternatively, the attacker might exploit an authorization
      server's ability to authenticate the resource owner automatically
      and without user interactions, e.g., based on certificates.

   In all cases, such an attack is limited to clients running on the
   victim's device, either within the user agent or as a native app.

   Please note: Such attacks cannot be prevented using CSRF
   countermeasures, since the attacker just "executes" the URLs as
   prepared by the authorization server including any nonce, etc.

   Countermeasures:

   Authorization servers should decide, based on an analysis of the risk
   associated with this threat, whether to detect and prevent this
   threat.

   In order to prevent such an attack, the authorization server may
   force a user interaction based on non-predictable input values as
   part of the user consent approval.  The authorization server could

   o  combine password authentication and user consent in a single form,

   o  make use of CAPTCHAs, or

   o  use one-time secrets sent out of band to the resource owner (e.g.,
      via text or instant message).

   Alternatively, in order to allow the resource owner to detect abuse,
   the authorization server could notify the resource owner of any
   approval by appropriate means, e.g., text or instant message, or
   email.

4.4.1.11. Threat: DoS Attacks That Exhaust Resources
If an authorization server includes a nontrivial amount of entropy in authorization "codes" or access tokens (limiting the number of possible codes/tokens) and automatically grants either without user intervention and has no limit on codes or access tokens per user, an attacker could exhaust the pool of authorization "codes" by repeatedly directing the user's browser to request authorization "codes" or access tokens.
Top   ToC   RFC6819 - Page 35
   Countermeasures:

   o  The authorization server should consider limiting the number of
      access tokens granted per user.

   o  The authorization server should include a nontrivial amount of
      entropy in authorization "codes".

4.4.1.12. Threat: DoS Using Manufactured Authorization "codes"
An attacker who owns a botnet can locate the redirect URIs of clients that listen on HTTP, access them with random authorization "codes", and cause a large number of HTTPS connections to be concentrated onto the authorization server. This can result in a denial-of-service (DoS) attack on the authorization server. This attack can still be effective even when CSRF defense/the "state" parameter (see Section 4.4.1.8) is deployed on the client side. With such a defense, the attacker might need to incur an additional HTTP request to obtain a valid CSRF code/"state" parameter. This apparently cuts down the effectiveness of the attack by a factor of 2. However, if the HTTPS/HTTP cost ratio is higher than 2 (the cost factor is estimated to be around 3.5x at [SSL-Latency]), the attacker still achieves a magnification of resource utilization at the expense of the authorization server. Impact: There are a few effects that the attacker can accomplish with this OAuth flow that they cannot easily achieve otherwise. 1. Connection laundering: With the clients as the relay between the attacker and the authorization server, the authorization server learns little or no information about the identity of the attacker. Defenses such as rate-limiting on the offending attacker machines are less effective because it is difficult to identify the attacking machines. Although an attacker could also launder its connections through an anonymizing system such as Tor, the effectiveness of that approach depends on the capacity of the anonymizing system. On the other hand, a potentially large number of OAuth clients could be utilized for this attack. 2. Asymmetric resource utilization: The attacker incurs the cost of an HTTP connection and causes an HTTPS connection to be made on the authorization server; the attacker can coordinate the timing of such HTTPS connections across multiple clients relatively easily. Although the attacker could achieve something similar, say, by including an iFrame pointing to the HTTPS URL of the authorization server in an HTTP web page and luring web users to visit that page, timing attacks using such a scheme may be more
Top   ToC   RFC6819 - Page 36
       difficult, as it seems nontrivial to synchronize a large number
       of users to simultaneously visit a particular site under the
       attacker's control.

   Countermeasures:

   o  Though not a complete countermeasure by themselves, CSRF defense
      and the "state" parameter created with secure random codes should
      be deployed on the client side.  The client should forward the
      authorization "code" to the authorization server only after both
      the CSRF token and the "state" parameter are validated.

   o  If the client authenticates the user, either through a single-
      sign-on protocol or through local authentication, the client
      should suspend the access by a user account if the number of
      invalid authorization "codes" submitted by this user exceeds a
      certain threshold.

   o  The authorization server should send an error response to the
      client reporting an invalid authorization "code" and rate-limit or
      disallow connections from clients whose number of invalid requests
      exceeds a threshold.

4.4.1.13. Threat: Code Substitution (OAuth Login)
An attacker could attempt to log into an application or web site using a victim's identity. Applications relying on identity data provided by an OAuth protected service API to login users are vulnerable to this threat. This pattern can be found in so-called "social login" scenarios. As a prerequisite, a resource server offers an API to obtain personal information about a user that could be interpreted as having obtained a user identity. In this sense, the client is treating the resource server API as an "identity" API. A client utilizes OAuth to obtain an access token for the identity API. It then queries the identity API for an identifier and uses it to look up its internal user account data (login). The client assumes that, because it was able to obtain information about the user, the user has been authenticated. If the client uses the grant type "code", the attacker needs to gather a valid authorization "code" of the respective victim from the same Identity Provider used by the target client application. The attacker tricks the victim into logging into a malicious app (which may appear to be legitimate to the Identity Provider) using the same Identity Provider as the target application. This results in the Identity Provider's authorization server issuing an authorization
Top   ToC   RFC6819 - Page 37
   "code" for the respective identity API.  The malicious app then sends
   this code to the attacker, which in turn triggers a login process
   within the target application.  The attacker now manipulates the
   authorization response and substitutes their code (bound to their
   identity) for the victim's code.  This code is then exchanged by the
   client for an access token, which in turn is accepted by the identity
   API, since the audience, with respect to the resource server, is
   correct.  But since the identifier returned by the identity API is
   determined by the identity in the access token (issued based on the
   victim's code), the attacker is logged into the target application
   under the victim's identity.

   Impact: The attacker gains access to an application and user-specific
   data within the application.

   Countermeasures:

   o  All clients must indicate their client ids with every request to
      exchange an authorization "code" for an access token.  The
      authorization server must validate whether the particular
      authorization "code" has been issued to the particular client.  If
      possible, the client shall be authenticated beforehand.

   o  Clients should use an appropriate protocol, such as OpenID (cf.
      [OPENID]) or SAML (cf. [OASIS.sstc-saml-bindings-1.1]) to
      implement user login.  Both support audience restrictions on
      clients.

4.4.2. Implicit Grant

In the implicit grant type flow, the access token is directly returned to the client as a fragment part of the redirect URI. It is assumed that the token is not sent to the redirect URI target, as HTTP user agents do not send the fragment part of URIs to HTTP servers. Thus, an attacker cannot eavesdrop the access token on this communication path, and the token cannot leak through HTTP referrer headers.
4.4.2.1. Threat: Access Token Leak in Transport/Endpoints
This token might be eavesdropped by an attacker. The token is sent from the server to the client via a URI fragment of the redirect URI. If the communication is not secured or the endpoint is not secured, the token could be leaked by parsing the returned URI. Impact: The attacker would be able to assume the same rights granted by the token.
Top   ToC   RFC6819 - Page 38
   Countermeasures:

   o  The authorization server should ensure confidentiality (e.g.,
      using TLS) of the response from the authorization server to the
      client (see Section 5.1.1).

4.4.2.2. Threat: Access Token Leak in Browser History
An attacker could obtain the token from the browser's history. Note that this means the attacker needs access to the particular device. Countermeasures: o Use short expiry time for tokens (see Section 5.1.5.3). Reduced scope of the token may reduce the impact of that attack (see Section 5.1.5.1). o Make responses non-cacheable.
4.4.2.3. Threat: Malicious Client Obtains Authorization
A malicious client could attempt to obtain a token by fraud. The same countermeasures as for Section 4.4.1.4 are applicable, except client authentication.
4.4.2.4. Threat: Manipulation of Scripts
A hostile party could act as the client web server and replace or modify the actual implementation of the client (script). This could be achieved using DNS or ARP spoofing. This applies to clients implemented within the web browser in a scripting language. Impact: The attacker could obtain user credential information and assume the full identity of the user. Countermeasures: o The authorization server should authenticate the server from which scripts are obtained (see Section 5.1.2). o The client should ensure that scripts obtained have not been altered in transport (see Section 5.1.1).
Top   ToC   RFC6819 - Page 39
   o  Introduce one-time, per-use secrets (e.g., "client_secret") values
      that can only be used by scripts in a small time window once
      loaded from a server.  The intention would be to reduce the
      effectiveness of copying client-side scripts for re-use in an
      attacker's modified code.

4.4.2.5. Threat: CSRF Attack against redirect-uri
CSRF attacks (see Section 4.4.1.8) also work against the redirect URI used in the implicit grant flow. An attacker could acquire an access token to their own protected resources. He could then construct a redirect URI and embed their access token in that URI. If he can trick the user into following the redirect URI and the client does not have protection against this attack, the user may have the attacker's access token authorized within their client. Impact: The user accesses resources on behalf of the attacker. The effective impact depends on the type of resource accessed. For example, the user may upload private items to an attacker's resources. Or, when using OAuth in 3rd-party login scenarios, the user may associate his client account with the attacker's identity at the external Identity Provider. In this way, the attacker could easily access the victim's data at the client by logging in from another device with his credentials at the external Identity Provider. Countermeasures: o The "state" parameter should be used to link the authorization request with the redirect URI used to deliver the access token. This will ensure that the client is not tricked into completing any redirect callback unless it is linked to an authorization request initiated by the client. The "state" parameter should not be guessable, and the client should be capable of keeping the "state" parameter secret. o Client developers and end users can be educated to not follow untrusted URLs.
4.4.2.6. Threat: Token Substitution (OAuth Login)
An attacker could attempt to log into an application or web site using a victim's identity. Applications relying on identity data provided by an OAuth protected service API to login users are vulnerable to this threat. This pattern can be found in so-called "social login" scenarios.
Top   ToC   RFC6819 - Page 40
   As a prerequisite, a resource server offers an API to obtain personal
   information about a user that could be interpreted as having obtained
   a user identity.  In this sense, the client is treating the resource
   server API as an "identity" API.  A client utilizes OAuth to obtain
   an access token for the identity API.  It then queries the identity
   API for an identifier and uses it to look up its internal user
   account data (login).  The client assumes that, because it was able
   to obtain information about the user, the user has been
   authenticated.

   To succeed, the attacker needs to gather a valid access token of the
   respective victim from the same Identity Provider used by the target
   client application.  The attacker tricks the victim into logging into
   a malicious app (which may appear to be legitimate to the Identity
   Provider) using the same Identity Provider as the target application.
   This results in the Identity Provider's authorization server issuing
   an access token for the respective identity API.  The malicious app
   then sends this access token to the attacker, which in turn triggers
   a login process within the target application.  The attacker now
   manipulates the authorization response and substitutes their access
   token (bound to their identity) for the victim's access token.  This
   token is accepted by the identity API, since the audience, with
   respect to the resource server, is correct.  But since the identifier
   returned by the identity API is determined by the identity in the
   access token, the attacker is logged into the target application
   under the victim's identity.

   Impact: The attacker gains access to an application and user-specific
   data within the application.

   Countermeasures:

   o  Clients should use an appropriate protocol, such as OpenID (cf.
      [OPENID]) or SAML (cf. [OASIS.sstc-saml-bindings-1.1]) to
      implement user login.  Both support audience restrictions on
      clients.

4.4.3. Resource Owner Password Credentials

The resource owner password credentials grant type (see [RFC6749], Section 4.3), often used for legacy/migration reasons, allows a client to request an access token using an end-user's user id and password along with its own credential. This grant type has higher risk because it maintains the UID/password anti-pattern. Additionally, because the user does not have control over the authorization process, clients using this grant type are not limited
Top   ToC   RFC6819 - Page 41
   by scope but instead have potentially the same capabilities as the
   user themselves.  As there is no authorization step, the ability to
   offer token revocation is bypassed.

   Because passwords are often used for more than 1 service, this
   anti-pattern may also put at risk whatever else is accessible with
   the supplied credential.  Additionally, any easily derived equivalent
   (e.g., joe@example.com and joe@example.net) might easily allow
   someone to guess that the same password can be used elsewhere.

   Impact: The resource server can only differentiate scope based on the
   access token being associated with a particular client.  The client
   could also acquire long-lived tokens and pass them up to an
   attacker's web service for further abuse.  The client, eavesdroppers,
   or endpoints could eavesdrop the user id and password.

   Countermeasures:

   o  Except for migration reasons, minimize use of this grant type.

   o  The authorization server should validate the client id associated
      with the particular refresh token with every refresh request
      (Section 5.2.2.2).

   o  As per the core OAuth specification, the authorization server must
      ensure that these transmissions are protected using transport-
      layer mechanisms such as TLS (see Section 5.1.1).

   o  Rather than encouraging users to use a UID and password, service
      providers should instead encourage users not to use the same
      password for multiple services.

   o  Limit use of resource owner password credential grants to
      scenarios where the client application and the authorizing service
      are from the same organization.

4.4.3.1. Threat: Accidental Exposure of Passwords at Client Site
If the client does not provide enough protection, an attacker or disgruntled employee could retrieve the passwords for a user. Countermeasures: o Use other flows that do not rely on the client's cooperation for secure resource owner credential handling. o Use digest authentication instead of plaintext credential processing.
Top   ToC   RFC6819 - Page 42
   o  Obfuscate passwords in logs.

4.4.3.2. Threat: Client Obtains Scopes without End-User Authorization
All interaction with the resource owner is performed by the client. Thus it might, intentionally or unintentionally, happen that the client obtains a token with scope unknown for, or unintended by, the resource owner. For example, the resource owner might think the client needs and acquires read-only access to its media storage only but the client tries to acquire an access token with full access permissions. Countermeasures: o Use other flows that do not rely on the client's cooperation for resource owner interaction. o The authorization server may generally restrict the scope of access tokens (Section 5.1.5.1) issued by this flow. If the particular client is trustworthy and can be authenticated in a reliable way, the authorization server could relax that restriction. Resource owners may prescribe (e.g., in their preferences) what the maximum scope is for clients using this flow. o The authorization server could notify the resource owner by an appropriate medium, e.g., email, of the grant issued (see Section 5.1.3).
4.4.3.3. Threat: Client Obtains Refresh Token through Automatic Authorization
All interaction with the resource owner is performed by the client. Thus it might, intentionally or unintentionally, happen that the client obtains a long-term authorization represented by a refresh token even if the resource owner did not intend so. Countermeasures: o Use other flows that do not rely on the client's cooperation for resource owner interaction. o The authorization server may generally refuse to issue refresh tokens in this flow (see Section 5.2.2.1). If the particular client is trustworthy and can be authenticated in a reliable way (see client authentication), the authorization server could relax
Top   ToC   RFC6819 - Page 43
      that restriction.  Resource owners may allow or deny (e.g., in
      their preferences) the issuing of refresh tokens using this flow
      as well.

   o  The authorization server could notify the resource owner by an
      appropriate medium, e.g., email, of the refresh token issued (see
      Section 5.1.3).

4.4.3.4. Threat: Obtaining User Passwords on Transport
An attacker could attempt to eavesdrop the transmission of end-user credentials with the grant type "password" between the client and server. Impact: Disclosure of a single end-user's password. Countermeasures: o Ensure confidentiality of requests (Section 5.1.1). o Use alternative authentication means that do not require the sending of plaintext credentials over the wire (e.g., Hash-based Message Authentication Code).
4.4.3.5. Threat: Obtaining User Passwords from Authorization Server Database
An attacker may obtain valid username/password combinations from the authorization server's database by gaining access to the database or launching a SQL injection attack. Impact: Disclosure of all username/password combinations. The impact may exceed the domain of the authorization server, since many users tend to use the same credentials on different services. Countermeasures: o Enforce credential storage protection best practices (Section 5.1.4.1).
4.4.3.6. Threat: Online Guessing
An attacker may try to guess valid username/password combinations using the grant type "password". Impact: Revelation of a single username/password combination.
Top   ToC   RFC6819 - Page 44
   Countermeasures:

   o  Utilize secure password policy (Section 5.1.4.2.1).

   o  Lock accounts (Section 5.1.4.2.3).

   o  Use tar pit (Section 5.1.4.2.4).

   o  Use CAPTCHAs (Section 5.1.4.2.5).

   o  Consider not using the grant type "password".

   o  Client authentication (see Section 5.2.3) will provide another
      authentication factor and thus hinder the attack.

4.4.4. Client Credentials

Client credentials (see [RFC6749], Section 3) consist of an identifier (not secret) combined with an additional means (such as a matching client secret) of authenticating a client. The threats to this grant type are similar to those described in Section 4.4.3.


(page 44 continued on part 3)

Next Section