keys to the cloud: formal analysis and concrete attacks on ...maffeis/papers/post13.pdf · wuala...

Keys to the Cloud: Formal Analysis and

Concrete Attacks on Encrypted Web Storage

Chetan Bansal1, Karthikeyan Bhargavan2,Antoine Delignat-Lavaud2, and Sergio Maffeis3,�

1 BITS Pilani-Goa2 INRIA Paris-Rocquencourt3 Imperial College London

Abstract. To protect sensitive user data against server-side attacks, anumber of security-conscious web applications have turned to client-sideencryption, where only encrypted user data is ever stored in the cloud.We formally investigate the security of a number of such applications, in-cluding password managers, cloud storage providers, an e-voting websiteand a conference management system. We find that their security relieson both their use of cryptography and the way it combines with com-mon web security mechanisms as implemented in the browser. We modelthese applications using the WebSpi web security library for ProVerif,we discuss novel attacks found by automated formal analysis, and wepropose robust countermeasures.

Keywords: Web Security, Formal Methods, Protocol Verification.

1 Application-Level Cryptography on the Web

Many web users routinely store sensitive data online, such as bank accounts,health records and private correspondence. Servers that store such data are atempting target for cybercrime: a single attack can yield valuable data, suchas credit card numbers, for millions of users. As websites move to using cloud-based data storage, the confidentiality of user data and the trustworthiness ofthe hosting servers has come further into question.

Transport layer security (TLS) as provided by HTTPS [21] does not fullyaddress these concerns. TLS protects sensitive data over the wire as it travelsbetween a browser and a website. However, it does not protect data at rest, whenit is stored on the client or the server, where it can be accessed by an attackerstealing a laptop or hacking into a server. To protect from these risks, webapplications use a combination of application-level cryptography and browser-based security mechanisms to securely handle user data. Our goal is to formallyinvestigate the effectiveness of these mechanisms and their concrete deployments.

Application-level cryptography. To protect data from hackers, websites like Drop-box [2] systematically encrypt all files before storing them on the cloud. However,

� Maffeis is supported by EPSRC grant EP/I004246/1.

D. Basin and J.C. Mitchell (Eds.): POST 2013, LNCS 7796, pp. 126–146, 2013.c© Springer-Verlag Berlin Heidelberg 2013

Keys to the Cloud 127

since the decryption keys must be accessible to the website, this architecture stillleaves user data vulnerable to dishonest administrators and website vulnerabil-ities. A more secure alternative, used by storage services like SpiderOak andpassword managers like 1Password, is client-side encryption: encrypt all data onthe client before uploading it to the website. Using sophisticated cryptographicmechanisms, the server can still perform limited computations on the encrypteddata [19]. For example, web applications such as ConfiChair [7] and Helios [4]combine client-side encryption with server-side zero-knowledge constructions toachieve stronger user privacy goals.

These application-level cryptographic mechanisms deserve close formal anal-ysis, lest they provide a false sense of security to their users. In particular, it isnecessary to examine not just the cryptographic details (i.e. what is encrypted),but also how the decryption keys are managed on the the browser.

Browser-based security mechanisms. Even with client-side encryption, the serveris still responsible for access control to the data it stores. Web authenticationand authorization typically rely on password-based login forms. Some websitesuse single sign-on protocols like OAuth [17] to delegate user authentication tothird parties. After login, the user’s session is managed using cookies knownonly to the browser and server. JavaScript is then used to interact with the user,make AJAX requests to download data over HTTPS, store secrets in HTML5local storage, and present decrypted data to the user.

The security of the application thus depends on both the server and onbrowser-based mechanisms like cookies and JavaScript. That is dangerous, con-sidering the prevalence of web vulnerabilities such as Cross-Site Scripting (XSS),Cross-Site Request Forgery (CSRF), open redirectors or phishing, even on ma-jor websites. In previous work, our survey of encrypted storage services [11]uncovered many such vulnerabilities and showed how can be exploited to bypassboth client-side and server-side cryptographic protections. However, these at-tacks were found by manual inspection aided by tracing tools. Can we search forsuch attacks systematically and exhaustively? More importantly, can we eval-uate any proposed countermeasures to ensure that they are not vulnerable tovariations of the same attacks? In response to both these questions, we follow[8] in advocating the automated formal analysis of web security mechanisms.

Formal analysis of cryptographic web applications. Standard cryptographic at-tacker models employ a crude notion of compromise: if a client or server per-forms any action outside the description of the protocol, it is considered com-promised. This characterization is too strong for web applications which maycontain dozens of pages, among which only a few are security-sensitive. We needa new attacker model that allows honest websites to have some vulnerable pages.

In previous work [8], we proposed WebSpi, a formal model of web attackersand browser-based security mechanisms, written as a library for ProVerif [12].We used WebSpi to analyze web authorization and single sign-on applicationsagainst a limited set of web attacks including CSRF and open redirectors. Here,

128 C. Bansal et al.

Table 1. Example encrypted web storage applications

Name Key Derivation Encryption Integrity Metadata Integrity Sharing

Wuala PBKDF2 AES, RSA HMAC � �(PKI)

SpiderOak PBKDF2 AES, RSA HMAC � �

BoxCryptor PBKDF2 AES None � �

CloudFogger PBKDF2 AES, RSA None � �(PKI)

1Password PBKDF2-SHA1 AES None � �

LastPass PBKDF2-SHA256 AES, RSA None � �

PassPack SHA256 AES None � �

RoboForm PBKDF2 AES, DES None � �

Clipperz SHA256 AES SHA256 � �

ConfiChair PBKDF2 RSA, AES SHA1 � �(PKI)Helios N/A El Gamal SHA256 Zero-Knowledge Proof N/A

we extend WebSpi to cover additional browser mechanisms such as local storage,AJAX, and the associated same origin policy, as well as to account for newattacks such as XSS, insecure cookies or JSONP-based CSRF.

The analysis of [8] did not address cryptographic issues. Here we extend Web-Spi to study a series of commercial and academic cryptographic web applications.Our analysis reveals several new web-based attacks that expose flaws in theircryptographic designs, and formally reconstructs attacks previously reportedin [11]. These attacks have been responsibly disclosed, and most were fixed inaccordance with our suggestions. Our formal analysis suggests new countermea-sures that are more robust in the face of web vulnerabilities. We verify thesedesigns against attackers modeled in WebSpi. In summary, our work extends thestate of the art by combining symbolic cryptographic protocol analysis with arealistic web attacker model. All the WebSpi scripts referenced in this paper areavailable online at http://prosecco.inria.fr/webspi/.

