Page History

Cookies are an essential part of any web application; they are used for many purposes, including user authentication. A cookie is a small piece of data that is set by a web server's response that is stored for a certain period of time on the client's computer. After a cookie has been set, all of the information within is sent in all subsequent requests to the cookie domain. Consequently, the information within a cookie is insecure; it is vulnerable to cross-site scripting (XSS) and man-in-the-middle attacks (among others). Servers must ensure that cookies lack excess or sensitive information about users. A partial list of such information includes user names, passwords, password hashes, credit cards, and any personally identifiable information about the user.

Noncompliant Code Example

In this noncompliant code example, the servlet stores the user name in the cookie to identify the user for authentication purposes.

...

Note that the noncompliant code example stores the user name and password within two cookie objects, which are sent to the client to be stored in a cookie. This code example is insecure because an attacker can discover this information by performing a cross-site scripting attack or by sniffing packets. Once the attacker gains access to the user name and password, he or she can freely log in to the user's account. Even if the application had stored only the user name within the cookie for authentication purposes, an attacker could still use the user name to forge his or her own cookie and bypass the authentication system.

Compliant Solution

This compliant solution stores user information using the HttpSesssion class within the javax.servlet.http package. Because HttpSession objects are server-side, an attacker cannot use cross-site scripting or man-in-the-middle attacks to directly gain access to the session information. Rather, the cookie stores a session id that refers to the user's HttpSession object stored on the server. Consequently, the attacker cannot gain access to the user's account details without first gaining access to the session id.

...

This solution also invalidates the current session and creates a new session to avoid session fixation attacks; see \[SD:OWASP 2009\].  The solution also reduces the window in which an attacker could perform a session hijacking attack by setting the session timeout to one.

Risk Assessment

Violation of this rule places sensitive information within cookies, making the information vulnerable to packet sniffing or cross-site scripting attacks.

Related Guidelines

Bibliography

...