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:
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:
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.