Related Work. A number of cryptographic protocols underlying real-world webapplications have been verified for sophisticated security properties. Closely re-lated to this paper are the symbolic analyses of ConfiChair [7], Helios [4], andPlutus [13]. However, none of these consider web attacks like CSRF and XSS, andas we show for ConfiChair and Helios, their security guarantees can be brokenby such standard web vulnerabilities.

Various attacks have previously been found on encrypted storage applications:on their cryptographic design [10], on their web deployment [5], and on combi-nations of the two [11]. Such attacks are typically found using ad hoc tracingtools, and these works do not offer any positive guarantees for countermeasures.These attacks serve as motivation for our fomal analysis.

Several works propose formal models of browser-based security mechanisms[24,15,6,16]. Closely related to our work are the models of [6], which capturemany of the same web vulnerabilities, and can be analyzed using Alloy [18]. How-ever, they do not generally consider cryptography, whereas our use of ProVerifenables a combination of cryptographic and web security analysis.

http://prosecco.inria.fr/webspi/


2 Encrypted Web Storage Applications

We study encrypted web storage, acore functionality of many security-conscious web applications. Morespecifically, we evaluate the design,implementation, and use of client-sideencryption in the web applications ofTable 1. The general architecture ofsuch applications is depicted on theright. They fall in three categories:File storage services, such as Wualaand SpiderOak, offer a remote en-crypted backup folder synchronized across various user devices with options toshare folders and files with non-registered users by sending web links.

Password managers, such as 1Password and LastPass, integrate with a browserto store user login credentials for different websites. When the user browses toa known website, the password manager offers to automatically fill in the loginform. The password database is kept encrypted on the client and backed up re-motely, and can be synchronized across the user’s devices.

Privacy-conscious websites, such as ConfiChair for conference management andHelios for electronic voting use client-side encryption to protect users againstpowerful attackers who may obtain control over the website itself.

All these applications implement an encrypted storage protocol and then useit to build more advanced features. We begin by describing one such protocol.

2.1 An Encrypted Storage Protocol

Suppose a user u has some sensitive data db with metadata m that she wishes tobackup on a storage server. For example, db may be a local file with name m, ordb may contain a password for the website m. u uses some client software a tocommunicate with the server b. When u creates or modifies db, a encrypts thedata and sends it to the storage server. Periodically, a downloads and synchro-nizes its local copy of the encrypted db with the storage server. u does not knowor trust the storage server, we assume it is somewhere in the cloud. We describethese two protocols below.

Notation. The cryptographic primitives crypt and decrypt represent symmetricencryption and decryption (e.g. AES in CBC mode); mac represents MACing(e.g. HMAC with SHA256); kdf represents password-based key derivation (e.g.PBKDF2). We model a TLS channel c with some server b as follows: an outgoingmessagem is denoted TLS→bc (m) and an incoming message is denoted TLS

←bc (m).

Update and Synchronization protocols. Assume that u and b share a secretsecretu,b and that a has a local encryption key K and MAC key K

′ that itnever sends to the server. These three secrets are stored on the client and maybe encrypted under a password for additional security.


Update Cloud Storage: Update(u,m,db)

a and b establish TLS connection c: TLS→bc (−), TLS←bc (−)1. a → b TLS→bc (Authenticate(u, secretu,b))

b verifies secretu,b and associates c with ua updates encdb to (m,e=crypt K db,h=mac K ′ (m,e))

2. a → b TLS→bc (Upload(m, e, h))b updates storage[u] to (m,e,h)

In the protocol above, Authenticate(a, secreta,b) denotes a tagged message re-questing authentication of user u with password secretu,b. Similarly, messageUpload(m, e, h) requests to upload the metadata m with the encryption e of thedatabase db under the key K, and the MAC h of m and e under the MAC keyK ′. Hence, this protocol protects the confidentiality and ciphertext integrity ofdb, and the metadata integrity of m. Some applications in Table 1 do not providemetadata integrity; in Section 4.3 we show how this leads to a password recoveryattack on 1Password.

The user data db is stored encrypted on the client. If an authorized userrequests to read it, the client a will verify the MAC, decrypt encdb, and displaythe plaintext. The synchronization protocol authenticates the user, downloadsthe most recent copy of the encrypted database, and verifies its integrity.

Synchronize with Cloud Storage: Synchronize(u)

a and b establish TLS connection c: TLS→bc (−), TLS←bc (−)1. a → b TLS→bc (Authenticate(u, secretu,b))

b verifies secretu,b and associates c with ub retrieves storage[u] = (m,e,h)

3. b → a TLS←bc (Download(m, e, h))a checks that mac K ′ (m, e) = ha updates encdb to (m,e,h)

Attacker Model. The protocols described above protect the user from com-promised servers, network attackers and stolen devices. In particular: an attackergaining control of a storage server, or of a device on which the client applica-tion is installed but not running, must be unable to recover any plaintext orinformation about user credentials; a user must be able to detect any tamperingwith the stored data; a network attacker must be unable to eavesdrop or tam-per with communications through the cloud. Under reasonable assumptions onthe cryptographic primitives, one can show that the reference protocol describedabove preserves the confidentiality of user data (see, for example [7]). However,such proofs do not reflect the actual deployment of web-based encrypted storageapplications, leading to attacks that break the stated security goals, despite theformal verification of their cryptographic protocols.


2.2 Deploying Encrypted Storage Protocols over the Web

Although encrypted storage protocols can be deployed using custom clients andservers, a big advantage of deploying it through a website is portability. Thestorage service may then be accessed from any device that has a web browserwithout the need for platform-specific software. This raises the challenge thatthe developer now needs to consider additional web-based attack vectors thataffect websites and browsers. Consider an encrypted storage protocol where theclient a is a browser and the server b is a website. We discuss the main designquestions raised by this deployment architecture.

