April 27, 2017

Last Updated on January 19, 2024

Editor’s Note: This post was originally published in April 2015 and has been updated for accuracy and comprehensiveness.
“Web cookies.” We see this term thrown around online quite a bit, whether it be in dialogue boxes requesting permission to use them, or site headers explaining the sites depend on cookies. Web cookies are small chunks of data that are sent from a website and stored on a user’s computer. This allows the browser to “remember” information from the site, making navigation and use more intuitive.
However, due to the fact they contain data, cookies (also called HTTP cookies, browser cookies, etc.) can also be a security risk. Securing cookies is one of many application security topics that doesn’t get the attention it deserves. Web application developers need to do everything they can to protect users’ cookies. Even applications that operate over SSL connections should have the secure flag set on cookies—especially cookies that contain session data, as a bare minimum protection against attacks.

What is a Web Cookie Secure Flag?

The cookie secure flag is a cyber security feature that ensures cookies will only get sent through encrypted channels, rather than the less secure routes. According to RFC, the exact definition is:

“The Secure attribute limits the scope of the cookie to “secure” channels (where “secure” is defined by the user agent). When a cookie has the Secure attribute, the user agent will include the cookie in an HTTP request only if the request is transmitted over a secure channel (typically HTTP over Transport Layer Security (TLS)” [RFC2818]).”

Why You Should Secure Cookies with Secure Flags

Here are a few good examples in the wild of why the Secure attribute can be so important for a business’s computer security program:
Let’s say I’m an attacker and I’m trying to steal your session ID by intercepting your session traffic.
If port 80 is open, and the application in questions handles redirection to port 443, it’s possible that the application will create and set the cookie values during the redirect. This will expose their values in clear, man-readable text when they are returned to the browser from port 80. This is pretty much a best-case scenario for a computer hacker, because all that’s required to steal your authentication cookie is to sniff the traffic between your browser and the server, and grab the cookie values when they are set. From there, all a hacker has to do is apply the values, and they could access a session.
If port 80 is open and set for redirect, but the application doesn’t create the cookies on the initial connection, my work as a hacker becomes harder. I need you to let the SSL connection take place in order to get cookie values, but then somehow convince you to connect to the server over a non-SSL connection. You might do this for me by opening a new tab and typing the full application URL into the address bar without specifying HTTPS. Or maybe I can get you to click on a link in a fraudulent email. Or I could try to get a link into the application that you will click on to create an HTTP connection. If a hacker can create any of these conditions, then your browser will send cookies without a secure flag to port 80 along with your request, effectively creating the best-case (for a hacker) scenario described above.
Even if port 80 isn’t open, I still have a shot at stealing your authentication credentials if I can capture your traffic. I’ll still need to let you connect to the application and set the cookies. Once they’re set, I need to redirect your traffic to an open port 80 (using DNS poisoning or ARP poisoning, for example). If I set up an invisible proxy that listens to port 80 and can get your system to think my proxy is the application server, then I can attempt to get your browser to connect via HTTP instead of HTTPS. If I succeed and your browser connects to my proxy on port 80 and gives me the request and the cookies, my proxy will try to connect to the server on port 80 and fail. But that’s okay because I’ve already got your cookies.
A couple of caveats to the above:

  • If my proxy is also on port 443 and you accept its insecure certificate, then secure flags don’t matter—because I’ll get all your traffic. That’s a security awareness concern beyond the scope of this blog post.
  • If the application sets an HTTP Strict Transport Security (HSTS) header, and the browser honors it, then setting the secure flag isn’t as critical. HSTS tells the browser to connect only via SSL for a given period of time (usually six months to a year). So even if I can convince you to specifically request HTTP instead of HTTPS, your browser will redirect to HTTPS without first contacting the server. My only hope as a hacker, in this case, is that I can proxy SSL and you accept the insecure certificate.

In short: any application that is meant to operate only over SSL should set the secure flag on all cookies. There’s no reason not to, and it’s easy to do. Yes, the presence of the HSTS header could make the secure flag redundant—but setting it won’t cause any problems. More importantly, it will be awhile before all the browsers out there honor HSTS. Do the sure-thing, and apply secure flags. It provides one more relief in a world of numerous security vulnerabilities.

More Information on Securing Cookies with Secure Flags:

To find out where your critical applications are vulnerable to attack and how to plug those gaps before attackers find them, contact Pivot Point Security.