The goal of this section is to introduce, discuss, and provide
language specific mitigation techniques for HttpOnly.
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. ,
According to the , 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:
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. ,
According to , 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. ,
Since Sun Java Enterprise Edition 6 (JEE 6), that adopted Java
Servlet 3.0 technology, it‘s programmatically easy setting HttpOnly
flag in a cookie.
In fact <code>setHttpOnly</code> and <code>isHttpOnly</code>
methods are available in the <code>Cookie</code> interface , and also for session cookies (JSESSIONID) :
Moreover since JEE 6 it‘s also declaratively easy setting
<code>HttpOnly</code> flag in session cookie, by applying the
following configuration in the deployment descriptor
<code>WEB-INF/web.xml</code>:
For Java Enterprise Edition versions prior to JEE 6 a
common workaround is to overwrite the
<code>SET-COOKIE</code> http response header with a session cookie
value that explicitly appends the <code>HttpOnly</code> flag:
In this context overwriting, despite appropriate for the
<code>HttpOnly</code> flag, is discouraged because JSESSIONID may
have been set with other flags. So a better workaround is taking
care of the previously set flags or using the
library: in fact the <code>addCookie</code> method of the
<code>SecurityWrapperResponse</code> takes care of previously set falgs for us. So
we could write a servlet filter as the following one:
Some web application servers, that implements JEE 5, and servlet
container that implements Java Servlet 2.5 (part of the JEE 5), also
allow creating HttpOnly session cookies:
Tomcat 6 In <code>context.xml</code> set the
<code>context</code> tag‘s attribute <code>useHttpOnly</code> as follow:
JBoss 5.0.1 and JBOSS EAP
5.0.1 In
<code>\server\<myJBossServerInstance>\deploy\jbossweb.sar\context.xml</code>
set the <code>SessionCookie</code> tag
as follow:
By default, .NET 2.0 sets the
HttpOnly attribute for
Session ID
Forms Authentication cookie
In .NET 2.0, HttpOnly can also be set via the HttpCookie
object for all custom application cookies
Via web.config in the system.web/httpCookies
element
Or programmatically
C# Code:
VB.NET Code:
However, in .NET 1.1, you would have to do
this manually, e.g.,
Python Code (cherryPy):
To use HTTP-Only cookies with Cherrypy
sessions just add the following line in your configuration file:
If you use SLL you can also make your cookies secure (encrypted)
to avoid "man in the middle" cookies reading with:
PHP supports setting the HttpOnly flag since version 5.2.0
(November 2006).
For session cookies managed by PHP, the flag is set either
permanently in php.ini through the
parameter:
or in and during a script via the function:
For application cookies last parameter in setcookie() sets
HttpOnly flag:
If code changes are infeasible, web application firewalls can be
used to add HttpOnly to session cookies:
Mod_security - using SecRule and Header directives
ESAPI WAF using add-http-only-flag
directive
Using WebGoat‘s HttpOnly lesson, the following web browsers have
been tested for HttpOnly support. If the browsers enforces HttpOnly,
a client side script will be unable to read or write the session
cookie. However, there is currently no prevention of reading or
writing the session cookie via a XMLHTTPRequest.
Note: These results may be out of date as this page is not well
maintained. A great site that is focused on keeping up with the
status of browsers is at: . For the most recent
security status of various browsers, including many details beyond
just HttpOnly, go to the browserscope site, and then click on the
Security Tab on the table at the bottom of the page. The
Browserscope site does not provide as much detail on HttpOnly as
this page, but provides lots of other details this page does
not.
Our results as of Feb 2009 are listed below in table
1.
Table 1: Browsers Supporting
HttpOnly
Browser
Version
Prevents
Reads
Writes
Read within XMLHTTPResponse*
Microsoft Internet Explorer
8 Beta 2
Yes
Partially (set-cookie is protected, but not
set-cookie2, see ). Fully patched IE8 passes
7
set-cookie2, see ). Fully patched IE7 passes
6 (SP1)
No
No (Possible that ms08-069 fixed IE 6 too,
please verify with and update
this page!)
6 (fully patched)
Unknown
Mozilla Firefox
3.0.0.6+
Yes (see )
Netscape Navigator
9.0b3
Opera
9.23
9.50
11
Safari
3.0
No (almost yes, see )
5
iPhone (Safari)
iOS 4
Google‘s Chrome
Beta (initial public release)
12
Android
Android 2.3
* An attacker could still read the session cookie in a response
to an .
As of 2011, 99% of browsers and most web application frameworks
do support httpOnly<ref></ref>.
The goal of this section is to provide a step-by-step example of
testing your browser for HttpOnly support.
The OWASP WEBGOAT HttpOnly lab is broken and does not show IE 8
Beta 2 with ms08-069 as complete in terms of HttpOnly XMLHTTPRequest
header leakage protection. This error is being tracked via .
Figure 1 - Accessing
WebGoat‘s HttpOnly Test Lesson
Assuming you have installed and launched WebGoat, begin by
navigating to the ‘HttpOnly Test’ lesson located
within the Cross-Site Scripting (XSS) category.
After loading the ‘HttpOnly Test’ lesson, as shown in figure
1, you are now able to begin testing web browsers
supporting HTTPOnly.
If the HttpOnly flag is set, then your browser should
not allow a client-side script to access the session cookie.
Unfortunately, since the attribute is relatively new, several
browsers may neglect to handle the new attribute properly.
The purpose of this lesson is to test whether
your browser supports the HttpOnly cookie flag.
Note the value of the unique2u
cookie. If your browser supports HTTPOnly, and you
enable it for a cookie, a client-side script should NOT be
able to read OR write to that cookie, but the browser can still send
its value to the server. However, some browsers only prevent client
side read access, but do not prevent write access.
The following test was performed on two browsers,
Internet Explorer 7 and Opera
9.22, to demonstrate the results when the HttpOnly flag is
enforced properly. As you will see, IE7 properly enforces the
HttpOnly flag, whereas Opera does not properly enforce the HttpOnly
flag.
Figure 2 - Disabling
An alert dialog box will display on the screen notifying you
that since HttpOnly was not enabled, the
‘unique2u’ cookie was successfully read as shown
below in figure 3.
Figure 3 - Cookie Successfully Read with
HttpOnly Off
‘unique2u’ cookie was successfully modified on
the client side as shown below in figure 4.
Figure 4 - Cookie Successfully Written
with HttpOnly Off
As you have seen thus far, browsing without
HttpOnly on is a potential
threat. Next, we will enable
HttpOnly to demonstrate how this flag protects the
cookie.
Figure 5 - Enabling
If the browser enforces the HttpOnly flag properly, an alert
dialog box will display only the session ID rather than the
contents of the ‘unique2u’ cookie as shown below
in figure 6.
Figure 6 - Enforced Cookie Read
Protection
However, if the browser does not enforce the HttpOnly flag
properly, an alert dialog box will display both the
‘unique2u’ cookie and session ID as shown below
in figure 7.
Figure 7 - Unenforced Cookie Read
Finally, we will test if the browser allows write
access to the cookie with HttpOnly enabled.
If the browser enforces the HttpOnly flag properly, client
side modification will be unsuccessful in writing to the
‘unique2u’ cookie and an alert dialog box will
display only containing the session ID as shown below in
figure 8.
Figure 8 - Enforced Cookie Write
However, if the browser does not enforce the write protection
property of HttpOnly flag for the ‘unique2u’
cookie, the cookie will be successfully modified to
HACKED on the client side as shown below in
figure 9.
Figure 9 - Unenforced Cookie Write
[1] Wiens, Jordan.
[2]
[3] Howard, Michael.
[4] MSDN.
[5]