Password-based Key Derivation. Browser a must be able to obtain the secretsecretu,b to authenticate to the server. Then it must be able to obtain the en-cryption key K and MAC key K ′. The usual solution is that all three of thesesecrets are derived from a passphrase, sometimes called a master password. Thekey derivation algorithm (e.g. PBKDF2) typically requires a salt and an iterationcount. Choosing a high iteration count stretches the entropy of the passphrase bymaking brute-force attacks more expensive, and choosing different salts for eachuser reduces the effectiveness of pre-computed tables [20]. In the following, weassume that each of the three secrets is derived with a different user-dependentconstant (Au, Bu, Cu) and a high iteration count (iter).

User Authentication and Cookie-based Sessions. To access a storage service a usermust log in with the secret secretu,b derived from her passphrase. Upon login,a session is created on the server and associated with a fresh session identifiersidu,b sent back to the browser as a cookie. The browser sends back the cookiewith every subsequent request, so the server can correlate all the user actionson the website even if these actions were taken in separate tabs, over differentHTTPS connections. This login protocol can be described as follows.

Web Login and Key Derivation: Login(u,p,b)

user on browser a navigates to https://b/logina and b establish TLS connection c: TLS→bc (−), TLS←bc (−)

1. a → b TLS→bc (Request(/login))2. b → a TLS←bc (Response(LoginForm))

user enters username u and passphrase pa derives and stores K = kdf p Au iter, K

′ = kdf p Bu itera derives secretu,b = kdf p Cu iter

3. a → b TLS→bc (Request(/login, user = u&secret =secretu,b))b verifies that secret = secretu,bb generates a cookie sidu,bb stores (sidu,b, u)

4. b → a TLS←bc (Response[sidu,b](LoginSuccess()))a stores (b, sidu,b)

We write Response[sidu,b](LoginSuccess()) to mean that the server sends an HTTPresponse with a header containing the cookie sidu,b and a body containing the

https://b/login/login/login


page representing successful login. All subsequent requests from the browser tothe server will have this cookie attached to it, written Request[sidu,b](· · · ).Browser-based Cryptography and Key Storage. The login protocol above and thesubsequent actions of the client role a of the encrypted storage protocol requirea to generate keys, store them, and use them in cryptographic operations. Toexecute this logic in a browser, typical websites use JavaScript, either as a scriptembedded in web pages or in an isolated browser extension. In some applications,the cryptography is also implemented in JavaScript (e.g. LastPass). In others,the cryptography is provided by a Java applet but invoked through JavaScript(e.g. ConfiChair). In both cases, the keys must be stored in a location accessibleto the script. Sometimes such cryptographic materials are stored in the browser’slocalStorage which provides a private storage area to each website and to eachbrowser extension.

When the performance or reliability of JavaScript is considered inadequate,a few storage applications (such as SpiderOak) instead cache decryption keyson the server and perform all decryptions on the server side; these keys arediscarded upon logout. In the rest of this paper, we generally assume that allcryptography is implemented on the client unless explicitly specified.

Releasing plaintext to authorized websites. In addition to update and synchro-nize, some storage services offer advanced sharing mechanisms. For example,password managers offer a form fill feature whereby user data is automaticallyretrieved, decrypted, and released to authorized websites. This feature is imple-mented by a browser extension or bookmarklet and activated when a user visitsa login page; the extension automatically fills the login form with the user’s cre-dentials for that page. In the protocol description below, the encrypted storageclient holding the database and its decryption keys is the browser extension x.

Automatic Form Filling for Web Login: Fill(b)

user on browser a navigates to https://b/logina and b establish TLS connection c: TLS→bc (−), TLS←bc (−)

1. a → b TLS→bc (Request(/login))2. b → a TLS←bc (Response(LoginForm))

a triggers browser extension x with the current page hostname3. a → x Lookup(b)

x looks up encdb for (b,e,h)x checks that mac K ′ (b, e) = hx computes (u, p) = decrypt K e

4. x → a Result(b, u, p)a fills LoginForm with (u, p)

Sharing with a web link. File storage services often allow a user to share a fileor folder with others, even if they do not have an account with the service. Thisworks by sending the recipient a web link that contains within it the decryptionkey for the shared file. The receiver can access the file by following the link.

https://b/login/login


URL-based File Sharing: Share(u,m)

user u sends to v the link U=https://b/?user=u&file=m&key=Kuser v on browser a navigates to U

1. a → b TLS→bc (Request[](U))b retrieves storage[u] = (m, e, h)b decrypts f = decrypt K e

2. b → a TLS←bc (Response[](Download(f)))

Sending decryption keys in plaintext links is clearly a security risk since the keycan easily be leaked. As a result, even services that offer link-based sharing donot use the same key for shared files as they do for private files. For instance,SpiderOak creates a fresh encryption key for each shared folder and re-encryptsits contents. When the owner needs to access and decrypt her own shared files,she must first retrieve this shared key from the server. We model this protocol inmore detail in Section 4. Other applications such as Wuala or CloudFogger usea more secure sharing scheme that relies on a public key infrastructure, allowingthe decryption key to be sent wrapped under the recipient’s public key.

2.3 Web Attacker Model

An encrypted storage application that uses JavaScript and cookie-based sessionsis exposed to, and must protect against, a range of web attack vectors.

Code delivery. In typical website deployments, the JavaScript code that performsclient-side encryption is itself downloaded from the web. If the attacker controlsthe server hosting the JavaScript, he may corrupt the application code in orderto leak keys back to himself. Alternatively, if the code is downloaded over plainHTTP, a network attacker may tamper with the script.

XSS. In its simplest form, an attacker may be able to exploit unsanitized userinput in the application to inject JavaScript that gets inlined in the websiteHTML and run along with trusted JavaScript. This may give the attacker com-plete control over a web page in the browser and to all cryptographic materialsavailable to that page. Even carefully written security-conscious applications,such as Dropbox, LastPass, and ConfiChair, may still contain such weaknesses,as we show in Section 5. New browser security mechanisms are being proposedto address this issue [23].

Session Hijacking. Once a session is established, the associated cookie is the onlyproof of authentication for further actions. If an attacker gets hold of the sessioncookie, he can perform the same set of operations with the server as the user. InSection 5 we describe attacks of this kind that we found in several applications(including ConfiChair), even if they normally use HTTPS. A solution is forapplications to set the cookie in secure mode, disallowing the browser to send itover an unencrypted connection.

