The key risk with unprotected cookies is user impersonation. This happens when malicious actors exfiltrate sensitive session/authentication tokens that have been saved in cookies, leading to the theft of credentials and personally identifiable information (PII), as well as credit card fraud. These types of attacks typically are the result of cross-site scripting (XSS), cross-site request forgery (CSRF), and network eavesdropping.
In this blog, we’ll take a look at cookie security and why organizations should be concerned, particularly with regards to user access tokens which are stored in cookies. We’ll also offer some thoughts on what businesses can do to identify and improve cookie security risks.
HTTP & HTTPS and Cookie Security
As the main protocol for transferring data over a network, the majority of the information that flows via HTTP is communicated using the rules and definitions established by the HTTP. By default, HTTP works without encryption. Any data that is being exchanged between two parties is in plain text, and any third person that happens to be looking at or “eavesdropping” on this data exchange can easily read the content. The types of information transferred via HTTP can be anything from cookies to content and API calls.
HTTPS is the secure version of HTTP and uses SSL/TLS by default to encrypt HTTP requests and responses.
So instead of seeing something like this through unencrypted HTTP:
GET /greeting.txt HTTP/1.1
User-Agent: curl/7.63.0 libcurl/7.63.0 OpenSSL/1.1.l zlib/1.2.11
An attacker sees something like this with HTTPS:
Web applications use HTTP cookies (a web cookie or browser cookie) for three main reasons: session management, personalization, and tracking. Cookies are used to indicate if multiple requests are coming from the same browser, for example, to keep a user logged in.
Even with most web applications now operating in only HTTPS mode, misconfigurations can still occur, exposing an HTTP-unprotected version of an API.
There are three primary ways to secure cookies so they can’t be intentionally or unintentionally accessed by a third party: Secure attribute, SameSite attribute, and HTTPOnly attribute.
#1: Secure Flag
To prevent cookie theft using man-in-the-middle or eavesdropping attacks that target unprotected HTTP cookies, developers and security professionals use something called the “secure flag” to ensure that cookies are only transmitted using a secure connection (SSL/HTTPS). This means that a web browser will never transmit a cookie if the connection is only set to HTTP. To set a “secure flag,” the developer or security professional must do it during an HTTPS connection, otherwise the security setting is ignored.
Since most web applications now operate in only HTTPS mode, “secure flag” settings may seem a bit meaningless, since no important communication should be occurring on the HTTP protocol. However, as mentioned previously, a misconfiguration in a web application can expose an HTTP-unprotected version of an API, in which case, the “secure flag” setting is useful.
This setting is also useful to avoid common eavesdropping attacks that target unprotected HTTP cookies.
Set-Cookie: sessionid=MqUckOwtyxZ9; HttpOnly; Secure
Example of setting the above cookie in PHP:
setcookie(“sessionid”, “MqUckOwtyxZ9”, [‘httponly’ => true, ‘secure’ => true]);
It’s important to note that while Secure Flag can prevent cookie theft from man-in-the-middle or eavesdropping attack, Secure Flag will not protect from cross-site scripting (XSS) or cross-site request forgery (CSRF) attacks.
#2: HTTPOnly Flag
The HTTPOnly Flag is useful for adding a layer of protection against threat actors trying to steal personal access tokens located inside cookies, which would enable them to impersonate a specific user.
#3: SameSite flag
The SameSite flag is an auxiliary flag that provides some defense and control over cross-site request forgery attacks (CSRF). However, the SameSite flag will not protect all actions in a CSRF. For example, the malicious CSRF code could attempt to initiate a GET/POST request (which can bypass the browser’s Same Origin Policy). The attack could then execute malicious actions on the site the user is logged in to.
Automated Script Protection