Felisberto Hernández

In the following, we give an overview of existing research in the area of formal web security analysis, security analysis of OAuth 2.0 and security analysis of OpenID Connect.6

1.4.1. Formal Web Security Analysis

Early research in the direction of formal web security analysis includes work by Kerschbaum [Ker07], in which a Cross-Site Request Forgery protection proposal was formally analyzed using a very simple model of browsers, scripts, and web pages expressed using Alloy, a finite-state model checker [Jac02].

In their seminal work, Akhawe et al. [Akh+10] initiated a more general formal treatment of web security. Again the model was provided in the Alloy modeling language. In five case studies, Akhawe et al. showed that their model can be used to identify security problems in standards and web applications. The model by Akhawe et al. has been analyzed extensively in the diploma thesis of the author [Fet11].

Kumar et al. [Kum12;Kum14;Pai+11] combined an Alloy model with BAN logic to analyze and automatically find attacks in web protocols. They applied their approach to the Security Assertion Markup Language (SAML) and OAuth (see below).

Bansal et al. [Ban+_13;Ban+_{14;BBM12] built the WebSpi model for the web infrastructure,}

which is encoded in the modeling language of ProVerif. ProVerif is a specialized tool for cryptographic protocol analysis [Bla01] based on a variant of the applied pi-calculus [AF01].

6

OAuth 2.0 is very different to its predecessor, OAuth 1.0(a). Likewise, OpenID Connect is very different to its predecessor, OpenID. We therefore only list research on OAuth 2.0 or OpenID Connect in the following.

The WebSpi library models several important features of the web infrastructure, such as cookies, origins, local storage, and CORS. As such, at the time of writing, it is the most comprehensive web model that is amenable to tool-based analysis (cf. Section6 for recent developments). The WebSpi model has been applied successfully to find attacks in encrypted web storage services and deployments of OAuth 2.0 (for more details, see the next subsection).

While the models above support (partially or fully) automated analysis, they are necessarily tailored to and limited by constraints of the respective tools. For example, models for Alloy are finite-state. Terms (messages) need to be encoded in some way as they are not directly supported. Due to the analysis method employed in ProVerif, the WebSpi model is of a monotonic nature. For instance, cookies and localStorage entries can only be added, but not deleted or modified. Also, the number of cookies per request is limited, and several important features are missing (e.g., cross-document messaging, different redirection codes, and a precise structure of windows, documents, and iframes). These automated approaches therefore may miss important problems. Our model of the web is much more comprehensive and accurate, but requires manual proofs, at least for now (see the discussion on future work in Chapter6).

Bai et al. [Bai+13] developed the AuthScan tool which is capable of extracting an authenti- cation protocol specification from the protocol implementation. The extracted protocol specifi- cations were then fed into ProVerif for a security analysis. Armando et al. [Arm+_08;Arm+_13]

performed analyses of SSO (SAML and OpenID) based on custom-built models in the High- Level Protocol Specification Language (HLPSL++). Compared to our work, the models by Bai et al. and Armando et al. are not very detailed, since they focus mainly on the logic of the protocols. They do not consider a comprehensive model of the web infrastructure.

Bohannon and Pierce [BP10] proposed a formal model of a web browser core as a basis for experiments with security policies and mechanisms. There are several approaches towards track- ing and controlling information flow inside web browsers [Bau+15; Gro+12;Guh+11; HBS16;

Yos+09]. B¨orger et al. [BCG12] presented an approach for the analysis of web application frame- works, focusing on the server. None of these works include a model for the web infrastructure.

1.4.2. Security Analysis of OAuth 2.0

The work closest to ours is the already mentioned research by Bansal et al. [Ban+14;BBM12]. They analyzed the security of OAuth using their WebSpi library and ProVerif. Bansal et al. mod- eled various settings of OAuth 2.0, often assuming the presence of common web implementation flaws, for example, CSRF and open redirectors in RPs and IdPs.

They identified previously unknown attacks on the OAuth implementations of Facebook, Yahoo, Twitter, and many other websites. As pointed out by Bansal et al., the main focus of their work was to discover attacks on OAuth rather than proving security. They have some positive results, which, however, are based on their more limited model. In addition, in order to prove these results, further restrictions were required, e.g., they considered only one authorization server per client and all authorization servers were assumed to be honest.

Wang et al. [Wan+13] presented a systematic approach to finding implicit assumptions in software development kits (SDKs) used for authentication and authorization. Their case studies include the Facebook PHP SDK and other SDKs implementing OAuth 2.0.

Pai et al. [Pai+11] analyzed the security of OAuth in a very limited model that does not incorporate generic web features. They showed that through their approach, based on the Alloy finite-state model checker, known weaknesses can be found.

Chari, Jutla, and Roy [CJR11] analyzed the security of the authorization code grant in the Universal Composability (UC) model, again without considering web features, such as semantics of HTTP status codes, details of cookies, or window structures inside a browser.

Besides these formal approaches, empirical studies were conducted on deployments of OAuth. In [SB12], Sun and Beznosov analyzed the security of three IdPs and 96 RPs. In [LM14], Li and Mitchell studied the security of ten IdPs and 60 RPs based in China. In [Yan+16], Yang et al. performed an automated analysis of four OAuth IdPs and 500 RPs. Shernan et al. [She+15] evaluated the lack of CSRF protection in various OAuth deployments. In [Che+14; SM14], practical evaluations on the security of OAuth implementations of mobile apps were performed. Many of the works listed here led to improved security recommendations for OAuth as documented in [RFC6749] and [RFC6819]. These are already taken into account in our model and analysis of OAuth.

