Session cookies are often seen as one of the biggest problems for security and privacy with HTTP, yet often times, it's necessary to utilize it to maintain state in modern web applications. By default, it is insecure and vulnerable to be intercepted by an authorized party.
By adding the httpOnly flag, you are instructing the browser that this cookie should not be read by the JavaScript code. The browser will take care of the rest. This is how it looks after adding the httpOnly flag: cookie set with httpOnly flag. Notice the tick mark in the HTTP property. That indicates that httpOnly is enabled.
Cookies typically store session identifiers that may offer full access to an account, therefore if a cookie is intercepted, a session can be hijacked by someone who is not the real user but pretending as that user.
Securing cookies is an important subject. Think about an authentication cookie. When the attacker is able to grab this cookie, he can impersonate the user. This article describes HttpOnly and secure flags that can enhance security of cookies. HTTP, HTTPS and secure flag. When the HTTP protocol is used, the traffic is sent in plaintext. A blog by Jeff Atwood on programming and human factors.
For this reason, it's very important that we need to set parameters on how the cookies are passed and have it encrypted as they get sent/read between a web server and the browser.
In order to make cookies more secure to use, there are two things we need to pay attention to, they are HttpOnly and Secure flags.
HttpOnly Flag
The first flag we need to set up is HttpOnly flag. By default, when there's no restriction in place, cookies can be transferred not only by HTTP, but any JavaScript files loaded on a page can also access the cookies. This ability can be dangerous because it makes the page vulnerable to cross-site scripting (XSS) attack.
The only way to restrict this is by setting HttpOnly flag, which means the only way cookies are sent is via HTTP connection, not directly through other means (i.e., JavaScript).
Secure Flag
The second flag we need to pay attention to is Secure flag. This flag highlights the second issue that by default cookies are always sent on both HTTP and HTTPS requests. A malicious attacker who can't see encrypted traffic with HTTPS connection can easily switch to HTTP connection and access the same cookie because it is not encrypted. Therefore, we need to set the Secure flag to ensure that the cookie in encrypted when it's created.
Enable HttpOnly Flag in IIS
Edit the web.config file of your web application and add the following:
Enable Secure Flag in IIS
To enable secure flag in IIS, it is better to use URL Rewrite and add the following to your web.config file:
Check Flags Settings
This example demonstrates an ASP.NET website that has HttpOnly flag set, but not the Secure flag using a professional web scan tool.
The scanner did not detect secure flag in the HTTP header with the following explanations:
Cookie Missing ‘Secure' Flag
Description
The session ID does not have the ‘Secure' attribute set. This attribute prevents cookies from being seen in plaintext. It may be possible for a malicious actor to steal cookie data and perform session theft through man-in-the-middle (MITM) or traffic sniffing attacks. The exploitable condition exists for unencrypted cookies to be passed over the network if a user accesses the site through HTTP instead of HTTPS, or if a link to a resource such as an image file or CSS file within the specified domain uses the HTTP protocol.
Risk
Data may be exposed to unauthorized parties during cookie transmission and increases the risk of session theft via man-in-the-middle (MITM) or traffic sniffing attacks.
Recommendation
Change the default ‘Secure' attribute from FALSE to TRUE to ensure cookies are sent only via HTTPS. The ‘Secure' attribute should be set on each cookie to prevent cookies from being observed by malicious actors. Implement the ‘Secure' attribute when using the Set-Cookie parameter during authenticated sessions.
After applying the recommended configuration mentioned above, the scan result is good as shown below.
As you may have noticed, in this particular example, the Session Cookie Missing ‘HttpOnly' Flag was already fixed.
Checking the header using cURL:
Before
After
Notice the word secure after the HttpOnly at the end of the line of Set-Cookie HTTP header.
Emphasis
Download
Further Reading
HTTP/2 in Action
The Secure Attribute
The HttpOnly Attribute
httpCookies Element (ASP.NET Settings Schema)
Ensuring secure cookies with URL Rewrite
How to Setup HTTP Strict Transport Security (HSTS) on IIS
HTTP cookies can be created in two ways: either in the HTTP layer, on in the application layer in the DOM using JavaScript. And after they are created, some cookies can be accessed from either layer, depending on the application requirements.
HTTP cookies can be created in a web browser either by the Set-Cookie header in a HTTP response or using JavaScript using the document.cookie property. An example from JavaScript console:
The same cookie can be set using a HTTP response header:
This gives application developers great flexibility in customizing the application behavior to match user preferences — for example, if an user indicated a preference to see the website in Russian language, the application can set a cookie language=russian which the browser will send in all subsequent requests. Upon receiving the cookie, the application will then display content in appropriate language, always returning what the user has chosen to see. The cookie can be read from either the HTTP session (Cookie request header), which is what most server-side applications would do, or client-side using JavaScript, a mode preferred by most AJAX JavaScript-based applications.
The problem with the latter access method is that some types of cookies are never intended to be accessed outside of the HTTP channel — for example, session cookies often contain authentication tokens which, if exposed by a malicious JavaScript code, can be used to impersonate the user on the target website.
This would require a vulnerability such as Cross-Site Scripting to be present on the website but ability to hide the authentication cookie from JavaScript code significantly reduces impact of such attack. The httpOnly cookie flag does exactly that — it instructs the browser that this particular cookie should be never exposed to the JavaScript layer and only sent
The flag is defined in RFC 6265 and should be set on all authentication-related cookies that are no intended to be accessed by JavaScript. An example: Pinball arcade 8 1 0 2.
Such cookie will be still sent in the Cookie request header, accessible by the server-side web application code, but never exposed to the client-side browser DOM and not accessible from JavaScript.
Website Hacking Part V - Infosec Resources
Most web application security scanners will check if session cookies are set with the httpOnly flag and will raise an alert if it's not. Some broken security scanners will raise this alert for any cookies set by the website which is definitely an overkill and a false positive.