CSRF. When an action can be triggered by accessing some URL, for examplechanging the current user’s email address or his role in the session, a malicious

https://b/?user=&file=&key=


site can force its users to access this URL and perform the action on theirbehalf, with attacker-controlled parameters. Although it is up to the applicationto prevent these kind of attacks, various varieties of CSRF remain common, evenin security-oriented web services [9]. A common solution is to use an unguessableauthorization token bound to the user session and require it to be sent with everysecurity-sensitive request.

Phishing and Open Redirectors. Features involving third parties may introducenew attack vectors. For instance, in the automatic form filling protocol above,an untrusted website may try feeding the extension a fake URL instead of the le-gitimate login URL, to trick the extension into retrieving the user’s password fora different website. Similarly, open redirectors such as URL http://b/?redir=x,that redirect the user to an external website x, facilitate phishing attacks wherethe website x may fool users into thinking that they are visiting a page on bwhen in fact they are on website x.

In summary, the design of cryptographic web applications must account forprevalent web vulnerabilities, not just the formal cryptographic attacker of Sec-tion 2.1. Next, we introduce our methodology for analyzing such applications.

3 Automated Verification of Web Cryptography

We describe the WebSpi library for ProVerif, and discuss how it is used to modeland verify web applications. We show our extensions to WebSpi to model newJavaScript-based attacks. For details on ProVerif, see the official manual [14].

3.1 Processes

The language underlying ProVerif is a variant of applied pi-calculus [3]. Compu-tations are described as the interaction of message-passing processes that com-municate over asynchronous named channels. Knowing the name of a channelis enough to be able to send or receive messages on it. The name of a channeldefined as private to a process cannot be guessed by other processes, so the cre-ator controls its scope (that can be extended by sending the channel name toother processes). Processes have access to local databases where they can storeand retrieve messages. Atomic messages, typically ranged over by a, b, c, h, k, ...are tokens of basic types. Basic types are channels, bitstrings or user-defined.Messages can be composed by pairing (M,N) or by applying n-ary data con-structors and destructors f(M1, ...,Mn). Constructors and destructors are par-ticularly useful for cryptography, as described below. Pattern matching = M isextensively used to parse messages.

ProVerif models symbolic cryptography: cryptographic algorithms are treatedas perfect black-boxes whose properties are abstractly encoded using construc-tors and destructors. Consider authenticated encryption:

fun aenc(bitstring,symkey): bitstring.reduc forall b:bitstring,k:symkey; adec(aenc(b,k),k) = b.

http://b/?redir=xxxbx


Given a bit-string b and a symmetric key k, the term aenc(b,k) stands for thebitstring obtained by encrypting b under k. The destructor adec, given an au-thenticated encryption and the original symmetric key, evaluates to the originalbit-string b. ProVerif constructors are collision-free (one-one) functions and are,by default, only reversible if equipped with a corresponding destructor. Hence,MACs and hashes are modeled as irreversible constructors, and asymmetric cryp-tography is modeled using public and private keys:

fun hash(bitstring) : bitstring.fun pk(privkey):pubkey.fun sign(bitstring,privkey): bitstring.reduc forall b:bitstring,sk:privkey; verify(sign(b,sk),pk(sk)) = b.

These and other standard cryptographic operations are part of the ProVeriflibrary. Users can define other primitives where necessary. Such primitives canbe used for example to build detailed models of applications like ConfiChair [7].

The WebSpi library defines data types related to the HTTP protocol andprovides interfaces to the core functionality of browsers and web servers, in theform of a set of private channels. Application-layer protocols are expressed asprocesses linked to this channel interface. The rest of the network, includingpotential attackers, can be thought of as arbitrary processes with access to netand any other public channel.

3.2 WebSpi Architecture

In our model, users surf the web by interacting with web pages on browsers thatcommunicate on the public channel net over HTTP(S) with servers that hostweb applications.

Users. Users are endowed with, or can acquire, username/password credentialsto access applications. Applications are identified by a host name and a pathwithin that host. The behaviour of specific web page users can be modeled bydefining a UserAgent process that uses the browser interface described below.

Servers. Servers possess private and public keys used to implement encryptedTLS connections with browsers. These are stored in the serverIdentities table to-gether with the server name (protocol and host) and a flag xdr specifying if cross-domain requests are accepted. The WebSpi implementation of a server is given bythe HttpServer process below. HttpServer handles HTTP(S) messages (and encryp-tion/decryption when necessary) and routes parsed messages to the correspond-ing web applications on the channels httpServerRequest and httpServerResponse. Tomodel the server-side handler of a web application one needs to write a processthat uses this interface to send and receive messages.

let HttpServer() =in(net,(b:Browser,o:Origin,m:bitstring));get serverIdentities(=o,pk P,sk P,xdr) inlet (k:symkey,httpReq(u,hs,req)) = reqdec(o,m,sk P) inif origin(u) = o thenlet corr = mkCorrelator(k) in


out(httpServerRequest,(u,hs,req,corr));in(httpServerResponse,(=u,resp:HttpResponse,cookieOut:CookiePair,=corr));out(net,(o,b,respenc(o,httpResp(resp,cookieOut,xdr),k))).

Browsers. Each browser has an identifier b and is associated with a user. TheWebSpi implementation of a browser is given by the HttpClient process (we inlinesome fragments below). Cookies and local storage are maintained in global tablesindexed by browser, page origin and, only for cookies, path. JavaScript runningon a page can access cookies and storage associated with the page origin usingthe private channels getCookieStorage and setCookieStorage, in accordance to theSame Origin Policy. Cookies can be flagged as secure or HTTP-only. Securecookies are sent only on HTTPS connections and HTTP-only cookies are notexposed to pages via the CookieStorage channel. For example, the HttpClient codethat gets triggered when the JavaScript of page p on browser b wants to setcookies dc and store ns in local storage is:

in (setCookieStorage(b),(p:Page,dc:Cookie,ns:Data));get pageOrigin(=p,o,h,ref) in get cookies(=b,=o,=h,ck) ininsert cookies(b,o,h,updatedomcookie(ck,securejs(dc),insecurejs(dc)));insert storage(b,o,ns)

Here, the function updatedomcookie prevents JavaScript from updating the HTTP-only cookies of the cookie record ck.

