Keep Your Cookies in the Cookie Jar: HttpOnly and Secure Flags

What are cookies, anyway?

Cookies are a way to store information across multiple HTTP requests. HTTP is a stateless protocol, meaning each request is completely independent of subsequent requests. Cookies are set by the web server, and then stored in the user’s web browser. Each subsequent request to the domain specified in the cookie will then include the set cookies in the HTTP request headers, so the web server can continue to associate the following requests to that user. Some common use cases for cookies are authentication, analytics IDs, and user preferences.cook

So, what are cookie flags, then?

Cookie flags are attributes for a cookie that are set when the cookie is initialized. These attributes live for the duration of the cookie’s lifespan, so it’s important that they are set with secure attributes, especially for important cookies used for maintaining sessions or other sensitive user information. These attributes can quickly be seen by looking at a cookie in the browser, as shown below:

Example of cookies set with Secure and HttpOnly flags
HttpOnly Flag

The HttpOnly flag prevents a cookie from being accessed from protocols other than HTTP. This flag is mostly used so that client-side JavaScript cannot access the cookie.

Security Impact

When the HttpOnly flag is not set, client-side JavaScript is able to access and use the cookie. From an attacker’s perspective, it means the cookie is vulnerable to being stolen or used during other client-side attacks, such as in a Cross-Site Scripting (XSS) attack. For example, in our recently discovered XSS Vulnerability in ManageEngine Applications Manager (CVE-2021-31813), cookies were accessed through the inserted JavaScript and reflected back to the screen, as shown below:

Cookie accessed by inserted JavaScript in XSS vulnerability (CVE-2021-31813)

In a real scenario, an attacker may send the cookie to themselves instead of reflecting it to the screen. However, if the HttpOnly flags had been set, the malicious JavaScript could not have accessed the application’s cookies in the first place.

Secure Flag

The Secure flag prevents a cookie from being sent over HTTP and enforces the cookie to only be sent over HTTPS. This flag is used to prevent attackers from stealing cookies by sniffing unencrypted HTTP traffic. Even though there is a high usage of HTTPS, cookies can still be sniffed on redirects and through other means without the Secure flag. 

Security Impact

When the Secure flag is not set, the user’s cookies will be sent over HTTP if a request is made to that website’s HTTP port. Most websites now support HTTPS, but there are still multiple ways for cookies to be sent over HTTP even when the server supports HTTPS. For example, if a website’s web server redirects HTTP requests to use HTTPS, it’s possible the initial web request will have sent cookies that are not using the Secure flag. Similarly, if a user clicks on a link (e.g., from a phishing email) that doesn’t have https:// appended to it, the initial request will send any cookies for that website that are not using the Secure flag. An attacker that is sniffing traffic would then be able to see the cookie’s value in cleartext. The Strict-Transport-Security header can help to mitigate some of this impact, but, to ensure cookies are never sent over an unencrypted channel, the Secure flag should always be used.

Raxis X logo as document separator
Cookie Jar
PenTest As a SErvice

Penetration Testing as a Service doesn’t have to be a dressed up vulnerability scan. Raxis PTaaS delivers a solid pentest done right and when you need it.

Blog CAtegories