Cleartext storage of sensitive information in a cookie occurs when unencrypted and non-hashed sensitive information, such as personally identifiable information (PII), is stored in browser cookies. Exploitation may occur when an attacker is able to access these cookies by intercepting HTTP traffic or by accessing the web browser directly.

In this lesson, you will learn about vulnerabilities resulting from the storage of sensitive information in cookies, and how to protect your applications against them. For our example, we'll follow the story of a shady university student harvesting PII from library computers.

Gotham University is ranked the top university in the northern hemisphere. Getting good grades just isn't enough to get accepted here, they need to be exceptional. For this reason, many of the world's future leaders have spent time in these halls.

Among the current students is Sally, an enterprising cybersecurity student with a questionable moral compass. You see, Sally knows the value of personally identifiable information on the dark web. Student's personal details must be stored somewhere on university servers, and they would fetch a pretty penny if she could get her hands on them!

In the example above, the attacker was able to steal sensitive information by simply viewing cookies. In most cases, cookies are considered to be difficult for an attacker to get hold of, but there are situations where it becomes possible. In those cases, it is in our best interest to ensure that no sensitive information is contained within them.

The vulnerable code in the example above may be as simple as this:

The key thing to note in this example is that the data in the cookie contains user details. A cookie should never contain any sensitive information, especially PII, because cookies are relatively easy for anyone to view if they have access to a browser that the victim has used.

What should we do instead?

There are a few things you can do to mitigate this type of vulnerability. Let's take a look!

Sensitive information within a cookie is usually a sign of bad architecture. Instead of storing user details in cookies, it is far better to only assign session tokens as cookies. If sensitive details of a user are required, they can be accessed on the server side by associating the session token with a user.

If for whatever reason, your application's cookies end up storing sensitive information, it's best that they are well protected! Use these security flags on your cookies to make them a little bit harder to gain access to for an attacker.

HTTPOnly

Cookies offer an HttpOnly flag, which stops cookies from being accessed by JavaScript in the browser. This will thwart a hacker who is attempting to exfiltrate cookie data via a cross-site scripting vulnerability.

Secure

Cookies also offer a vaguely-named secure flag, which ensures that the cookie will never be sent over an unencrypted connection.

In an ideal world, cookies would expire instantly! Of course, in the real world, this would make browsing authenticated web applications very difficult. The shorter the expiry time is, the less likely it is to be discovered by an attacker and exploited. The longer an expiry time is, the less your users will need to re-authenticate.

We recommend having a think about what is an appropriate amount of time before the cookie expires and implementing a timeout.

The previous vulnerable code should use both security flags, shorten the timeout and store a token instead of user data:

Keep learning about cookies and storing sensitive information

• CWE for Cleartext Storage of Sensitive Information in a Cookie
• A blog post by Snyk, is local storage safe to use?
• Learn more about cryptography and hashing