The main role of the browser process is to handle requests generated by usersand web pages, and their responses. The location bar is modeled by channelbrowserRequest, which can be used by to navigate to a specific webpage. Loca-tion bar request have an empty referrer header. Hyperlink clicks or JavaScriptGET/POST requests are modeled by the pageClick channel. The browser attachesrelevant headers (referrer and cookies) and sends the request on the network.When it receives the response, it updates the cookies and creates a new page withthe response data. Process HttpClient also takes care of encrypting HTTPS re-quests, decrypting HTTPS responses, and handling redirection responses. AJAXrequests are sent to the browser on channel ajaxRequest. When the browser re-ceives the response to an AJAX request it passes on the relevant data to theappropriate web page. (Although we abstract away the tree-like structure of theDOM, we do represent its main features salient to modeling web interactions:cookies, hyperlinks, location bar, forms, etc.) We give the HttpClient code forsending a request req to URI u from page p, with referrer ref and AJAX flag aj:

let o = origin(u) in let p = path(u) inget cookies(=b,=o,=slash(),cs) in get cookies(=b,=o,=p,cp) inlet header = headers(ref, cookiePair(cs,cp), aj) inget publicKey(=o,pk host) inlet m = httpReq(u,header,req) inlet (k:symkey,e:bitstring) = reqenc(o,m,pk host) inout(net,(b, o, e));

The request header is obtained concatenating the referrer, the cookies cs forpath “/” and cp for path p and the AJAX flag aj. If needed one could extend


the model by including additional headers such as Origin [9]. Note how thecode retrieves the public key pk host of the destination server, which is used tocreate the symmetric key k and the encrypted message e. The origin parameter opassed to the encryption function reqenc specifies if the chosen protocol is HTTPor HTTPS. In the former case, e equals m.

To model the client side of a web application, one needs to write a pro-cess that can access the private browser interface channels pageClick, ajaxRequest,getCookieStorage and setCookieStorage.

Web Attacker Model. Representing the network as a public channel netenables the standard Dolev-Yao network attacker, that can intercept and injectmessages but is not able to break cryptography. To model a compromised server,we simply release its private key on a public channel so that an arbitrary attackerprocess can impersonate the server. We enable XSS and code injection attacksby defining a process AttackerProxy that receives messages on a public channel(available to the attacker) and forwards them on the browser’s private channels.The parameters sent on these channels include the browser and page ids, whichare normally secret. We can selectively enable the compromise of a specific pageon a specific browser by releasing the corresponding ids to the environment.CSRF attacks are enabled by the willingness of the user to visit attacker websitesand by the ability of our model to represent GET/POST requests and attachthe corresponding cookies.

Verification in WebSpi. The verification model of WebSpi is the same as inProVerif. Security goals in ProVerif are typically written as correspondence asser-tions between events embedded in the code [12]. The command event e(M1,...,Mn)inserts an event e(M1,...,Mn) in the trace of the process being executed. A scriptin fact contains processes and queries of the form ∀M1, ...Mk. e(M1, ...Mk) ⇒ φ.ProVerif tries to prove that whenever the event e is reachable, the formula φis true (φ can contain conjunctions or disjunctions). In Section 4 we will showconcrete security queries.

The soundness properties of ProVerif [12] also hold for our security policies.If an expect is satisfied, then it is satisfied in all traces of running the applied-piprocesses defined in the script in parallel with any arbitrary attacker processes.If ProVerif proves that an expect is not satisfied, it outputs a proof derivationthat explains how an attacker can trigger an event that violates the policy.

Although very expressive, WebSpi is not a complete model of the web. Forexample, our model of the Same Origin Policy does not include tagsfrom different origins within the same page, and we do not model several HTTPheaders such as Origin and ETag. Hence, our main focus is on discovering at-tacks, which can be validated in the real world, rather than on providing positiveguarantees, which may be violated in practice due to omissions in our model.

4 Analyzing Encrypted Web Storage Services

In this section, we analyze three web applications that use the cloud to storeencrypted secrets. We show how to model these applications using WebSpi and


verify them using ProVerif against realistic web attackers. We show how webvulnerabilities enable concrete attacks that leak secrets to a web attacker. It isdifficult to completely eradicate such vulnerabilities from complex, real-worldweb applications. For that reason we propose countermeasures that harden suchapplications even in the presence of vulnerabilities.

4.1 ConfiChair

ConfiChair [7] is a cloud-based conference management system that seeks to offerstronger security and privacy guarantees than current systems like EasyChairand EDAS. Each conference has a chair, authors, and a program committee(of reviewers). Once a user logs in atthe login page, she is forwarded toa Conferences page where she maychoose a conference to participatein. The user may choose her role inthe conference by clicking on “changerole” which forwards her to the rolepage. Papers and reviews are storedencrypted on the web server, and eachuser holds keys to all papers and reviews she is allowed to read in a keypurse.For example, each paper has an encryption key (generated by the author) thatis stored in the author’s and conference chair’s keypurses. Each conference has aprivate key stored only in the chair’s keypurse and a shared reviewer key that isstored in each reviewer’s keypurse. Each user’s keypurse is also stored encryptedon the web server under a key derived from her password. The password itselfis not stored there, instead a separate key derived from the password is used toauthenticate the user. The web server authenticates users before sending themtheir keypurses and enforces role-based access control to conference actions andper-user access control to papers and reviews. All the cryptography for decrypt-ing and encrypting keypurses, papers, and reviews is performed in the browserusing a combination of JavaScript and a Java applet.

WebSpi Analysis. We model and evaluate paper downloads using WebSpi.

Login. We model the login page using two processes: LoginApp represents aserver-side webpage listening for requests on https://confichair.org/login, andLoginUserAgent represents the client-side JavaScript and HTML downloaded fromthis URL. These processes implement the web login protocol of Section 2.2, butdo not yet derive the encryption and MAC keys.

The process LoginUserAgent downloads a login form, waits for the user to typeher username and password, derives an authentication credential from the pass-word and sends the username and credential to LoginApp over HTTPS (throughthe network channel between the browser and HTTP server processes):

let loginURI = uri(https(), confichair, loginPath(), nullParams()) inout(browserRequest(b),(loginURI, httpGet()));in (newPage(b),(p:Page,=loginURI,d:bitstring));

https://confichair.org/login


