{'fraction_non_alphanumeric': 0.031236131498992934, 'fraction_numerical': 0.01184583347557437, 'mean_word_length': 4.54810606060606, 'pattern_counts': {'":': 0, '<': 1, '<?xml version=': 0, '>': 1, 'https://': 4, 'lorem ipsum': 0, 'www.': 3, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 9, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
Mitigating CSRF attacks on OAuth 2.0 and OpenID Connect

Many millions of users routinely use their Google, Facebook and Microsoft accounts to log in to websites supporting OAuth 2.0 and/or OpenID Connect-based single sign on. The security of OAuth 2.0 and OpenID Connect is therefore of critical importance, and it has been widely examined both in theory and in practice. Unfortunately, as these studies have shown, real-world implementations of both schemes are often vulnerable to attack, and in particular to cross-site request forgery (CSRF) attacks. In this paper we propose a new technique which can be used to mitigate CSRF attacks against both OAuth 2.0 and OpenID Connect.


Introduction
Since the OAuth 2.0 authorisation framework was published at the end of 2012 [11], it has been adopted by a large number of websites worldwide as a means of providing single sign-on (SSO) services. By using OAuth 2.0, websites can reduce the burden of password management for their users, as well as saving users the inconvenience of re-entering attributes that are instead stored by identity providers and provided to relying parties as required.
There is a correspondingly rich infrastructure of identity providers (IdPs) providing identity services using OAuth 2.0. This is demonstrated by the fact that some Relying Parties (RPs), such as the website USATODAY 3 , support as many as six different IdPs -see Fig. 1

.1.
As discussed in greater detail in section 4, the theoretical security of OAuth 2.0 has been analysed using formal methods [1,2,4,5,9,17,21]. Research focusing on the practical security and privacy properties of implementations of OAuth 2.0 has also been conducted [6,13,14,19,22,23,25]. This latter research has revealed that many real-world implementations of OAuth 2.0 and OpenID Connect have serious vulnerabilities, often because the implementation advice from IdPs is hard to follow. In this paper we look at a class of cross-site request forgery (CSRF) attacks which have been shown to apply to many real-world implementations of both OAuth 2.0 and OpenID Connect (which is OAuth 2.0-based). In particular, we examine a new class of mitigations which can be applied to prevent such attacks; such techniques are needed because, although existing mitigations are effective in principle, for a variety of practical reasons these are often not deployed in operational implementations.
The remainder of this paper is structured as follows. Section 2 provides background on OAuth 2.0. In section 3 we describe implementation strategies that RPs use to support multiple IdPs. Section 4 summarises previous work analysing the security of real-world OAuth 2.0 implementations. Section 5 describes the adversary model we use in this paper, and also gives a detailed description of possible CSRF attacks against OAuth 2.0 and OpenID Connect. In section 6 we propose a new approach to defend against CSRF attacks. In section 7 we describe how CSRF attacks can be mitigated for RPs using a specific OAuth 2.0 client library. Section 8 describes possible limitations of our approach and also possible ways of avoiding these limitations. Section 9 concludes the paper.

OAuth 2.0
The OAuth 2.0 specification [11] describes a system that allows an application to access resources (typically personal information) protected by a resource server on behalf of the resource owner, through the consumption of an access token issued by an authorization server. In support of this system, the OAuth 2.0 architecture involves the following four roles (see Fig. 2.1).
1. The Resource Owner is typically an end user. 2. The Client is an application running on a server, which makes requests on behalf of the resource owner (the Client is the RP when OAuth 2.0 is used for SSO). 3. The Authorization Server generates access tokens for the client, after authenticating the resource owner and obtaining its authorization. 4. The Resource Server is a server which stores the protected resources and consumes access tokens provided by an authorization server (the Resource Server and Authorization Server together constitute the IdP when OAuth 2.0 is used for SSO).  (1) an authorization request to the resource owner. In response, the resource owner generates an authorization grant (or authorization response) in the form of a code, and sends it (2) to the client. After receiving the authorization grant, the client initiates an access token request by authenticating itself to the authorization server and presenting the authorization grant, i.e. the code issued by the resource owner (3). The authorization server issues (4) an access token to the client after successfully authenticating the client and validating the authorization grant. The client makes a protected source request by presenting the access token to the resource server (5). Finally, the resource server sends (6) the protected resources to the client after validating the access token. The OAuth 2.0 framework defines four ways for RPs to obtain access tokens, namely Authorization Code Grant, Implicit Grant, Resource Owner Password, and Client Credentials Grant. In this paper we are only concerned with the Authorization Code Grant and Implicit Grant protocol flows. Note that, in the descriptions below, protocol parameters given in bold font are defined as required (i.e. mandatory) in the OAuth 2.0 Authorization Framework [11].

OpenID Connect
OpenID Connect 1.0 [18] builds an identity layer on top of the OAuth 2.0 protocol. The added functionality enables RPs to verify an end user identity by relying on an authentication process performed by an OpenID Provider (OP). In order to enable an RP to verify the identity of an end user, OpenID Connect adds a new type of token to OAuth 2.0, namely the id token. This complements the access token and code, which are already part of OAuth 2.0. An id token contains claims about the authentication of an end user by an OP together with any other claims requested by the RP.
OpenID Connect supports three authentication flows [18], i.e. ways in which the system can operate, namely Hybrid Flow, Authorization Code Flow and Implicit Flow.

OAuth 2.0 used for SSO
In order to use OAuth 2.0 as the basis of an SSO system, the following role mapping is used: the resource server and authorization server together play the IdP role; the client plays the role of the RP; the resource owner corresponds to the user. OAuth 2.0 and OpenID Connect SSO systems build on user agent (UA) redirections, where a user (U) wishes to access services protected by the RP which consumes the access token generated by the IdP. The UA is typically a web browser. The IdP provides ways to authenticate the user, asks the user to grant permission for the RP to access the user's attributes, and generates an access token on behalf of the user. After receiving the access token, the RP can access the user's attributes using the API provided by the IdP.

RP Registration
The RP must register with the IdP before it can use OAuth 2.0. During registration, the IdP gathers security-critical information about the RP, including the RP's redirect URI, i.e. redirect uri , the URI to which the user agent is redirected after the IdP has generated the authorization response and sent it to the RP via the UA. As part of registration, the IdP issues the RP with a unique identifier (client id ) and, optionally, a secret (client secret). If defined, client secret is used by the IdP to authenticate the RP when using the Authorization Code Grant flow.
Authorization Code Grant The OAuth 2.0 Authorization Code Grant is very similar to the OpenID Connect Authorization Code Flow; for simplicity, we only give the description of the OAuth 2.0 Authorization Code Grant. This flow relies on certain information having been established during the registration process, as described in section 2.
3. An instance of use of the protocol proceeds as follows.
1. U → RP: The user clicks a login button on the RP website, as displayed by the UA, which causes the UA to send an HTTP request to the RP. 2. RP → UA: The RP produces an OAuth 2.0 authorization request and sends it back to the UA. The authorization request includes client id , the identifier for the client which the RP registered with the IdP previously; response type=code, indicating that the Authorization Code Grant method is requested; redirect uri, the URI to which the IdP will redirect the UA after access has been granted; state, an opaque value used by the RP to maintain state between the request and the callback (step 6 below); and scope, the scope of the requested permission. 3. UA → IdP: The UA redirects the request which it received in step 2 to the IdP. 4. IdP → UA: The IdP first compares the value of redirect uri it received in step 3 (embedded in the authorization request) with the registered value; if the comparison fails, the process terminates. If the user has already been authenticated by the IdP, then the next step is skipped. If not, the IdP returns a login form which is used to collect the user authentication information. 5. U → UA → IdP: The user completes the login form and grants permission for the RP to access the attributes stored by the IdP. 6. IdP → UA → RP: After (if necessary) using the information provided in the login form to authenticate the user, the IdP generates an authorization response and redirects the UA back to the RP. The authorization response contains code, the authorization code (representing the authorization grant) generated by the IdP; and state, the value sent in step 2. 7. RP → IdP: The RP produces an access token request and sends it to the IdP token endpoint directly (i.e. not via the UA). The request includes grant type=authorization code, client id , client secret (if the RP has been issued one), code (generated in step 6), and the redirect uri . 8. IdP → RP: The IdP checks client id , client secret (if present), code and redirect uri and, if the checks succeed, responds to the RP with access token. 9. RP → IdP: The RP passes access token to the IdP via a defined API to request the user attributes. 10. IdP → RP: The IdP checks access token (how this works is not specified in the OAuth 2.0 specification) and, if satisfied, sends the requested user attributes to the RP.

Implicit Grant
The OAuth 2.0 Implicit Grant is very similar to the OpenID Connect Implicit Flow and Hybrid Flow; for simplicity, we only give the description of the OAuth 2.0 Implicit Grant. This flow has a similar sequence of steps to Authorization Code Grant. We specify below only those steps where the Implicit Grant flow differs from the Authorization Code Grant flow.
2. RP → UA: The RP produces an OAuth 2.0 authorization request and sends it back to the UA. The authorization request includes client id , the identifier for the client which the RP registered with the IdP previously; response type=token, indicating that the Implicit Grant is requested; redirect uri, the URI to which the IdP will redirect the UA after access has been granted; state, an opaque value used by the RP to maintain state between the request and the callback (step 6 below); and scope, the scope of the requested permission. 6. IdP → UA → RP: After (if necessary) using the information provided in the login form to authenticate the user, the IdP generates an access token and redirects the UA back to the RP using the value of redirect uri provided in step 2. The access token is appended to redirect uri as a URI fragment (i.e. as a suffix to the URI following a # symbol).
As URI fragments are not sent in HTTP requests, the access token is not immediately transferred when the UA is redirected to the RP. Instead, the RP returns a web page (typically an HTML document with an embedded script) capable of accessing the full redirection URI, including the fragment retained by the UA, and extracting the access token (and other parameters) contained in the fragment; the retrieved access token is returned to the RP. The RP can now use this access token to retrieve data stored at the IdP.

Supporting multiple IdPs
As described in section 1, many RPs support more than one IdP. This recognises the fact that users will have trust relationships with varying sets of IdPs -for example, one user may prefer to trust Facebook, whereas another may prefer Google.
In this section we describe two ways in which this is achieved in practice.

Using redirect URIs
One way in which an RP can support multiple IdPs is to register a different redirect uri with each IdP, and to set up a sign-in endpoint for each. The can then use the endpoint on which it receives an authorization response to recognise which IdP sent it. For example, AddThis 4 has registered the URIs: https://www.addthis.com/darkseid/account/register-facebook-return as its redirect uri for Facebook, and https://www.addthis.com/darkseid/account/register-google-return as its redirect uri for Google.
If AddThis receives an authorization response at the endpoint https://www. addthis.com/darkseid/account/register-facebook-return?code=[code_generated_ by_Facebook], (in step 7 of section 2.3), it assumes that this response was generated by Facebook, and thus sends the authorization code to the Facebook server (step 8 of section 2.3) to request an access token.

Explicit User Intention Tracking
Registering a different redirection URI for each IdP is not the only approach that could be used by an RP to support multiple IdPs. If an RP does not register a different redirection URI for each IdP, it can instead keep a record of the IdP each user wishes to use to authenticate (e.g. it could save the identity of the user's selected IdP to a cookie). In this case, when a authorization response is received by the RP, the RP can retrieve the identity of the IdP from the cookie and then send the code to this IdP. This method is typically used by RPs that allow for dynamic registration, where using the same URI is an obvious implementation choice [9].

Analysing the security of OAuth 2.0 and OpenID Connect
The security properties of OAuth 2.0 have been analysed using formal methods. Pai et al. [17] confirmed a security issue described in the OAuth 2.0 Thread Model [15] using the Alloy Framework [12]. Chari et al. analysed OAuth 2.0 in the Universal Composability Security Framework [5] and showed that OAuth 2.0 is secure if all the communications links are SSL-protected. Frostig and Slack [21] discovered a cross site request forgery attack in the Implicit Grant flow of OAuth 2.0, using the Murphi framework [8]. Bansal et al. [1] analysed the security of OAuth 2.0 using the WebSpi [2] and ProVerif models [4]. However, all this work is based on abstract models, and so delicate implementation details are ignored. The security properties of real-world OAuth 2.0 implementations have also been examined by a number of authors. Wang et al. [23] examined deployed SSO systems, focussing on a logic flaw present in many such systems, including OpenID. In parallel, Sun and Beznosov [22] also studied deployed OAuth 2.0 systems. Later, Li and Mitchell [13] examined the security of deployed OAuth 2.0 systems providing services in Chinese. In parallel, Zhou and Evans [25] conducted a large scale study of the security of Facebook's OAuth 2.0 implementation. Chen et al. [6], and Shehab and Mohsen [19] have looked at the security of OAuth 2.0 implementations on mobile platforms. Li and Mitchell [14] conducted an empirical study of the security of the OpenID Connect-based SSO service provided by Google.
These latter studies have revealed a number of vulnerabilities arising in implementations of these systems. Of particular interest here are vulnerabilities which can lead to CSRF attacks, and we next describe how these attacks can arise.

Adversary Model
We suppose that the adversary has the capabilities of a web attacker, i.e. it can share malicious links or post comments which contain malicious content (e.g. stylesheets or images) on a benign website, and/or can exploit vulnerabilities in an RP website. The malicious content might trigger the web browser to send an HTTP/HTTPS request to an RP and IdP using either the GET or POST methods, or execute JavaScript scripts crafted by the attacker.

CSRF attacks
A cross site request forgery (CSRF) attack [3, ?,?,?,?,?,?] operates in the context of an ongoing interaction between a target web browser (running on behalf of a target user) and a target website. The attack involves a malicious website causing the target web browser to initiate a request of the attacker's choice to the target website. This can cause the target website to execute actions without the involvement of the user. In particular, if the target user is currently logged into the target website, the target web browser will send cookies containing an authentication token generated by the target website for the target user, along with the attacker-supplied request, to the target website. The target website will then process the malicious request as through it was initiated by the target user.
There are various ways in which the target browser could be made to send the spurious request. For example, a malicious website visited by the browser could use the HTML <img> tag's src attribute to specify the malicious request URL, which will cause the browser to silently use a GET method to send the request to the target website.
According to the OWASP Top 10 -2013 report [16] released by the Open Web Application Security Project (OWASP) in 2013, the CSRF attack is ranked as No. 8 in the 10 most critical web application security risks. This means that such attacks represent a real danger in practice.

CSRF Attacks Against the Redirect URI
CSRF attacks against the OAuth 2.0 redirect uri [15] can allow an attacker to obtain authorization to access OAuth-protected resources without the consent of the user. Such an attack is possible for both the Authorization Code Grant Flow and the Implicit Grant Flow.
An attacker first acquires a code or access token relating to its own protected resources. The attacker then aborts the redirect flow back to the RP on the attacker's own device, and then, by some means, tricks the victim into executing the redirect back to the RP. The RP receives the redirect, fetches the attributes from the IdP, and associates the victim's RP session with the attacker's resources that are accessible using the tokens. The victim user then accesses resources on behalf of the attacker.
The impact of such an attack depends on the type of resource accessed. For example, the user might upload private data to the RP, thinking it is uploading information to its own profile at this RP, and this data will subsequently be available to the attacker; as described by Li and Mitchell [13], an attacker can use a CSRF attack to control a victim user's RP account without knowing the user's username and password.

Existing CSRF Defences
Barth et al. [3] describe four mechanisms that a website can use to defend itself against CSRF attacks: validating a secret token, validating the HTTP Referer header, including additional headers with an XMLHttpRequest, and validating the HTTP Origin header. All of these mechanisms are in use on the web today, but none of them are entirely satisfactory.
-Secret Validation Token. One approach to defending against CSRF attacks is to send additional information in the form of a secret validation token in each HTTP request; this token can be used to determine whether the request came from an authorized source. The "validation token" should be hard to guess for attacker who does not already have access to the user's account. If a request does not contain a validation token, or the token does not match the expected value, the server should reject the request. -The Referer Header. In many cases, when the browser issues an HTTP request, it includes a Referer header that indicates which URL initiated the request. The Referer header, if present, distinguishes a same-site request from a cross-site request because the header contains the URL of the site making the request. A site can defend itself against cross-site request forgery attacks by checking whether the request in question was issued by the site itself. However, the Referer might contain sensitive information that impinges on the privacy of web users. -Custom HTTP Headers. Custom HTTP headers can be used to prevent CSRF attacks, because browsers prevent sites from sending custom HTTP headers to another site but allow sites to send custom HTTP headers to themselves using XMLHttpRequest. For example, the prototype.js JavaScript library 5 uses this approach and attaches the X-Requested-With header with the value XMLHttpRequest. To use custom headers as a CSRF defence, a site must issue all state-modifying requests using XMLHttpRequest, attach the custom header (e.g. X-Requested-with), and reject all statemodifying requests that are not accompanied by the header. This works because XMLHttpRequest does not allow an attacker to make a request to a third party domain by default. Thus, it is not possible for an attacker to forge a request with a spoofed X-Requested-With header. -The Origin Header. In many cases, the browser includes an Origin header, which indicates the request originates from an HTTP POST request as well as a Cross-Origin Resource Sharing (CORS) 6 request. Its use is similar to the Referer header, but it does not include any path information, only the server name.

Existing CSRF Defences for OAuth 2.0
As described in the OAuth Threat model [15], two possible mitigations [15] for a CSRF attack are as follows.
-A state parameter should be used to link the authorization request to the redirect URI used to deliver the code or access token (see Secret Validation Token in section 5.4). -RP developers and end users should be educated not to follow untrusted URLs.
The OAuth Threat model does not recommend use of the three other CSRF defences described in section 5.4. This is because the OAuth 2.0 response to the redirect URI is a cross-site request, since the request is generated by the IdP and is redirected to the RP by the browser; all the existing CSRF defences (except for use of the secret token) will therefore not work in this case.
It is important to observe that both the recommended mitigations delegate the responsibility for correctly implementing CSRF countermeasures to the RP developers. However, in practice, RPs do not always implement CSRF countermeasures in the recommended way. A study conducted by Shernan et al. [20] in 2015 found that 25% of websites in the Alexa Top 10,000 domains using Facebook's OAuth 2.0 service appear vulnerable to CSRF attacks. Further, a 2016 study conducted by Yang et al. [24] revealed that 61% of 405 websites using OAuth 2.0 (chosen from the 500 top-ranked US and Chinese websites) did not implement CSRF countermeasures; even worse, for those RPs which support the state parameter, 55% of them are still vulnerable to CSRF attacks due to misuse/mishandling of the state parameter. They also disclosed four scenarios where the state parameter can be misused by the RP developers.
This means that, if CSRF attacks are to be prevented in practice, new and simple-to-implement CSRF countermeasures would be extremely valuable. This motivates the work described in the remainder of this paper.

A new approach
Since the requirement to add a state parameter to an authorization request is often ignored by RP developers, large numbers of real-world OAuth 2.0 implementations are vulnerable to CSRF attacks; moreover traditional Referer header, Origin header and Custom header countermeasures are infeasible in the OAuth 2.0 framework (see section 5.5). We propose to combine the Referer header and the fact that RPs register different URIs for different IdPs (see section 3.1) to provide a novel means of mitigating CSRF attacks. We first describe how a Referer header can be used to mitigate CSRF attacks against the redirect uri in both the Authorization Code Grant Flow of OAuth 2.0 and the (very similar) Authorization Code Flow of OpenID Connect.

Protecting the Authorization Code (Grant) Flow
Normally an authorization response is only generated after a user clicks on a grant button rendered by the IdP (see fig. 6.1). The HTTP message (see, for example, listing 1.1) of such an authorization response contains a Referer header which points to the IdP domain. In practice, major IdPs, such as Google, Facebook and Microsoft, implement an 'automatic authorization granting' feature [14]. That is, when the user has logged in to his/her OAuth 2.0 IdP account, the IdP generates an authorization response without explicit user consent. The HTTP message (see, for example, listing 1.2) of such an authorization response contains a Referer header which points to the RP domain.
The proposed mitigation operates as follows. When the RP receives an authorization response, it first retrieve the identity of the IdP from redirect uri and then checks that the domain in the Referer header is either the RP Domain or the IdP domain. If the domain of the Referer header is one of these two values, then the RP knows this is a genuine authorization response coming from the IdP; otherwise, the RP should discard this HTTP message and send an error page to the user. 10 Cookie: * * * 11 Connection: close Listing 1.3: HTTP message of a CSRF attack against redirect uri

Protecting the Implicit Grant Flow
We next describe how a Referer header can be used to mitigate CSRF attacks against the redirect uri in the Implicit Grant Flow of OAuth 2.0 or the Implicit Flow and Hybrid Flow of OpenID Connect.
As an example of how this might work in practice, suppose a web attacker creates the link https://rp.com/AIdP-callback#access_token=[accsstoken_ belongs_to_attacker_generated_by_AIdP] on attacker.com to try to launch a CSRF attack against the redirect uri RP registered with AIdP. As discussed in section 2.3, the access token in the Implicit Grant Flow is not immediately transferred when the UA is redirected to the RP. Thus the HTTP request message looks similar to the CSRF HTTP request described in listing 1.4. Note that the only difference between a normal HTTP message and a CSRF HTTP message in the OAuth 2.0 Implicit Grant is the Referer header. The RP can detect a CSRF attack by checking the domain of the Referer header is either the IdP identity it retrieves from the redirect uri or its own domain; it can then respond with different HTML depending on the HTTP messages it has received (see lines 22 and 47 in listing 1.4). Listing 1.4: Preventing CSRF attacks on OAuth 2.0 Implicit Grant

Supporting multiple IdPs
In the previous sections we described how the Referer header can be used to mitigate CSRF attacks against RPs which use redirect uri to track the user login intention. We now describe how the Referer header can be used to protect RPs using explicit user intention tracking.
The user log-in intention is stored in the session (Jsession=12345 in the example below). Thus, when the RP receives an authorization response (such as that in listing 1.5), it retrieves the IdP's identity from the session and checks whether the domain of the Referer header is either the IdP identity or its own domain. If the two values are the same then the RP knows that this is a genuine authorization response; otherwise, it should respond to the user with an error page.

Limitations of our approach
One possible limitation of the Referer header approach described above is that a UA might compress the Referer header in a (non-secure) HTTP request if the referring page is transferred via a secure protocol (e.g. HTTPS) [10]. This means that an RP which uses HTTP to register its redirect uri with an IdP cannot use the approach described in section 6 to defend against CSRF attacks against its redirect uri , since as part of compression the Referer header will be removed by the web browser when it redirects the authorization response to the RP (note that we assume here IdPs use HTTPS at their OAuth 2.0 authorization endpoint). This limitation is negated by the fact that that some IdPs, such as Amazon and Microsoft, require the RP to register its redirect uri using the HTTPS protocol. This means that the attack mitigation described above will work successfully for RPs supporting Amazon and Microsoft login. It would clearly be beneficial if other IdPs could change their registration process to require RPs to register their redirect uri using HTTPS, enabling all RPs to use our approach to mitigate CSRF attacks.

Conclusions
In this paper, we have proposed a new class of mitigations which can be applied to prevent CSRF attacks against redirect uri in OAuth 2.0 and OpenID Connect. Our approach is practical and simple to implement, and requires no changes to the IdP service; i.e. it can be adopted by an RP independently of what any other party does. We hope that RPs can adopt this approach to provide an additional layer of protection against CSRF attacks for their OAuth 2.0 and/or OpenID Connect services. Of course, adoption would likely be increased if this measure was recommended by major IdPs and/or included in the relevant specifications.