Cookie Path Best Practice

Cookies provide a method for creating a stateful HTTP session and their recommended use is formally defined within RFC2965 and BCP44.

Although they are used for many purposes, they are often used to maintain a Session ID (SID), through which an individual user can be identified throughout their interaction with the site. For a site that requires authentication, this SID is typically passed to the user after they have authenticated and effectively maintains the authentication state. If an attacker can use a mechanism (such as sniffing or cross site scripting) to gain access to the SID, then potentially they can incorporate it within their own session to successfully assume the users identity. The cookie specifications provide arguments for restricting the domain and path for which the user agent (browser) will supply the cookie. Both of these should be matched by the request before the user agent sends the cookie data to the server.

It is common for the path argument to be specified as the root of the origin server; a practise that can expose the application cookies to unnecessary additional scrutiny. It is worth noting however, that whilst the various “same origin” security issues still afflict the browser vendors, the specification of the cookie path argument is somewhat of a moot poin

1. Introduction

Cookies provide a method for creating a stateful HTTP session and their recommended use is formally defined within RFC2965 and BCP44. Although they are used for many purposes, they are often used to maintain a Session ID (SID), through which an individual user can be identified throughout their interaction with the site. For a site that requires authentication, this SID is typically passed to the user after they have authenticated and effectively maintains the authentication state. If an attacker can use a mechanism (such as sniffing or cross site scripting) to gain access to the SID, then potentially they can incorporate it within their own session to successfully assume the users identity.
The cookie specifications provide arguments for restricting the domain and path for which the user agent (browser) will supply the cookie. Both of these should be matched by the request before the user agent sends the cookie data to the server. It is common for the path argument to be specified as the root of the origin server; a practise that can expose the application cookies to unnecessary additional scrutiny. It is worth noting however, that whilst the various “same origin” security issues still afflict the browser vendors, the specification of the cookie path argument is somewhat of a moot point.

2. The Problem

The cookie standard is formally defined in RFC2965 [1]. This makes reference to the optional path argument that allows a cookie originator to specify “the subset of URLs on the origin server to which this cookie applies” [1]. The vast majority of web based applications simply set this argument to the root “/” of the origin server, either for simplicity or merely for lack of knowing any better. Where this oversight becomes useful is in conducting attacks against the session cookies of an application that does not suffer from any exploitable validation flaws, but that shares the same server environment with one that does.
As an example we shall imagine that a secure application shares a host with some sample files that were installed at the same time as the web server. Obviously, this would never happen in a live production environment (pauses to insert tongue firmly in cheek). The secure application is located within the “/secure” folder but sets the cookie path argument to
the root “/”. An attacker knows that the secure application has no useable vulnerabilities in itself.

However, they also know that the sample files have an exploitable cross-site scripting (XSS) flaw that would give them access to the all-important session cookies. All they now need is a method to get a valid user to access the sample files (a completely different problem to solve).
The secure application vendor might have otherwise followed all the best practise recommendations when developing their application, but they could still be exposing sensitive information through the loosely specified path argument.

3. The Solution

Fortunately the solution to this issue is a straightforward one. By simply specifying the cookie path argument accurately, an application can take measures to protect itself from flawed products that share the same hosting environment.

References [1] http://www.faqs.org/rfcs/rfc2965.html