3 important things to know about cookie security

Feroot security researchers warn application security professionals of the client-side security risk associated with unprotected cookie structures. Because cookies are so ubiquitous on all types of websites, from e-commerce and banking to social media and SaaS applications, organizations should be aware of the privacy and data mining risks associated with improper cookie security.

The main risk with unprotected cookies is user impersonation. This occurs when malicious actors exfiltrate sensitive session/authentication tokens that have been stored in cookies, leading to the theft of credentials and personally identifiable information (PII), as well as card fraud credit. These types of attacks are typically the result of cross-site scripting (XSS), cross-site request forgery (CSRF), and network eavesdropping.

In this blog, we’ll look at cookie security and why organizations should be concerned, especially when it comes to user access tokens that are stored in cookies. We will also offer some thoughts on what companies can do to identify and improve cookie security risks.

There are client-side security threats associated with unprotected cookies and user access tokens.  Find out if you are at risk.  Schedule a demo today.  Schedule a demo.
Cookie security is a key part of client-side protection. Find out if your sensitive cookie data is secure. Schedule a demo.

As the primary protocol for transferring data on a network, the majority of information that travels over HTTP is communicated using the rules and definitions established by HTTP. By default, HTTP works without encryption. All data exchanged between two parties is in plain text, and any third party viewing or “listening” to this data exchange can easily read the content. The types of information transferred over HTTP can range 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 over 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/FNUjgH0BmVRWII6+T4MnDwmORPBV/orxP3HGwYCSIvyzS3MpmmSe4iaWKCOHQ==

Web applications use HTTP cookies (a web cookie or a browser cookie) for three main reasons: session management, personalization, and tracking. Cookies are used to indicate whether multiple requests come from the same browser, for example, to keep a user logged in.

Even with most web applications now only running in HTTPS mode, misconfigurations can still occur exposing an unprotected HTTP version of an API.

There are three main ways to secure cookies so that they cannot be viewed intentionally or unintentionally by a third party: the Secure attribute, the SameSite attribute and the HTTPOnly attribute.

Secure flag

To prevent cookie theft using man-in-the-middle or eavesdropping attacks that target unprotected HTTP cookies, developers and security professionals use what is calls the “secure flag” to ensure that cookies are only transmitted using a secure connection (SSL/HTTPS). This means that a web browser will never pass a cookie if the connection is only set to HTTP. To set a “secure flag”, the developer or security professional must set it during an HTTPS connection, otherwise the security setting is ignored.

Since most web applications now only work in HTTPS mode, the “secure flag” settings might seem a bit meaningless, since no significant communication should take place over the HTTP protocol. However, as mentioned earlier, misconfiguration in a web application can expose an unprotected HTTP version of an API, in which case the “secure flag” setting is useful.

This setting is also useful to prevent common eavesdropping attacks that target unprotected HTTP cookies.

Example:

Set-Cookie: sessionid=MqUckOwtyxZ9; HttpOnly; Secured

Example of setting the above cookie in PHP:

setcookie(“session id”, “MqUckOwtyxZ9”, [‘httponly’ => true, ‘secure’ => true]);

It is important to note that while Secure Flag can prevent man-in-the-middle cookie theft or eavesdropping attacks, Secure Flag does not protect against cross-site scripting (XSS) or cross-site request forgery attacks. (CSRF).

HTTP only 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 malicious actor steals user information, such as authentication tokens, stored in a cookie. However, the HTTPOnly flag will not prevent other scripting risks associated with XSS attacks. With the HTTPOnly flag enabled, developers and security professionals ensure that JavaScript does not have access to cookies. All cookie management, as well as validation and navigation, is performed by the HTTP protocol itself. With the HTTPOnly flag, many attacks can be avoided for the simple reason that client-side code cannot access critical information.

The HTTPOnly flag is useful for adding a layer of protection against malicious actors who attempt to steal personal access tokens located in cookies, allowing them to impersonate a specific user.

SameSite Indicator

The SameSite flag is an auxiliary flag that provides some defense and control against cross-site request forgery (CSRF) attacks. However, the SameSite flag will not protect all actions in a CSRF. For example, malicious CSRF code could attempt to initiate a GET/POST request (which may circumvent the browser’s same-origin policy). The attack could then perform malicious actions on the site to which the user is connected.

Automated script protection

Gaining visibility into all scripts that access and attempt to read web application cookies can be a manual and time-consuming process. An automated solution that uses 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 lists and specified cookie APIs.

To see automated client-side attack surface monitoring and JavaScript security policies in action, schedule a no-obligation demo.

The post 3 Important Things to Know About Cookie Security appeared first on Feroot.

*** This is a syndicated blog from Feroot’s Security Bloggers Network written by Breno Torres. Read the original post at: https://www.feroot.com/blog/3-important-things-to-know-about-cookie-security/

Comments are closed.