get userData(=confichair, uid, pwd, paper) inlet cred = kdf1(pwd) inin (getCookieStorage(b),(=p,cookiePair(cs,ch),od:Data));out (setCookieStorage(b),(p,ch,storePassword(pwd)));event LoginInit(confichair, b, uid);out(pageClick(b),(p,loginURI,httpPost(loginFormReply(uid,cred))))

Notably, the process stores the password in the HTML5 local storage corre-sponding to the current origin https://confichair.org, making it available toany page subsequently loaded from this origin. When the user logs out, the localstorage is purged.

The server process LoginApp is dual to the LoginUserAgent. It checks that thecredential provided by the user in the login form is valid (by consulting a server-side database modeled as a table) and creates a session id passed to the browseras a cookie for all pages on the website, before redirecting the user to the con-ferences page.

Paper Download. We model all the conference pages using a server-side pro-cess ConferenceApp and a client-side process ConferenceUserAgent. The processConferencesUserAgent first makes an AJAX request to retrieve the encrypted key-purse of the logged in user. It then decrypts the keypurse using a key derivedfrom the cached password and stores the decrypted keypurse in local storage forthe current origin (https://confichair.org).

let keypurseURI = uri(https(), confichair, keyPursePath(), nullParams()) inout (ajaxRequest(b),(p,keypurseURI,httpGet()));in (ajaxResponse(b),(=p,=keypurseURI,JSON(x)));in (getCookieStorage(b),(=p,cookiePair(cs,ch),storePassword(pwd)));let keypurse(k) = adec(x, kdf2(pwd)) inout (setCookieStorage(b),(p,ch,storeKeypurse(k))))

For simplicity, the keypurse contains a single key, meant for decrypting thecurrent user’s papers. Subsequently, the user may at any point ask to downloada paper and decrypt the downloaded PDF with the keypurse.

let paperURI = uri(https(), h, paperPath(), nullParams()) inout (ajaxRequest(b),(p,paperURI,httpGet()));in (ajaxResponse(b),(=p,=paperURI,JSON(y)));in (getCookieStorage(b),(=p,cookiePair(cs,ch),storeKeypurse(k)));let paper = adec(y,k) in event PaperReceived(paper))

Security Goals. We model two simple security goals for our ConfiChair websitemodel. First, the login mechanism should authenticate the user. This is modeledas a correspondence query:

event(LoginAuthorized(confichair,id,u,c)) =⇒event(LoginInit(confichair,b,id))Second, that a user’s papers must remain syntactically secret. We model thisusing an oracle process that raises an event when the attacker successfully guessesthe contents of a paper

in(paperChannel, paper:bitstring);get userData(h, uId, k, =paper) in event PaperLeak(uId,paper).

https://confichair.orghttps://confichair.org


We then ask whether the event PaperLeak is ever reachable. The queries writ-ten here are quite simple. More generally, they must account for compromisedusers whose passwords are known to the attacker. For the login and conferencesprocesses above, these queries do indeed hold against an adversary who controlsthe network, some other websites that honest users may visit, and some set ofcompromised users.

Attacker Model: XSS on Role Page. Our security analysis found a number ofweb vulnerabilities. Here we describe how the change-role functionality on theConfiChair webpage is vulnerable to an XSS attack. If an attacker can trick a userinto visiting the URL http://confichair.org/?set-role=S


expose the wrapping key in a secure cookie only for those pages. For example,suppose all pages that need access to the wrapping key are served from the sub-domain secure.confichair.org, whereas all other pages are served from theparent domain confichair.org. The wrapping key can then be set as a cookiefor the sub-domain, pages in the parent domain will not be able to access it. Inthis design, the website never has both the key and the encrypted data. Duringlogin the browser has the password and the website has the encrypted data.After login, the browser has a re-encrypted keypurse and the website has thefresh encryption key. With these changes our secrecy and authentication queriesare verified by ProVerif. That is, if the login and conferences pages are hostedon the secure sub-domain and are XSS-free, then XSS attacks on other pagesdo not impact the security of the application. Whether this countermeasure ispractical or even resistant to more sophisticated iframe-based attacks requiresfurther investigation.

4.2 SpiderOak

SpiderOak is a commercial cloud-based backup, synchronization and sharing ser-vice. It advertises itself as “zero-knowledge”, that is, the SpiderOak servers onlystore encrypted data, but never the associated decryption keys. Users typicallyuse downloaded client software to connect to SpiderOak and synchronize theirlocal folders with cloud-based encrypted backups. However, SpiderOak also pro-vides its users with a web front end to access their data so that they can reador download their files on a machine where they have not installed SpiderOak.

When a user logs into the SpiderOak website, her decryption keys are madeavailable to the web server so that it can decrypt a user’s files on her behalf.These keys are to be thrown away when the user logs out. However, if theuser shares a folder using a web link with someone else, the decryption key istreated differently. The key is embedded in the web link, and it is also stored onthe website for the file owner’s use. We focus on modeling this management ofshared folders (called shared rooms) on SpiderOak.

WebSpi Analysis. The SpiderOak login process is similar to ConfiChair, ex-cept that besides the derived authentication credential it sends also the plaintextpassword to the server. After login, the user is forwarded to his root directory,from where he may choose to open one of his shared folders (called shared rooms).

The process SharedRoomUserAgent models the client-side JavaScript triggeredwhen the user accesses a shared folder. It makes an AJAX request to retrievethe URL, file names, and decryption key for the folder. It then constructs a weblink consisting of the URL, file name, and the decryption key and uses the URL-based sharing protocol of Section 2.2 to retrieve its files. The server-side processSharedRoomApp responds to the AJAX request from the user: it authenticatesthe user based on her login cookie, retrieves the folder URL, file names, anddecryption key from a database and sends it back in a JSON formatted message.It also responds to GET requests for files, but in this case the user does not haveto be logged in; she can instead provide the name of the file and the decryptionkey as parameters in the URI.

secure.confichair.orgconfichair.org


Similarly to ConfiChair, we set two security goals: user authentication andsyntactic file secrecy. ProVerif is able to show that our SpiderOak model pre-serves login authentication but it fails to prove file secrecy as we explain below.

