Difference between revisions of "HttpOnly"

Revision as of 13:39, 20 August 2007 (view source) Rknell (talk | contribs) (→‎Browsers Supporting HTTPOnly) ← Older edit		Revision as of 14:22, 6 September 2007 (view source) Rknell (talk | contribs) (→‎Browsers Supporting HTTPOnly) Newer edit →
Line 85:		Line 85:
	|-		|-
	| Mozilla Firefox		| Mozilla Firefox
−	| align="center" | 2.0.0.5	+	| align="center" | 2.0.0.6
	| align="center" | Yes		| align="center" | Yes
	| align="center" | Yes		| align="center" | Yes

---

Revision as of 14:22, 6 September 2007

Overview

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>[; <name>=<value>]
[; 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 XSS 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

• Problem
  • Most environments (e.g., Java EE) do not provide a mechanism to set the HTTPOnly flag.

• Solution

response.setHeader("Set-Cookie", 
                   "originalcookiename=originalvalue; 
                   HTTPOnly=");

Note: This works OK for custom cookies, but the JSESSIONID is created and handled by the Java EE container, so you really cannot override the framework to add HTTPOnly to JSESSIONID.

Using .NET to Set HTTPOnly

• By default, .NET 2.0 sets the HTTPOnly attribute for
  1. Session ID
  2. 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

<httpCookies httpOnlyCookies="true" …> 

• Or programmatically

C# Code:

HttpCookie myCookie = new HttpCookie("myCookie");
myCookie.HttpOnly = true;
Response.AppendCookie(myCookie);

VB.NET Code:

Dim myCookie As HttpCookie = new HttpCookie("myCookie")
myCookie.HttpOnly = True
Response.AppendCookie(myCookie)

• However, in .NET 1.1, you would have to do this manually, e.g.,

Response.Cookies[cookie].Path += ";HTTPOnly";

Browsers Supporting HTTPOnly

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. The results are listed below in table 1.

Table 1: Browsers Supporting HTTPOnly

Browser	Version	Prevents Reads	Prevents Writes	Prevents XMLHTTPRequests*
Microsoft Internet Explorer	6 (SP1) - 7	Yes	Yes	No
Mozilla Firefox	2.0.0.6	Yes	Yes	No
Netscape Navigator	9.0b2	No	No	No
Opera	9.22	No	No	No
Safari	3.0	No	No	No

* An attacker could still access the session identifier cookie using a XmlHttpRequest.

Using WebGoat to Test for HTTPOnly Support

The goal of this section is to provide a step-by-step example of testing your browser for HTTPOnly support.

Getting Started

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.

Lesson Goal

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.

Testing Web Browsers for HTTPOnly Support

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.

Disabling HTTPOnly

1) Select the option to turn HTTPOnly off as shown below in figure 2.

2) After turning HTTPOnly off, select the “Read Cookie” button. 

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

3) With HTTPOnly remaining disabled, select the “Write Cookie”  button.

• An alert dialog box will display on the screen notifying you that since HTTPOnly was not enabled, the ‘unique2u’ cookie was successfully modified on the client side as shown below in figure 4.

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

Enabling HTTPOnly

4) Select the radio button to enable HTTPOnly as shown below in figure 5.

5) After enabling HTTPOnly, select the "Read Cookie" button.

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

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

• Finally, we will test if the browser allows write access to the cookie with HTTPOnly enabled.

6) Select the "Write Cookie" button.

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

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

References

[1] Wiens, Jordan. No cookie for you!"

[2] Mitigating Cross-site Scripting with HTTP-Only Cookies

[3] Howard, Michael. Some Bad News and Some Good News