Nasrat Dernaika

Security in Cookies

Blog Post created by Nasrat Dernaika Employee on Apr 12, 2017

What is a Cookie?

A cookie is a small file sent by a website (or set by a web server) and stored by the end-user's browser. Cookies let us get around the statelessness of the HTTP protocol by storing data at the client-side. Cookies are set using the Set-Cookie HTTP Header, sent in an HTTP response from the web server. This header instructs the web browser to store the cookie and send it back in future requests to the server. In most cases, a cookie is primarily used as either an authentication token or data storage vehicle.

 

The Problem with Cookies

  • Cookies are stored on the client-side and in some cases may contain sensitive data (e.g. an IP address of an internal server or PII) that is set in clear text. Therefore, the cookie data is in complete control of the client; it can be modified or overwritten or captured and reused.
  • Cookies are passed over HTTP, and HTTP does not encrypt the headers in anyway. This leaves cookies susceptible for sniffing attacks.
  • Cookies are used to store session data. These are known as Session cookies. They store the respective Session ID of the user. The real power of the session happens server side where the Session ID is used to pull data stored on the server that you don't want the client to have access or authorize an end-user for example. Imagine the damage that can be caused when a Session ID is sniffed and replayed again by a malicious attacker via a MITM or Replay attack.

 

Identifying your Next Steps to Secure a Cookie

To identify the security measures you should take to protect your cookie, you should ask yourself the following questions:

  • Does my cookie contain any sensitive information? and how sensitive is it?
  • Is my cookie passed over TLS? Does it need to persist if the user leaves an TLS portion of the site?
  • Does the cookie need to work across different sub domains?
  • What part of the my site really need to access my cookie?
  • Does my cookie restrict access to Java scripts?

 

Protecting your Cookie

  • Encrypt cookies in the Browser to protect them at-rest and in-transit. This can be done using a software of Javascript APIs. Encrypting the cookie itself will protect you against:
    • Session Hijacking: if the cookie is sent in an encrypted manner, attempts for hijacking attacks will be mitigated in this case, even if the cookies are sent over clear HTTP.
    • Sniffing Attacks: in case someone gains local access to your computer and scans for cookies OR someone sniffs your cookie while in-transit, encrypted cookies prevent the attacker from viewing the cookie contents.
    • XSS Attacks: in case a cookie gets captured via a cross site scripting attack, the information or data is going to be non-usable in encrypted format or will add a layer of complexity for the attacker to decrypt the captured info.Last but not least, encrypting your cookies in the browser provides you with user privacy.
  • Pass your cookies over TLS to protect your cookie in-transit.
  • Set the right attributes for your cookies to secure them and make them safer. Below is a list of attributes that can be set on a per-cookie basis which makes them safer to use:
    • Secure: informs the browser (or other http clients) to only send the cookie over secure connections (HTTPS or TLS). This means that the cookie will not be available to any part of the site that is not secure, it also makes it much less likely that you will accidentally send the cookie in clear text.
    • HTTPOnly: informs the browser that it should not allow Java scripts to access the content of a cookie. This helps protect against XSS attacks as it will prevent hackers from being able to retrieve and use session or other type of info through such an attack.
    • Domain: allows you to specify whether or not to send the cookie to sub-domains. Setting “www.foo.com” for instance will mean only the exact domain “www.foo.com” will be matched, while setting “.foo.com” will also match again any sub-domain (e.g. support.foo.com, blog.foo.com, etc...)
    • Path: specifies the location or path the cookie is valid for. For example, the default value of “/” means every request will get the cookie, while “/services/” would limit the cookie to just that path. This path is going to be based on the actual URL the browser uses, before any mod_rewrite or URL mapping. It is important when using this attribute to use as restrictive a path as possible to avoid attacks launched from co-located apps.
    • Expires: offers strong protection against misuse of cookies because it erases the cookie when the expiration date is met. If this attribute is not set then the cookie will be erased when the browser is closed by the end-user.
    • SameSite: has been introduced by Google Chrome recently. This attribute offers a robust defense against CSRF attacks when deployed in strict mode, and when supported by the client. It basically requests the browser to only send the cookie in a first-party context (when you are using the web application directly). When another site tries to request something from the web application, the cookie is not sent. This effectively makes CSRF impossible, because an attacker can not use a user’s session from his site anymore. This attribute might not be supported by Akamai at this point. Please reach out to your account team to confirm.

       

      Here are some good references on the SameSite attribute:

 

You will find some of the best practices or guidelines we discussed above under OWASP Secure Coding Practices Checklist - OWASP 

 

The Professional Services team (or yourself) can help improve the security of your cookie by setting the right attributes for your cookie at the edge in your Akamai configuration.

 

Please reach out to you account team to discuss your cookies security posture in depth.

Outcomes