HTTP COOKIES SECURITY

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 mechanism 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.

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 differentiate between different, distinct users accessing their resources. Remember, each user has adifferent 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 following 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-Cookie header 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 PREF cookie 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 Expires directive 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 example, 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 containing a unique identifier allowing the Web to differentiate incoming requests for the sameresource, all requests would revert to being stateless.3 The Web browser sends the appropriate cookies to each and every page because the Web browser has no idea which Web pages on the server actually use the data and which don’t. So, the browser simply sends all appropriate cookies all the time for all pages, regardless of whether the server-side code of the Web application actually uses cookies or not.We discuss the security problems of this design later in this section.

COOKIE ACCESS CONTROL RULES

Surely we aren’t transmitting every cookie we have to every Web site we visit, are we? The answer is: No. Only the cookies that are appropriate when requesting a given Web page are added to the outgoing request.What do we mean by appropriate cookies? Well, cookies can have access control rules that tell the Web browser which pages should get the cookie. For example, a cookie can tell the browser what domains, what protocols, or what paths it is valid for.When a browser wants to request a page from a Web server, it checks the URL of the resource against all the cookies in the browser’s cookie jar. If the URL passes all the access control rules for a cookie, then that cookie is added to the outgoing request. In Figure 8-1, we can see that the PREF cookie used by Google should only be sent with requests to URLs ending in .google.com, regardless of the URLs path or use of SSL.

Cookie access control rules form the basis for the access control rules used by all other client-side storage methods.We will examine these rules in fine detail now, and note any differences from these ground rules in the specific sections covering the other client-side storage methods.

Cookies can define access rules using three different properties. These rules determine which cookies are attached to an outgoing request. These properties are: which domain names can access the cookie; which path or folder structure is needed to access the cookie; and whether the cookie must be sent over a secured connection or not. By default, cookies will be sent with all requests to the same domain that set the cookie, regardless of the path and regardless of whether the channel is secure or not. Figures 8-2 through 8-4 illustrate the access control of a default cookie.