This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
Difference between revisions of "HttpOnly"
m |
(Added references and two headings including text within overview section) |
||
Line 1: | Line 1: | ||
== Overview == | == Overview == | ||
+ | |||
+ | The goal of this section is to introduce and explain the need for HTTPOnly. | ||
+ | |||
+ | <h3 style=color:#4682B4> <u> Who developed HTTPOnly? When? </u> </h3> | ||
+ | |||
+ | According to Jordan Wiens' daily blog article, “No cookie for you!,” in 2002, HTTPOnly cookies were first implemented in Internet Explorer 6 SP1 by Microsoft Internet Explorer developers. [http://www.networkcomputing.com/blog/dailyblog/archives/2007/03/no_cookie_for_y.html Wiens], | ||
+ | [http://www.networkcomputing.com/blog/dailyblog/archives/2007/03/no_cookie_for_y.html] | ||
+ | |||
+ | <h3 style=color:#4682B4> <u> What is HTTPOnly? </u> </h3> | ||
+ | |||
+ | According to the [http://msdn2.microsoft.com/en-us/library/ms533046.aspx Microsoft Developer Network], an HTTPOnly cookie is an additional flag set on the client using a HTTP response header to help mitigate the risk of client side script accessing the session cookie. | ||
+ | |||
+ | *The figure below shows the syntax used within the HTTP response header: | ||
+ | |||
+ | <code> | ||
+ | |||
+ | Set-Cookie: <name>=<value>[; <name>=<value>] | ||
+ | [; expires=<date>][; domain=<domain_name>] | ||
+ | [; path=<some_path>][; secure][; HttpOnly] | ||
+ | |||
+ | </code> | ||
+ | |||
+ | If the HTTPOnly flag (optional) is included in the HTTP response header, the cookie cannot be accessed through client side script, even by the Web site that originally set the cookie. As a result, even if a cross-site scripting flaw exists, and a user accidently accesses a link that exploits this flaw, Internet Explorer will not send the cookie to a third party. | ||
+ | |||
+ | If a browser does not support HTTPOnly and a web site attempts to set an HTTPOnly-cookie, the cookie is either ignored or demoted to a traditional, scriptable cookie. Unfortunately, this makes your session cookie vulnerable. [http://msdn2.microsoft.com/en-us/library/ms533046.aspx Microsoft], [http://msdn2.microsoft.com/en-us/library/ms533046.aspx] | ||
== Browsers Supporting HTTPOnly == | == Browsers Supporting HTTPOnly == | ||
Line 95: | Line 120: | ||
[[Image:Fig9-No_Cookie_Write_Protection.PNG|frame|center|Figure 9 - Unenforced Cookie Write Protection]] | [[Image:Fig9-No_Cookie_Write_Protection.PNG|frame|center|Figure 9 - Unenforced Cookie Write Protection]] | ||
+ | |||
+ | == References == | ||
+ | |||
+ | [1] Wiens, Jordan. [http://www.networkcomputing.com/blog/dailyblog/archives/2007/03/no_cookie_for_y.html No cookie for you!"] |
Revision as of 15:31, 27 July 2007
Overview
The goal of this section is to introduce and explain the need for HTTPOnly.
Who developed HTTPOnly? When?
According to Jordan Wiens' daily blog article, “No cookie for you!,” in 2002, HTTPOnly cookies were first implemented in Internet Explorer 6 SP1 by Microsoft Internet Explorer developers. Wiens, [1]
What is HTTPOnly?
According to the Microsoft Developer Network, an HTTPOnly cookie is an additional flag set on the client using a HTTP response header to help mitigate the risk of client side script accessing the session cookie.
- The figure 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, even by the Web site that originally set the cookie. As a result, even if a cross-site scripting flaw exists, and a user accidently accesses a link that exploits this flaw, Internet Explorer will not send the cookie to a third party.
If a browser does not support HTTPOnly and a web site attempts to set an HTTPOnly-cookie, the cookie is either ignored or demoted to a traditional, scriptable cookie. Unfortunately, this makes your session cookie vulnerable. Microsoft, [2]
Browsers Supporting HTTPOnly
Using WebGoat's HTTPOnly lesson, the following web browsers have been tested for HTTPOnly capabilities. The results are listed below in table 1.
Browser | Version | Supports HTTPOnly? |
---|---|---|
Microsoft Internet Explorer | 6 (SP1) - 7 | Partially* |
Mozilla Firefox | 2.0.0.5 | Partially* |
Netscape Navigator | 9.0b2 | No |
Opera | 9.22 | No |
* An attacker could still access the session identifier cookie using a XmlHttpRequest.
Using WebGoat to Test for HTTPOnly Capabilities
Getting Started
Assuming you have already installed and launched WebGoat, begin by navigating to the ‘HTTPOnly Test’ lesson located within the Cross-Site Scripting (XSS) category. After selecting the ‘HTTPOnly Test’ link, as shown in figure 1, you are now able to begin testing web browsers that support HTTPOnly.
Lesson Goal
If the HTTPOnly flag is set, then your browser should not allow client-side script to access the cookie. Unfortunately, since the attribute is relatively new, several browsers 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, client side code 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!"