1 Lightweight Integrity Protection for Web Storage-driven Content Caching Sebastian Lekies and Martin Johns SAP Research Karlsruhe ffi[email protected] Abstract—The term Web storage summarizes a set of browser- runs the malicious content (See Section III for examples). based technologies that allow application-level persistent storage Well-known cross-site scripting defense techniques such as of key/values pairs on the client-side. These capabilities are input validation or output encoding are not applicable in this frequently used for caching of markup or script code fragments, e.g., in scenarios with specific bandwidth or responsiveness scenario, as legitimate code fragments would also be rendered requirements. Unfortunately, this practice is inherently insecure, void by these XSS filters. as it may allow attackers to inject malicious JavaScript payloads In this paper we first investigate the usage of Web Storage into the browser’s Web storage. Such payloads reside in the with regards to code caching by investigating the front pages victim’s browser for a potentially prolonged period and lead to of the Alexa top 500.000 Web sites. Thereby, we found out resident compromise of the application’s client-side code. In this paper, we first present three possible attack scenarios that 20,422 Web sites make use of client-side storage and that that showcase how an attacker is able to inject code into web 386 Web sites store 2084 pieces of HTML, Javascript code storage. Then we verify that Web storage is indeed used in the or CSS style declarations within Local- or SessionStorage. outlined, insecure fashion, via a large-scale study of the top Furthermore, we present a method that allows a Web appli- 500.000 Alexa domains. Furthermore, we propose a lightweight cation to securely store code fragments on the client-side. integrity protecting mechanism that allows developers to store markup and code fragments in Web storage without risking a We achieve this by utilizing checksums that are calculated potential compromise. Our protection approach can be intro- for cached code. Whenever the code is fetched and executed duced without requiring browser modifications and introduces from Web Storage the application validates the checksum in only negligible performance overhead. order to ensure integrity of the stored content. Therefore, an attacker is not able to inject his payload into client-side storage capabilities and thus attacks are rendered void. I. INTRODUCTION The rest of the paper is structured as follows. After we Since the rise of Web 2.0 applications a shift from server- outlined the basics of Web Storage in Section II, we present side to client-side functionality is perceivable on the Web. three attack scenarios in Section III that could be utilized by Especially new HTML5 features such as Web Messaging, an attacker to smuggle his payload into the client-side Web Cross-Origin Resource Sharing or Offline Apps enrich the storage of a victim. After that, we investigate the usage of Web user-experience of modern Web applications. However, with Storage by presenting the results of a large-scale study of the the power of these new APIs comes the responsibility to utilize Alexa top 500,000 Web sites in Section IV. As pointed out by these features in a secure fashion. In the past some research the study results Web Storage is used in an insecure fashion work has already been conducted to reveal potential security when it is utilized for client-side code caching. Therefore, we issues with client-side technologies [1, 3, 4, 6, 12]. developed a JavaScript library that protects Web applications In this paper we investigate HTML5’s Web Storage API that from being exploited while still preserving the benefits of code consists of the SessionStorage and LocalStorage attributes [5]. caching. The basic idea, an evaluation and possible limitations Web Storage is a mechanism that allows a Web application of our approach are discussed in Section V. Finally, we present to store structured data within the user’s Web browser via related work in Section VI and a conclusion in Section VII. Javascript. While this API can be used for client-side state management, it is also often used for caching[17] (See Section II. TECHNICAL BACKGROUND IV for more details). Especially, in mobile environments where In this Section we briefly outline the technical backgrounds. bandwidth and latency matters Web-Storage-based caching can After covering the basics of Web Storage, we present different be a powerful technique to decrease loading times by saving use cases for the presented capabilities. and reusing frequently required scripts or style declarations on the mobile device[17]. However, caching such content in a storage that is accessible A. What is Web Storage? via scripting is a dangerous practice as it creates new attack Web Storage is a mechanism that allows a piece of vectors for adversaries. The cause of the problem is the fact Javascript to store structured data within the user’s browser [5]. that at one point in time, code written to the storage has to be Web Storage is, thereby, an umbrella term for two related func- executed again. Hence, if an attacker is able to exchange the tionalities - SessionStorage and LocalStorage. Each of these cached code with his payload, the application automatically storage types implements the same API and adheres to the 2 same security restrictions. The underlying storage mechanism implications to differ from the corresponding results for the is implemented via a key-value scheme that allows to store, established technologies. retrieve and delete a String value based on a certain key (See Listing 1 for an example). B. Use cases for Web storage Up to now, two usage patterns for Web storage have received Listing 1 Exemplary usage of LocalStorage some attention: Keeping state in offline situations and using <script> Web storage for caching purposes. We briefly revisit these //Set Item concepts in this section. localStorage.setItem("foo","bar"); However, the general concept of persistent, client-side Web ... storage is still a rather recent addition to the Web application //Get Item paradigm. Hence, not much experience has been documented, var testVar = localStorage.getItem("foo"); ... how these APIs end up being used by real-life Web appli- //Remove Item cations. Hence, to collect practical insight into this area, we localStorage.removeItem("foo"); conducted some applied survey work, which will be the subject ... of Section IV. //Clear all 1) State-keeping for offline apps: Modern browsers allow localStorage.clear(); </script> Web applications to provide offline capabilities. For this, the application can explicitly specify which of its Web resources should be kept in the browser’s application cache [2]. This In general, access to data stored within Web Storage is is done using a dedicated manifest file that lists the URLs limited to same origin resources only. Each site gets one of to be stored resources. In situations, in which the Web storage area assigned to it, so that data of different origins browser is disconnected form the network, these files, which is strictly separated. Therefore, data stored by a Web site on were stored earlier, are loaded and rendered from the appcache. a.net is only accessible to other resources from a.net, but not However, as no network connection is present to propagate the from b.net. user’s action to the Web server, all actions, which may have a 1) SessionStorage: SessionStorage was designed for permanent effect, have to be temporarily stored in the browser transaction-based scenarios in which a user is able to simul- until the browser reenters the online mode. For this purpose, taneously carry out the same transaction in multiple browser Web storage is well designed. windows. Within the same window, data can be stored and 2) Using Web storage for controlled caching of Web con- retrieved from the storage by any Web page loaded from the tent: The current caching facilities of Web browsers only same origin. A page loaded within another window posses its allow to cache the content of full HTTP responses, i.e., own storage and hence is not able to access the data from complete documents, scripts, or images. Furthermore, the another window. actual caching process is transparent to the application and 2) LocalStorage: LocalStorage differs from SessionStorage not under its control. Hence, in situation, in which the need in respect to scope and lifetime. As opposed to Session- occurs to either cache only sub-parts of HTML documents or Storage, data within the LocalStorage can also be accessed in which the application needs closer control in respect to the across different browser windows by same origin Web pages. cached content and its usage, Web storage provides the needed Furthermore, LocalStorage is persistent across sessions, while capabilities [15]. This seems to be especially appreciated in data within SessionStorage is discarded whenever the corre- the context of Web applications that target mobile devices, sponding session is closed. (Note: The lifetime of a session which, unlike their modern desktop counterparts, may have is unrelated to the lifetime of the corresponding user agent to deal with limited network bandwidth and high network process, as the user agent may support resuming sessions after latency [17]. restart[5].) III. ATTACKS 3) GlobalStorage: Earlier versions of the HTML5 spec- ification also contained the GlobalStorage directive. How- A. Insecure usage of Web storage ever, it was removed from the specification in favor of the As motivated in Section II-B2, a potential use case for Web LocalStorage API [9]. GlobalStorage holds multiple private storage is application-level content caching. In this context, it storage areas that can be accessed over a longer period of time has been documented [4, 7], that some applications use Web across multiple pages and sessions.