1.4.3. Security Analysis of OpenID Connect

As mentioned in the introduction, the only previous works on the security of OIDC are [LM16;

Mla+16]. In [LM16], the authors found implementation errors in deployments of Google Sign- In, which is based on OIDC. In [Mla+16], the authors described a specific variant of the AS Mix-Up Attack (see Section4.4) and highlighted the possibility of Server-Side Request Forgery attacks at RPs in the OIDC standard (see Section3.4). In contrast to our work, neither [LM16] nor [Mla+16] are based on formal analysis or establish security guarantees for the OIDC standard.

2. The Web Infrastructure Model

In this chapter, we present our model of the web infrastructure. We start with an overview of our design goals, before elaborating on the scope of the model, and eventually outlining our sources and approach. Subsequently, we outline the architecture before delineating the building blocks of the model. At the end of this section we demonstrate that our our model can be extended easily, using WebRTC as an example.

We introduce notations, formalisms, and definitions only as far as they are needed here. Some definitions in this section are simplified for presentation, in particular regarding the handling of nonces. All details, including the full definitions, can be found in AppendixA.

2.1. Building a Model of the Web Infrastructure

The design goal was to create a precise and rather comprehensive model of the web infrastructure. To this end, we decided to create a “pencil-and-paper model”, one that is not encoded in the language of an automated analysis tool, and as such, not constrained by the tool’s abilities. As we discuss in Chapter6, our model can serve as a basis for future efforts towards a tool-supported analysis of web standards and applications.

The scope of the model is chosen in a way that it covers meaningful classes of attacks on several layers of web applications, standards, and the web infrastructure:

– Attacks targeting interactions between web applications and browsers, for example, missing checks for the origin of messages sent between documents (e.g., [BJM08b;SS13]), the 307 Redirect Attack (cf. Section3.3.1), or leakage of OAuth tokens from URI fragments (as described in [RFC6819]).

– Attacks targeting the behavior of web browsers, for example, DNS rebinding [Jac+07], and attacks on the integrity of cookies [Zhe+15].

– Attacks targeting web application code on servers, for example, lack of user authen- tication or cross-site request forgery protections.

– Attacks targeting the network layer, for example, forgery of DNS responses and TLS stripping.

Conversely, certain aspects of the web infrastructure are considered out of the scope of our model. We do not model the following aspects:

– Language details: We employ an abstract model of JavaScript, i.e., we cannot model misuse of specific language features, timing attacks and race conditions in scripts, and do not track information flows inside scripts. We do, however, have an accurate model of the input and output behavior of JavaScript and our model precisely captures the effects that JavaScript, including malicious JavaScript, can have on other documents, network traffic, and the browser.

– Typing, corruption, and system details: We neither model buffer overflows or similar attacks in browsers, rendering or scripting engines, nor capture memory corruption attacks that can be triggered from JavaScript [GMM16]. We can, however, model the effects of browsers compromised by an attacker through such attacks.

– User interface details: We do not model a user interface, e.g., security indicators, overlapping frames, style sheets, etc. This prevents us from modeling, for example, browser fingerprinting [Eck10] or clickjacking attacks [Akh+14; Hua+12]. Again we can, however, capture the effects of such attacks. We also assume that a user can always distinguish between HTTPS and HTTP sites and that the user does not “click through” (ignore) browser warnings.

– Attacks on cryptography and TLS: As is typical for Dolev-Yao models, we assume that cryptographic primitives cannot be broken. For example, we assume that attackers cannot eavesdrop on the plain text exchanged in TLS connections without knowledge of the keys in use.

– Proprietary and deprecated technologies: Our model neither supports proprietary browser extensions such as ActiveX nor browser plugins like Flash or Java that use the Netscape Plugin API (NPAPI). While the NPAPI was once widely used, it has now been deprecated by browser vendors [Sch14;Sme15], first and foremost for its negative impact on browser security and user privacy [Sol+10].

To build our model, we studied the standards that define the web infrastructure and translated relevant parts into formalisms and notations of the model. As we describe more precisely in the following subsection, we provide, with a varying degree of abstraction, models for

– networking (IP [RFC791], TCP [RFC793], UDP [RFC768], DNS [RFC1034;RFC1035]),

– URIs [RFC3986] and HTTP/1.1 [RFC7230; RFC7231; RFC7232; RFC7233; RFC7234;

RFC7235],

– HTML5 [Ber+17],

– Cookies [RFC6265],

– Web Messaging [Hic15],

– the web origin concept [RFC6454],

– Fetch [Fetch],

– WebSockets [RFC6455],

– WebRTC [Ber+18]), and

– security technologies (HTTP Basic Authorization [RFC7617], Strict Transport Security [RFC6797], Referrer Policy [ES17]).

The initial version of the model, presented in [FKS14], contained only a subset of these tech- nologies. As outlined in Section1.3, more features were added over time.

To fill gaps where standards lacked details and to check the standards against the real-world implementations, we ran experiments for certain aspects of the modeling in the most popular browsers (Microsoft Internet Explorer and Microsoft Edge, Google Chrome, Mozilla Firefox).1