JSONP CSRF Attack on Shared Rooms. The SpiderOak shared rooms page isvulnerable to a CSRF attack on its AJAX call for retrieving shared room keys.If a user visits a malicious website while logged into SpiderOak, that websitecan trigger a cross-site request to retrieve the shared room key for the currentlylogged-in user. The browser automatically adds the user’s login cookie to therequest and since the server relies only on the cookie for authentication, it willsend back the JSON response to the attacker. The attacker can then retrieve thefile by constructing a web link and making a GET request.

This CSRF attack only works if the target website explicitly enables cross-domain AJAX requests, as we found to be the case for SpiderOak. In our Spi-derOak model, the SharedRoomsApp page sets the xdr flag, and ProVerif finds theCSRF attack (as a violation of file secrecy).

Mitigations and Countermeasures. We experimentally confirmed the attack onthe SpiderOak website and on our advice, SpiderOak removed cross-domain ac-cess to shared rooms. As in ConfiChair, we consider whether a different design ofSpiderOak would make it resistant to attack even if it had a CSRF vulnerability.

One countermeasure is to encrypt the shared room key with the owner’s pass-word. Hence, only the owner can decrypt the key, but that is adequate sinceother shares are given the key in the web link anyway. ProVerif shows that withthis fix the attacker is no longer able to obtain the file, even though the CSRFattack is still enabled. The attacker can get the file URL but not the key.

4.3 1Password

1Password is a password manager that uses the cloud only as an encrypted store.Typically, it uses Dropbox to backup and replicate a user’s encrypted passworddatabase. To protect these passwords in transit, on Dropbox, and on each device,the password database is always encrypted on the client before uploading. Eventhough 1Password does not host any website, we show that it is nonethelessvulnerable to web-based attacks.

Password managers such as 1Pass-word provide a browser extension thatmakes it easier for users to managetheir passwords. The first time a uservisits a login page and enters his pass-word, the browser extension offers toremember the password. On futurevisits, 1Password offers to automati-cally fill in the password. Concretely, the extension looks at the origin of thepage and uses it to lookup its database. If a password is found, it is decryptedand filled into the login form.

WebSpi Analysis. We model 1Password and its browser extension as a processthat waits for messages from a page on a channel extensionChannel; it then looks


Table 2. Web vulnerabilities in cloud storage websites

Name Alternate Login Insecure Cookie XSS CSRF Open Redirector Frameable

Dropbox OAuth � � � � �

SpiderOak HTTP Auth � � � � �

LastPass YubiKey � � � � �

PassPack YubiKey � � � � �

ConfiChair None � � � � �

Helios OAuth, OpenID � � � � �

for an entry for the current origin in the password database (called a keychainstore). If it finds an entry, it asks the user for a master password, uses it todecrypt the username and password, and returns them on the extension channelto the requesting page. This protocol corresponds to the automatic form fillingprotocol of Section 2.2, except that 1Password does not include a MAC withthe encrypted data. We compose this extension process with a standard loginapplication, for example, as in the SpiderOak model, to obtain a simple modelfor 1Password. Login authentication and password secrecy are the security goals.

Metadata Tampering on the Password Database. 1Password is designed to beresistant to attacks on Dropbox and to an attacker who has stolen a user’sdevice. We model an attacker with read/write access to the encrypted passworddatabase. Each password entry in 1Password is stored as a separate text file inDropbox, so our model captures attackers who can read or write to these files.When composed with this attacker and a malicious website, ProVerif finds thatpassword secrecy is violated (hence, so is login authentication).

The attack proceeds as follows: the attacker reads the entry for (say) Spi-derOak from the database and replaces the hostname SpiderOak with the nameof his own server, Mallory. Since the origin is not encrypted or integrity-protectedin the database, this modification remains undetected. The next time the uservisits Mallory’s website, the page requests a password for Mallory and the 1Pass-word extension instead provides the password for SpiderOak, which gets leakedto Mallory. We call this attack a metadata tampering attack since the attackermanages to modify the metadata surrounding an encrypted password. Similarattacks are applicable in other storage services.

Mitigations and Countermeasures. The metadata tampering attack only appliesif the attacker has write access to the encrypted database. Hence, one counter-measure is to make the database inaccessible to the attacker. A more robustsolution is to add metadata integrity protection to the password database. Asin the protocols of Section 2.2, we propose that both the ciphertext and allmetadata in a keychain should be MACed with a key derived from the masterpassword. ProVerif verified that this prevents metadata tampering, and hencepassword leaks, even if the password database is stored in an insecure location.

5 Concrete Attacks on Encrypted Web Storage Services

We have shown how to formally analyze core components of three encryptedweb storage services using WebSpi and ProVerif. In each case, we found that


the security provided by cryptography was circumvented by a web-based attack.For illustration, Table 2 summarizes vulnerabilities on storage websites foundby us and by others. Besides XSS and CSRF, this table notes websites that didnot use secure cookies and were thus vulnerable to session hijacking, those thathad open redirectors that may lead to phishing, and those that were framableand thus vulnerable to clickjacking. These vulnerabilities are ubiquitous on theweb and seem difficult to avoid on realistic websites. We now explain the impactof such vulnerabilities on our target applications. All the attacks below werediscovered and reported by us, either during this work, or in [11].

Metadata Tampering. Encrypted storage services such as BoxCryptor, Cloud-fogger, and 1Password aim to be resilient to the tampering of encrypted dataon DropBox. However, these applications failed to protect metadata integrity,so an attacker could confuse users about their stored data. For example, onecould rename an encrypted file in BoxCryptor and replace an encrypted file inCloudFogger without these modifications being detected.

User Impersonation. Both ConfiChair and Helios can be attacked if a logged-inuser visits a malicious website. If a logged-in conference chair visits a maliciouswebsite, the website may use a series of CSRF and clickjacking attacks to closesubmissions or release referee reports to authors. On Helios, the problem is moreserious. If a user authenticates on Helios using Facebook (a common usage pat-tern), any malicious website she subsequently visits may steal her authenticationtoken and impersonate her, even if she logged out of Helios. The attack relieson an open redirector on Helios and the OAuth 2.0 protocol implemented byFacebook, and corresponds to a token redirection attack previously found usingWebSpi [8]. This attack undermines voter authentication on Helios, and lets anattacker modify election settings by impersonating the election administrator.

