Securing HTTP Cookies

HTTP cookies are common in web development since cookies persist data on the browser. For web developers, cookies solve many problems with a stateless protocol. In the HTTP protocol, there are myriad possibilities available with cookies.

The challenge for programmers building web solutions is to wield HTTP cookies. There are many effective ways to work with cookies and secure them.

In Node, for example, setting an HTTP cookie is trivial:

var http = require('http');

var app = http.createServer(function onRequest(req, res) {
  res.setHeader('Content-Type', 'text/plain; charset=utf-8');
  res.setHeader('Set-Cookie', 'sessionCookie=value; HttpOnly');

  res.end('Setting a session cookie in the browser');
});

This sets a session cookie on the browser because there is no expiration date set on it.

Session cookies go away as soon as you close the browser window or tab. With HTTP cookies it is important to know how long you plan to persist the data on the browser. If you set an expiration date you get a permanent cookie and not a session cookie.

Cookies are set through HTTP headers, hence res.setHeader() in Node.

HTTP Only

One level of security with cookies is to enable HTTP Only. In my previous example, note the HttpOnly flag as part of the header.

The HttpOnly flag in cookies makes it so that you can’t change cookie values through JavaScript. This setting mitigates cross-site scripting (XSS) attacks.

The DOM API has a document.cookie property that allows attackers to change cookie data. A good approach to mitigate this risk is to turn on HTTP Only in all your cookies. This provides a level of basic security when clients attempt to tinker with the cookies.

For example, without this HTTP-only flag, one can do:

document.cookie = 'sessionCookie=newValue'; // Without HTTP only this persists

Turning HTTP Only tells the browser to persist cookie values from the server. It is an effective way of ensuring data integrity with HTTP cookies. Modern browsers will, for the most part, let you enable this setting.

Encrypted Cookies

HTTP cookies often come from the web server so consider encrypting cookie values. This adds a layer of protection since the browser client can’t decrypt the data. This makes it so that HTTP cookies are meaningful only to the back-end application.

Server-side encryption adds more protection because the client can’t sniff the cookies. The cookie values the browser gets are meaningless without proper decryption. With encryption, the server becomes the sole source of truth for HTTP cookies.

HTTP cookies are a server concern and a simple way to persist temporary data on the browser. A good approach is to prevent the client from knowing what the cookie means on the server. Encrypting the value of the cookie is a good way to mitigate this risk. If the value has encryption the client can’t know what it means. This prevents attackers from sniffing cookie values and crafting attacks on the server.

The encryption you use can be a one-way lookup of the cookie value. It is possible to use the encrypted value as the key to look up data on the server. This means there is no need to take the cookie value and assume it is valid on the server. The web server can use the encrypted value to confirm what it knows about the client from the session. This one-way look-up of encrypted cookie values adds an extra layer of protection.

In spite of the fact that cookie tampering got disabled through client-side JavaScript. Any attacker can craft an HTTP message with cookies and send them to your server. Encrypting cookies doing one-way loop-ups can mitigate even a well-crafted attack.

Client-Side Persistence

The browser will use cookies to persist data across HTTP requests. HTTP cookies are an effective way to keep data around that you may need later. Web developers often turn to cookies to solve many persistence problems.

One gotcha with cookies is users often expect the exact same experience across devices. With a cookie, you store data on the specific browser itself. In a mobile-first world, this way of solving persistence problems falls apart. HTTP cookies only persist data across many requests on the same browser, not on many devices.

The web server has no way of knowing where the HTTP request with a cookie comes from. Any attacker has the ability to craft cookies and dupe your web server. The web server, for the most part, has no way of knowing who sent the HTTP cookie.

It is important to keep in mind HTTP cookies solve a niche problem on the web. When you use cookies with the wrong assumptions it is easy to miss the mark or create security holes. Any system that blindly trusts HTTP cookies on the web server is open to attacks.

Consider using HTTP cookies as a simple way to identify who sent the request. Once a browser gets an HTTP cookie it can carry it around as a way of identifying itself. Think of it as an identity card browser clients have to tell you something about them. Of course, anybody can lose or steal identity cards so you need to validate them.

The web server can take whatever cookies the client sends and do a session validation. If the information stored on the session matches that of the browser you have a secure cookie. If it does not you have a potential attacker, you can then log their activity or have the app blow up in their face. With validation, you have a way of setting up security landmines to stop attackers in their tracks.

Conclusion

HTTP cookies solve the perennial problem with a stateless protocol. It is important to realize cookies come with limitations and pitfalls. You can mitigate risks with HTTP-only cookies, adding encryption, and cookie validation.

If you are using HTTP cookies for session management, take a look at this OWASP cheat sheet.

Before deploying your commercial or enterprise JavaScript apps to production, make sure you are protecting their code against reverse-engineering, abuse, and tampering with Jscrambler.

Start your free trial today!