Security researchers at Feroot are warning application security professionals of the client-side security risk associated with unprotected cookie structures. Because cookies are so ubiquitous with all website types—from e-commerce and banking to social networks and SaaS applications—organizations need to be aware of the privacy and data exploitation risks associated with poor cookie security.
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
Host: www.websitesample.com
Accept-Language: en
An attacker sees something like this with HTTPS:
a9Gm3V+9CV411pLfyhDksansz7+uieldr7j0g+SKK3L3RFTRsQCpaSnSBZ59Vme+ DpDVJPvZdZUZHpzbbcqmSW1+3xXGsERHg9YDmpYk0VVDiRvw1H5miJivJeJ/FNUjgH0Bm VRWII6+T4MnDwmORPBV/orxP3HGwYCSIvyzS3MpmmSe4iaWKCOHQ==
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.
Example:
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 a step ahead of the simple “secure flag” and is often used to mitigate a specific type of XSS attack, in which a threat actor steals user information—like authentication tokens—stored in a cookie. However, the HTTPOnly flag will not prevent other scripting risks associated with XSS attacks. With the HTTPOnly flag activated, developers and security professionals ensure that JavaScript does not have cookie access. All cookie handling, as well as validation and navigation, is conducted by the HTTP protocol itself. With the HTTPOnly flag, many attacks can be prevented for the simple reason that client-side code can’t access critical information.
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
Gaining visibility into all the scripts that have access to and are trying to read web application cookies can be a manual and time-consuming process. An automated solution that employs client-side attack surface monitoring and JavaScript security policies can provide visibility. In particular, with automated JavaScript security policies, features include components that prevent unwanted cookie reads—essentially an automated HTTPOnly flag. Automated security policies can also prevent the read attempt for explicitly configured block/allow list and specified cookie APIs.
To see automated client-side attack surface monitoring and JavaScript security policies in action, schedule a no-strings-attached demo.
