Ebook Ajax security: Part 1

Attacking Client-Side Storage Myth: The client’s machine is a safe place to store data. There are several security issues when Ajax applications store data on the client. Not only is client-side storage easily viewed or modified by an attacker, client-side storage methods can also leak access to these storage spaces to untrusted third parties. This can allow an attacker to remotely read all offline data stored on the client by an Ajax applica-tion. Even security-conscious developers who explicitly avoid putting sensitive data in client-side storage systems can inadvertently do so when they use client-side storage to cache data tables or trees. Only by fully understanding the access methods of each client-side storage method and implementing expiration policies and proper access control can a developer truly secure an Ajax application that utilizes client-side storage. OVERVIEW OF CLIENT SIDE STORAGE SYSTEMS The client-side portions of Web applications have been hobbled from fully participating as major components of an application by four roadblocks: • Sufficient penetration of (semi-) standards compliant browsers allowing developers to easily write cross-platform client-side programs • Sufficient penetration of personal computers fast enough to parse and interpret large and complex client-side programs • A means to transmit data back and forth between the client and server without interrupting the user’s experience 201 CHAPTER 8 ATTACKING CLIENT SIDE STORAGE • A large, persistent data storage system on the client to persist the input and output of our computations between different pages The first requirement was satisfied by time as Web standards matured and Web develop-ers and users pressured the browser manufactures to conform to standards. It is now far easier to write cross-browser JavaScript than in the Web dark ages of the 1990s.Moore’s Law, which states computing power doubles every 18 months, took care of the second requirement. Modern computers run complex interpreted programs inside a browser much faster than before. Remember how long Java applets took to run in the mid 1990s on a Pentium 90 with 32MB of RAM? The third requirement was handled by the pillar of Ajax: the XMLHttpRequestobject.Ajax applications seamlessly move data without the long, full page refreshes of yesteryear. The final requirement has recently been met with the rise of JavaScript-accessible client-side storage systems. Offline Ajax is a perfect example. Offline Ajax allows users to access Web applications without being connected to the Internet.We discuss offline Ajax application in depth in Chapter 9,“Offline Ajax Applications.”However, client-side storage is essential for this capability. The benefits of client-side storage include reducing Ajax traffic by storing data on the client, improving a slow network connection, or persisting data across domains or browser instances. In this chapter we examine several different client-side storage meth-ods and discuss how to use them securely. Specifically, we examine HTTP cookies, Flash Local Shared Objects, Mozilla’s DOM storage, and Internet Explorer’s userData. Before we dive into the different implementations for client-side storage, we should examine how long the data is stored on the client. There are two classifications, persist-ent and nonpersistent, which denote how long data is stored in a system. Nonpersistent data is stored temporarily on the client and is discarded when the user closes the Web browser. Persistent data is stored on the client in a more permanent capacity. It survives if the user closes and reopens the browser, or even if she reboots her machine. Data stored persistently usually has an expiration date. Much like a jug of milk in your fridge, once the expiration date for the persistent data has passed, the Web browser deletes it. When developers are selecting a data storage system it is important to know whether the data stored in the system will be stored persistently. GENERAL CLIENT SIDE STORAGE SECURITY As we learned in the myth at the start of this chapter, there are several significant security concerns related to storing data on the client.When we examine each method for storing data on the client, readers should keep several questions in mind. Knowing the answers will help you pick the most appropriate and secure client-side storage method for your application. These questions include: 202 OVERVIEW OF CLIENT SIDE STORAGE SYSTEMS • What browsers are supported? While there are some frameworks like Dojo.Storage that attempt to abstract away the differences between storage methods, you could end up with a poorly implemented feature depending on which browser your users access your application with. • Does the storage method offer persistent,nonpersistent,or both forms of data storage? If you can only store data persistently, it is up to you to implement code to delete and purge data when appropriate. • How much data can you store? What is the default capacity? What is the maximum capacity? It does not matter how appealing the other features of a storage method are if it cannot offer enough space for your application. • What data types can you store? If a storage method can only save strings, then you will have to handle serialization and deserialization of other data types.As men- tioned earlier, this is a step that attackers like to focus on because it is very easy to cause Denial of Service attacks in custom serialization and deserialization code. Be aware of which storage methods force you to do some heavy lifting. • What are the access policies for the storage method? What other domains, services, and Web pages can access the data by default? What features does the storage method have that allow you to limit who can access the data? • How do you clean up or remove old data? Leaving unnecessary data around isn’t just sloppy, it can also be a security vulnerability.While no secret can be protected on the client, leaving the sensitive data scattered all around for long periods of time isn’t going to help matters. Pay attention to which methods automatically delete data for you or allow you to set an expiration date for the data. • How easy is it for the user to delete the data? If you pick a volatile storage method, your application will need to handle situations in which the client-side data disap- pears.You did write your application to handle errors gracefully, right? • How easy is it to read the data stored on the machine? Attackers can definitely read any data you store on the client, regardless of the method you pick. The real question is, how much work must an attacker perform to read what is stored? Never, never, never store anything secret in client-side storage! • How easy is it to modify the data stored on the machine? Attackers can definitely modify any data you store on the client, regardless of the method you pick. The real question is, how much work must an attacker perform to write over the stored data? This is an excellent vector to launch attacks and is another example of input that requires validation. 203 CHAPTER 8 ATTACKING CLIENT SIDE STORAGE HTTP COOKIES HTTP cookies are one of the most basic forms of client-side storage. To fully appreciate the limitations and security issues of using cookies as a storage mechanism, we must explorer the history of cookies. In case you missed the memo, HTTP is a stateless protocol. This means that the server treats each request as an isolated transaction that is not related to any previous request. Cookies were created in 1994 by Netscape as a means to impose a state-keeping mecha-nism on top of the HTTP. Fundamentally, cookies are a mechanism to allow the Web server to store a small amount of data on a user’s machine.A user’s Web browser attaches this cookie data to outgoing requests back to the Web server that set the data.1 Figure 8-1 shows the browser’s cookie jar—where cookies the Web browser has received are stored. Figure 8-1 The browser’s cookie jar displays a list of cookies the browser has and all of their properties. To impose state-keeping, a Web server can store a unique identifier for each visitor inside a cookie and send the cookie to the visitor’s Web browser. Every time that visitor requests a page from that Web server, their Web browser attaches the cookie containing the unique identifier to the outgoing HTTP request. This allows the Web server to differenti-ate between different, distinct users accessing their resources. Remember, each user has a 1 This is actually a simplification.We discuss how developers can control which cookies get sent to which Web servers later in this section. 204 HTTP COOKIES different unique identifier. This differentiation allows Web applications on the Web server to store session information about each user.2 Some common uses of session data include keeping the contents of a shopping cart or a user’s language preference. The fol-lowing are the HTTP headers of a Web server’s response where a cookie is set. HTTP/1.1 200 OK Server: Microsoft-IIS/5.1 Date: Wed, 06 Jun 2007 00:05:42 GMT X-Powered-By: ASP.NET Cache-Control: private Content-Type: text/html; charset=utf-8 Content-Length: 909 Connection: Keep-Alive Set-Cookie: shoppingCart=51349,90381,7744; Expires=Tue, 03-Jun-2008 05:00:00 GMT; Path=/Assign/Shop/ The Set-Cookieheader is what tells the Web browser to store a cookie. In the preceding code it appears that the cookie represents some kind of online shopping cart. Notice that in addition to a name/value of data to store, the Web application is able to specify other attributes of the cookie. For example, this cookie declaration sets an expiration date for the cookie. This means the cookie is stored persistently on the client’s machine until that expiration date. Once the expiration data has passed, the Web browser will automatically delete that cookie. There is no real limit on how far in the future the expiration date of a cookie can be set. Sharp-eyed readers will notice in Figure 8-1 that the PREFcookie that Google sets does not expire until 2038! If a cookie is set, but is not given an expiration date, it is considered a nonpersistent cookie and will be discarded when the user closes the Web browser. Thus, the use of the Expiresdirective allows Web applications to store arbitrary data persistently on the client inside a cookie, while excluding the Expires directive provides nonpersistent client-side data storage. It’s paramount to remember that cookies were designed to store small amounts of data on the client’s machine to impose state on top of HTTP. They weren’t intended to be a general client-side storage mechanism. This has profound consequences. For exam-ple, the Web browser sends the appropriate cookies to the Web server on each and every request. There is no way to change this behavior. In fact, it makes sense that the Web browser would send the appropriate cookies on every request.Without a cookie contain-ing a unique identifier allowing the Web to differentiate incoming requests for the same 2 As we saw in the “Session Hijacking”section of Chapter 3, if an attacker gains access to a user’s unique identifier he can impersonate that user by making fraudulent requests with the stolen unique identifier. 205 ... - tailieumienphi.vn