Password Phishing. Password managers are vulnerable to a variety of phishingattacks where malicious websites try to fool them into releasing passwords fortrusted websites. Metadata tampering, as shown for 1Password, also applies toRoboform. Another attack vector is to use carefully crafted URLs that are in-correctly parsed by the password manager. A typical example is http://a:b@c:d,which means that the user a with password b wants to access website c at port d,but may be incorrectly parsed by a password manager as a user accessing web-site a at port b. We found such vulnerabilities in 1Password and many popularJavaScript URL parsing libraries. We also found that password managers likeLastPass that use bookmarklets are vulnerable to JavaScript rootkits [5].

6 Conclusions

In this paper, we formally analyzed 3 encrypted web storage applications, anddescribed concrete security attacks in 7 more. Our reports resulted in securityupdates for Wuala, 1Password, LastPass, and SpiderOak, and security advisoriesfor the ConfiChair and Helios websites, others are being discussed. WebSpi isa useful tool for evaluating web applications and for experimenting with their

http://a:b@c:d


design to make them more resilient to standard web vulnerabilities. As Web-Spi is not complete, we leave the task of modeling even more attacks, such asframing [22], JavaScript rootkits [5], and other scenarios [1], to future work.

References

1. Browser security handbook, http://code.google.com/p/browsersec2. How secure is Dropbox?, https://www.dropbox.com/help/27/en3. Abadi, M., Fournet, C.: Mobile values, new names, and secure communication.

SIGPLAN Not. 36, 104–115 (2001)4. Adida, B.: Helios: Web-based open-audit voting. In: USENIX Security Symposium,

pp. 335–348 (2008)5. Adida, B., Barth, A., Jackson, C.: Rootkits for JavaScript environments. In: Work-

shop on Offensive Technologies, WOOT (2009)6. Akhawe, D., Barth, A., Lam, P.E., Mitchell, J., Song, D.: Towards a formal foun-

dation of web security. In: CSF, pp. 290–304 (2010)7. Arapinis, M., Bursuc, S., Ryan, M.: Privacy Supporting Cloud Computing: Con-

fiChair, a Case Study. In: Degano, P., Guttman, J.D. (eds.) POST 2012. LNCS,vol. 7215, pp. 89–108. Springer, Heidelberg (2012)

8. Bansal, C., Bhargavan, K., Maffeis, S.: Discovering concrete attacks on websiteauthorization by formal analysis. In: CSF, pp. 247–262 (2012)

9. Barth, A., Jackson, C., Mitchell, J.C.: Robust defenses for cross-site request forgery.In: CCS, pp. 75–88 (2008)

10. Belenko, A., Sklyarov, D.: “Secure Password Managers” and “Military-Grade En-cryption” on Smartphones: Oh, Really? Technical report, Elcomsoft Ltd. (2012)

11. Bhargavan, K., Delignat-Lavaud, A.: Web-based attacks on host-proof encryptedstorage. In: Workshop on Offensive Technologies, WOOT (2012)

12. Blanchet, B.: Automatic verification of correspondences for security protocols.Journal of Computer Security 17(4), 363–434 (2009)

13. Blanchet, B., Chaudhuri, A.: Automated formal analysis of a protocol for secure filesharing on untrusted storage. In: IEEE Symposium on Security & Privacy (2008)

14. Blanchet, B., Smyth, B.: ProVerif: Automatic Cryptographic Protocol Verifier,User Manual and Tutorial, http://www.proverif.inria.fr/manual.pdf

15. Bohannon, A., Pierce, B.C.: Featherweight Firefox: Formalizing the core of a webbrowser. In: WebApps (2010)

16. Groß, T.R., Pfitzmann, B., Sadeghi, A.-R.: Browser Model for Security Analy-sis of Browser-Based Protocols. In: De Capitani di Vimercati, S., Syverson, P.F.,Gollmann, D. (eds.) ESORICS 2005. LNCS, vol. 3679, pp. 489–508. Springer, Hei-delberg (2005)

17. Hammer-Lahav, E., Recordon, D., Hardt, D.: The OAuth 2.0 Authorization Pro-tocol. IETF Internet Draft (2011)

18. Jackson, D.: Alloy: A Logical Modelling Language. In: Bert, D., Bowen, J.P., King,S., Waldén, M. (eds.) ZB 2003. LNCS, vol. 2651, p. 1. Springer, Heidelberg (2003)

19. Kamara, S., Lauter, K.: Cryptographic Cloud Storage. In: Sion, R., Curtmola, R.,Dietrich, S., Kiayias, A., Miret, J.M., Sako, K., Sebé, F. (eds.) FC 2010 Workshops.LNCS, vol. 6054, pp. 136–149. Springer, Heidelberg (2010)

http://code.google.com/p/browsersechttps://www.dropbox.com/help/27/enhttp://www.proverif.inria.fr/manual.pdf


20. Kelsey, J., Schneier, B., Hall, C., Wagner, D.: Secure Applications of Low-EntropyKeys. In: Okamoto, E., Davida, G., Mambo, M. (eds.) ISW 1997. LNCS, vol. 1396,pp. 121–134. Springer, Heidelberg (1998)

21. Rescorla, E.: HTTP over TLS. Request for Comments 2818, IETF (2000)22. Rydstedt, G., Bursztein, E., Boneh, D., Jackson, C.: Busting frame busting: a study

of clickjacking vulnerabilities at popular sites. In: Web 2.0 S&P (2010)23. Stearne, B., Barth, A. (eds.): Content Security Policy 1.0. W3C Working Draft

(2012)24. Yoshihama, S., Tateishi, T., Tabuchi, N., Matsumoto, T.: Information-Flow-Based

Access Control for Web Browsers. IEICE Transactions E92-D(5), 836–850 (2009)

Keys to the Cloud: Formal Analysis and Concrete Attacks on Encrypted Web StorageApplication-Level Cryptography on the WebEncrypted Web Storage ApplicationsAn Encrypted Storage ProtocolDeploying Encrypted Storage Protocols over the WebWeb Attacker Model

Automated Verification of Web CryptographyProcessesWebSpi Architecture

Analyzing Encrypted Web Storage ServicesConfiChairSpiderOak1Password

Concrete Attacks on Encrypted Web Storage ServicesConclusions

keys to the cloud: formal analysis and concrete attacks on ...maffeis/papers/post13.pdf · wuala...

Documents