When the browser receives such a cookie, it is supposed to use it as usual in the following HTTP exchanges, but not to make it visible to client-side scripts.[21] The `HttpOnly` flag is not part of any standard, and is not implemented in all browsers. Note that there is currently no prevention of reading or writing the session cookie via a XMLHTTPRequest.[36]
The goal of this section is to introduce, discuss, and provide language specific mitigation techniques for HttpOnly.
Who developed HttpOnly? When?
According to a daily blog article by Jordan Wiens, “No cookie for you!,” HttpOnly cookies were first implemented in 2002 by Microsoft Internet Explorer developers for Internet Explorer 6 SP1. Wiens, [1]
What is HttpOnly?
According to the Microsoft Developer Network, HttpOnly is an additional flag included in a Set-Cookie HTTP response header. Using the HttpOnly flag when generating a cookie helps mitigate the risk of client side script accessing the protected cookie (if the browser supports it).
•The example below shows the syntax used within the HTTP response header:
Set-Cookie: <name>=<value>[; <Max-Age>=<age>]
[; expires=<date>][; domain=<domain_name>]
[; path=<some_path>][; secure][; HttpOnly]
If the HttpOnly flag (optional) is included in the HTTP response header, the cookie cannot be accessed through client side script (again if the browser supports this flag). As a result, even if a cross-site scripting (XSS) flaw exists, and a user accidentally accesses a link that exploits this flaw, the browser (primarily Internet Explorer) will not reveal the cookie to a third party.
If a browser does not support HttpOnly and a website attempts to set an HttpOnly cookie, the HttpOnly flag will be ignored by the browser, thus creating a traditional, script accessible cookie. As a result, the cookie (typically your session cookie) becomes vulnerable to theft of modification by malicious script. Mitigating, [2]
Mitigating the Most Common XSS attack using HttpOnly
According to Michael Howard, Senior Security Program Manager in the Secure Windows Initiative group at Microsoft, the majority of XSS attacks target theft of session cookies. A server could help mitigate this issue by setting the HTTPOnly flag on a cookie it creates, indicating the cookie should not be accessible on the client.
If a browser that supports HttpOnly detects a cookie containing the HttpOnly flag, and client side script code attempts to read the cookie, the browser returns an empty string as the result. This causes the attack to fail by preventing the malicious (usually XSS) code from sending the data to an attacker's website. Howard, [3]
Using Java to Set HttpOnly
Sun Java EE supports HttpOnly flag in Cookie interface since version 6 (Servlet class version 3)[4], also for session cookies (JSESSIONID)[5]. Methods setHttpOnly and isHttpOnly can be used to set and check for HttpOnly value in cookies.
For older versions there the workaround is to rewrite JSESSIONID value using and setting it as a custom header[6].
String sessionid = request.getSession().getId();
response.setHeader("SET-COOKIE", "JSESSIONID=" + sessionid + "; HttpOnly");
In Tomcat 6 flag useHttpOnly=True in context.xml to force this behaviour for applications[7], including Tomcat-based frameworks like JBoss[8].
Servlet 3.0 (Java EE 6) introduced a standard way to configure HttpOnly attribute for the session cookie, this can be done by applying the following configuration in web.xml
<session-config>
<cookie-config>
<http-only>true</http-only>
</cookie-config>
<session-config>