OWASP - User contributions [en]

HttpOnly

2007-09-06T14:38:18Z

Rknell: /* Browsers Supporting HTTPOnly */

== Overview ==

The goal of this section is to introduce, discuss, and provide language specific mitigation techniques for HTTPOnly.

<h3 style=color:#4682B4> <u> Who developed HTTPOnly? When? </u> </h3>

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. [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], 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. [http://msdn2.microsoft.com/en-us/library/ms533046.aspx Mitigating], [http://msdn2.microsoft.com/en-us/library/ms533046.aspx]

<h3 style=color:#4682B4> <u> Mitigating XSS using HTTPOnly </u> </h3>

According to [http://msdn2.microsoft.com/en-us/library/ms972826.aspx 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. [http://msdn2.microsoft.com/en-us/library/ms972826.aspx Howard], [http://msdn2.microsoft.com/en-us/library/ms972826.aspx]

<h5 style=color:#2E8B57> <u> Using Java to Set HTTPOnly </u> </h5>

*'''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.

<h5 style=color:#2E8B57> <u> Using .NET to Set HTTPOnly </u> </h5>

*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
<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'''.

{|border="2" width="100%" align="center"
|+ '''Table 1:''' Browsers Supporting HTTPOnly
|-
! style="background:black; color:white" | '''Browser'''
! style="background:black; color:white" | '''Version'''
! style="background:black; color:white" | '''Prevents Reads'''
! style="background:black; color:white" | '''Prevents Writes'''
! style="background:black; color:white" | '''Prevents XMLHTTPRequests*'''
|-
| Microsoft Internet Explorer
| align="center" | 6 (SP1) - 7
| align="center" | Yes
| align="center" | Yes
| align="center" | No
|-
| Mozilla Firefox
| align="center" | 2.0.0.6
| align="center" | Yes
| align="center" | Yes
| align="center" | No
|-
| Netscape Navigator
| align="center" | 9.0b3
| align="center" | Yes
| align="center" | Yes
| align="center" | No
|-
| Opera
| align="center" | 9.23
| align="center" | No
| align="center" | No
| align="center" | No
|-
| Safari
| align="center" | 3.0
| align="center" | No
| align="center" | No
| align="center" | No
|}

<nowiki>*</nowiki> An attacker could still access the session identifier cookie using a '''[http://ha.ckers.org/blog/20070719/firefox-implements-httponly-and-is-vulnerable-to-xmlhttprequest/ 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.

<h3 style=color:#4682B4> <u> Getting Started </u> </h3>

[[Image:Click_link.JPG|thumb|175px|right|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.

<h3 style=color:#4682B4> <u> Lesson Goal </u> </h3>

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.

<h3 style=color:#4682B4> <u> Testing Web Browsers for HTTPOnly Support </u> </h3>

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.

<h5 style=color:#2E8B57> <u> Disabling HTTPOnly </u> </h5>

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

[[Image:Fig2-Disabling_HTTPOnly.PNG|frame|center|Figure 2 - Disabling HTTPOnly]]

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

[[Image:Fig3-Read_HTTPOnly_Off.PNG|frame|center|Figure 3 - Cookie Successfully Read with HTTPOnly Off]]

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

[[Image:Fig4-Write_HTTPOnly_Off.PNG|frame|center|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.

<h5 style=color:#2E8B57> <u> Enabling HTTPOnly </u> </h5>

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

[[Image:Fig5-Turning_HTTPOnly_On.PNG|frame|center|Figure 5 - Enabling HTTPOnly]]

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

[[Image:Fig6-Cookie_Read_Protection.PNG|frame|center|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'''.

[[Image:Fig7-No_Cookie_Read_Protection.PNG|frame|center|Figure 7 - Unenforced Cookie Read Protection]]

*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'''.

[[Image:Fig6-Cookie_Read_Protection.PNG|frame|center|Figure 8 - Enforced Cookie Write Protection]]

*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'''.

[[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!"]

[2] [http://msdn2.microsoft.com/en-us/library/ms533046.aspx Mitigating Cross-site Scripting with HTTP-Only Cookies]

[3] Howard, Michael. [http://msdn2.microsoft.com/en-us/library/ms972826.aspx Some Bad News and Some Good News]

HttpOnly

2007-09-06T14:37:52Z

Rknell: /* Browsers Supporting HTTPOnly */

== Overview ==

The goal of this section is to introduce, discuss, and provide language specific mitigation techniques for HTTPOnly.

<h3 style=color:#4682B4> <u> Who developed HTTPOnly? When? </u> </h3>

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. [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], 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. [http://msdn2.microsoft.com/en-us/library/ms533046.aspx Mitigating], [http://msdn2.microsoft.com/en-us/library/ms533046.aspx]

<h3 style=color:#4682B4> <u> Mitigating XSS using HTTPOnly </u> </h3>

According to [http://msdn2.microsoft.com/en-us/library/ms972826.aspx 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. [http://msdn2.microsoft.com/en-us/library/ms972826.aspx Howard], [http://msdn2.microsoft.com/en-us/library/ms972826.aspx]

<h5 style=color:#2E8B57> <u> Using Java to Set HTTPOnly </u> </h5>

*'''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.

<h5 style=color:#2E8B57> <u> Using .NET to Set HTTPOnly </u> </h5>

*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
<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'''.

{|border="2" width="100%" align="center"
|+ '''Table 1:''' Browsers Supporting HTTPOnly
|-
! style="background:black; color:white" | '''Browser'''
! style="background:black; color:white" | '''Version'''
! style="background:black; color:white" | '''Prevents Reads'''
! style="background:black; color:white" | '''Prevents Writes'''
! style="background:black; color:white" | '''Prevents XMLHTTPRequests*'''
|-
| Microsoft Internet Explorer
| align="center" | 6 (SP1) - 7
| align="center" | Yes
| align="center" | Yes
| align="center" | No
|-
| Mozilla Firefox
| align="center" | 2.0.0.6
| align="center" | Yes
| align="center" | Yes
| align="center" | No
|-
| Netscape Navigator
| align="center" | 9.0b3
| align="center" | Yes
| align="center" | Yes
| align="center" | No
|-
| Opera
| align="center" | 9.22
| align="center" | No
| align="center" | No
| align="center" | No
|-
| Safari
| align="center" | 3.0
| align="center" | No
| align="center" | No
| align="center" | No
|}

<nowiki>*</nowiki> An attacker could still access the session identifier cookie using a '''[http://ha.ckers.org/blog/20070719/firefox-implements-httponly-and-is-vulnerable-to-xmlhttprequest/ 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.

<h3 style=color:#4682B4> <u> Getting Started </u> </h3>

[[Image:Click_link.JPG|thumb|175px|right|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.

<h3 style=color:#4682B4> <u> Lesson Goal </u> </h3>

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.

<h3 style=color:#4682B4> <u> Testing Web Browsers for HTTPOnly Support </u> </h3>

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.

<h5 style=color:#2E8B57> <u> Disabling HTTPOnly </u> </h5>

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

[[Image:Fig2-Disabling_HTTPOnly.PNG|frame|center|Figure 2 - Disabling HTTPOnly]]

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

[[Image:Fig3-Read_HTTPOnly_Off.PNG|frame|center|Figure 3 - Cookie Successfully Read with HTTPOnly Off]]

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

[[Image:Fig4-Write_HTTPOnly_Off.PNG|frame|center|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.

<h5 style=color:#2E8B57> <u> Enabling HTTPOnly </u> </h5>

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

[[Image:Fig5-Turning_HTTPOnly_On.PNG|frame|center|Figure 5 - Enabling HTTPOnly]]

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

[[Image:Fig6-Cookie_Read_Protection.PNG|frame|center|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'''.

[[Image:Fig7-No_Cookie_Read_Protection.PNG|frame|center|Figure 7 - Unenforced Cookie Read Protection]]

*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'''.

[[Image:Fig6-Cookie_Read_Protection.PNG|frame|center|Figure 8 - Enforced Cookie Write Protection]]

*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'''.

[[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!"]

[2] [http://msdn2.microsoft.com/en-us/library/ms533046.aspx Mitigating Cross-site Scripting with HTTP-Only Cookies]

[3] Howard, Michael. [http://msdn2.microsoft.com/en-us/library/ms972826.aspx Some Bad News and Some Good News]

HttpOnly

2007-09-06T14:35:29Z

Rknell: /* Browsers Supporting HTTPOnly */

== Overview ==

The goal of this section is to introduce, discuss, and provide language specific mitigation techniques for HTTPOnly.

<h3 style=color:#4682B4> <u> Who developed HTTPOnly? When? </u> </h3>

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. [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], 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. [http://msdn2.microsoft.com/en-us/library/ms533046.aspx Mitigating], [http://msdn2.microsoft.com/en-us/library/ms533046.aspx]

<h3 style=color:#4682B4> <u> Mitigating XSS using HTTPOnly </u> </h3>

According to [http://msdn2.microsoft.com/en-us/library/ms972826.aspx 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. [http://msdn2.microsoft.com/en-us/library/ms972826.aspx Howard], [http://msdn2.microsoft.com/en-us/library/ms972826.aspx]

<h5 style=color:#2E8B57> <u> Using Java to Set HTTPOnly </u> </h5>

*'''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.

<h5 style=color:#2E8B57> <u> Using .NET to Set HTTPOnly </u> </h5>

*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
<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'''.

{|border="2" width="100%" align="center"
|+ '''Table 1:''' Browsers Supporting HTTPOnly
|-
! style="background:black; color:white" | '''Browser'''
! style="background:black; color:white" | '''Version'''
! style="background:black; color:white" | '''Prevents Reads'''
! style="background:black; color:white" | '''Prevents Writes'''
! style="background:black; color:white" | '''Prevents XMLHTTPRequests*'''
|-
| Microsoft Internet Explorer
| align="center" | 6 (SP1) - 7
| align="center" | Yes
| align="center" | Yes
| align="center" | No
|-
| Mozilla Firefox
| align="center" | 2.0.0.6
| align="center" | Yes
| align="center" | Yes
| align="center" | No
|-
| Netscape Navigator
| align="center" | 9.0b3
| align="center" | No
| align="center" | No
| align="center" | No
|-
| Opera
| align="center" | 9.22
| align="center" | No
| align="center" | No
| align="center" | No
|-
| Safari
| align="center" | 3.0
| align="center" | No
| align="center" | No
| align="center" | No
|}

<nowiki>*</nowiki> An attacker could still access the session identifier cookie using a '''[http://ha.ckers.org/blog/20070719/firefox-implements-httponly-and-is-vulnerable-to-xmlhttprequest/ 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.

<h3 style=color:#4682B4> <u> Getting Started </u> </h3>

[[Image:Click_link.JPG|thumb|175px|right|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.

<h3 style=color:#4682B4> <u> Lesson Goal </u> </h3>

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.

<h3 style=color:#4682B4> <u> Testing Web Browsers for HTTPOnly Support </u> </h3>

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.

<h5 style=color:#2E8B57> <u> Disabling HTTPOnly </u> </h5>

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

[[Image:Fig2-Disabling_HTTPOnly.PNG|frame|center|Figure 2 - Disabling HTTPOnly]]

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

[[Image:Fig3-Read_HTTPOnly_Off.PNG|frame|center|Figure 3 - Cookie Successfully Read with HTTPOnly Off]]

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

[[Image:Fig4-Write_HTTPOnly_Off.PNG|frame|center|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.

<h5 style=color:#2E8B57> <u> Enabling HTTPOnly </u> </h5>

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

[[Image:Fig5-Turning_HTTPOnly_On.PNG|frame|center|Figure 5 - Enabling HTTPOnly]]

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

[[Image:Fig6-Cookie_Read_Protection.PNG|frame|center|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'''.

[[Image:Fig7-No_Cookie_Read_Protection.PNG|frame|center|Figure 7 - Unenforced Cookie Read Protection]]

*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'''.

[[Image:Fig6-Cookie_Read_Protection.PNG|frame|center|Figure 8 - Enforced Cookie Write Protection]]

*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'''.

[[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!"]

[2] [http://msdn2.microsoft.com/en-us/library/ms533046.aspx Mitigating Cross-site Scripting with HTTP-Only Cookies]

[3] Howard, Michael. [http://msdn2.microsoft.com/en-us/library/ms972826.aspx Some Bad News and Some Good News]

HttpOnly

2007-09-06T14:22:48Z

Rknell: /* Browsers Supporting HTTPOnly */

== Overview ==

The goal of this section is to introduce, discuss, and provide language specific mitigation techniques for HTTPOnly.

<h3 style=color:#4682B4> <u> Who developed HTTPOnly? When? </u> </h3>

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. [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], 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. [http://msdn2.microsoft.com/en-us/library/ms533046.aspx Mitigating], [http://msdn2.microsoft.com/en-us/library/ms533046.aspx]

<h3 style=color:#4682B4> <u> Mitigating XSS using HTTPOnly </u> </h3>

According to [http://msdn2.microsoft.com/en-us/library/ms972826.aspx 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. [http://msdn2.microsoft.com/en-us/library/ms972826.aspx Howard], [http://msdn2.microsoft.com/en-us/library/ms972826.aspx]

<h5 style=color:#2E8B57> <u> Using Java to Set HTTPOnly </u> </h5>

*'''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.

<h5 style=color:#2E8B57> <u> Using .NET to Set HTTPOnly </u> </h5>

*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
<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'''.

{|border="2" width="100%" align="center"
|+ '''Table 1:''' Browsers Supporting HTTPOnly
|-
! style="background:black; color:white" | '''Browser'''
! style="background:black; color:white" | '''Version'''
! style="background:black; color:white" | '''Prevents Reads'''
! style="background:black; color:white" | '''Prevents Writes'''
! style="background:black; color:white" | '''Prevents XMLHTTPRequests*'''
|-
| Microsoft Internet Explorer
| align="center" | 6 (SP1) - 7
| align="center" | Yes
| align="center" | Yes
| align="center" | No
|-
| Mozilla Firefox
| align="center" | 2.0.0.6
| align="center" | Yes
| align="center" | Yes
| align="center" | No
|-
| Netscape Navigator
| align="center" | 9.0b2
| align="center" | No
| align="center" | No
| align="center" | No
|-
| Opera
| align="center" | 9.22
| align="center" | No
| align="center" | No
| align="center" | No
|-
| Safari
| align="center" | 3.0
| align="center" | No
| align="center" | No
| align="center" | No
|}

<nowiki>*</nowiki> An attacker could still access the session identifier cookie using a '''[http://ha.ckers.org/blog/20070719/firefox-implements-httponly-and-is-vulnerable-to-xmlhttprequest/ 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.

<h3 style=color:#4682B4> <u> Getting Started </u> </h3>

[[Image:Click_link.JPG|thumb|175px|right|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.

<h3 style=color:#4682B4> <u> Lesson Goal </u> </h3>

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.

<h3 style=color:#4682B4> <u> Testing Web Browsers for HTTPOnly Support </u> </h3>

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.

<h5 style=color:#2E8B57> <u> Disabling HTTPOnly </u> </h5>

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

[[Image:Fig2-Disabling_HTTPOnly.PNG|frame|center|Figure 2 - Disabling HTTPOnly]]

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

[[Image:Fig3-Read_HTTPOnly_Off.PNG|frame|center|Figure 3 - Cookie Successfully Read with HTTPOnly Off]]

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

[[Image:Fig4-Write_HTTPOnly_Off.PNG|frame|center|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.

<h5 style=color:#2E8B57> <u> Enabling HTTPOnly </u> </h5>

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

[[Image:Fig5-Turning_HTTPOnly_On.PNG|frame|center|Figure 5 - Enabling HTTPOnly]]

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

[[Image:Fig6-Cookie_Read_Protection.PNG|frame|center|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'''.

[[Image:Fig7-No_Cookie_Read_Protection.PNG|frame|center|Figure 7 - Unenforced Cookie Read Protection]]

*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'''.

[[Image:Fig6-Cookie_Read_Protection.PNG|frame|center|Figure 8 - Enforced Cookie Write Protection]]

*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'''.

[[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!"]

[2] [http://msdn2.microsoft.com/en-us/library/ms533046.aspx Mitigating Cross-site Scripting with HTTP-Only Cookies]

[3] Howard, Michael. [http://msdn2.microsoft.com/en-us/library/ms972826.aspx Some Bad News and Some Good News]

HttpOnly

2007-08-20T13:39:29Z

Rknell: /* Browsers Supporting HTTPOnly */

== Overview ==

The goal of this section is to introduce, discuss, and provide language specific mitigation techniques for HTTPOnly.

<h3 style=color:#4682B4> <u> Who developed HTTPOnly? When? </u> </h3>

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. [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], 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. [http://msdn2.microsoft.com/en-us/library/ms533046.aspx Mitigating], [http://msdn2.microsoft.com/en-us/library/ms533046.aspx]

<h3 style=color:#4682B4> <u> Mitigating XSS using HTTPOnly </u> </h3>

According to [http://msdn2.microsoft.com/en-us/library/ms972826.aspx 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. [http://msdn2.microsoft.com/en-us/library/ms972826.aspx Howard], [http://msdn2.microsoft.com/en-us/library/ms972826.aspx]

<h5 style=color:#2E8B57> <u> Using Java to Set HTTPOnly </u> </h5>

*'''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.

<h5 style=color:#2E8B57> <u> Using .NET to Set HTTPOnly </u> </h5>

*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
<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'''.

{|border="2" width="100%" align="center"
|+ '''Table 1:''' Browsers Supporting HTTPOnly
|-
! style="background:black; color:white" | '''Browser'''
! style="background:black; color:white" | '''Version'''
! style="background:black; color:white" | '''Prevents Reads'''
! style="background:black; color:white" | '''Prevents Writes'''
! style="background:black; color:white" | '''Prevents XMLHTTPRequests*'''
|-
| Microsoft Internet Explorer
| align="center" | 6 (SP1) - 7
| align="center" | Yes
| align="center" | Yes
| align="center" | No
|-
| Mozilla Firefox
| align="center" | 2.0.0.5
| align="center" | Yes
| align="center" | Yes
| align="center" | No
|-
| Netscape Navigator
| align="center" | 9.0b2
| align="center" | No
| align="center" | No
| align="center" | No
|-
| Opera
| align="center" | 9.22
| align="center" | No
| align="center" | No
| align="center" | No
|-
| Safari
| align="center" | 3.0
| align="center" | No
| align="center" | No
| align="center" | No
|}

<nowiki>*</nowiki> An attacker could still access the session identifier cookie using a '''[http://ha.ckers.org/blog/20070719/firefox-implements-httponly-and-is-vulnerable-to-xmlhttprequest/ 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.

<h3 style=color:#4682B4> <u> Getting Started </u> </h3>

[[Image:Click_link.JPG|thumb|175px|right|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.

<h3 style=color:#4682B4> <u> Lesson Goal </u> </h3>

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.

<h3 style=color:#4682B4> <u> Testing Web Browsers for HTTPOnly Support </u> </h3>

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.

<h5 style=color:#2E8B57> <u> Disabling HTTPOnly </u> </h5>

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

[[Image:Fig2-Disabling_HTTPOnly.PNG|frame|center|Figure 2 - Disabling HTTPOnly]]

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

[[Image:Fig3-Read_HTTPOnly_Off.PNG|frame|center|Figure 3 - Cookie Successfully Read with HTTPOnly Off]]

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

[[Image:Fig4-Write_HTTPOnly_Off.PNG|frame|center|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.

<h5 style=color:#2E8B57> <u> Enabling HTTPOnly </u> </h5>

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

[[Image:Fig5-Turning_HTTPOnly_On.PNG|frame|center|Figure 5 - Enabling HTTPOnly]]

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

[[Image:Fig6-Cookie_Read_Protection.PNG|frame|center|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'''.

[[Image:Fig7-No_Cookie_Read_Protection.PNG|frame|center|Figure 7 - Unenforced Cookie Read Protection]]

*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'''.

[[Image:Fig6-Cookie_Read_Protection.PNG|frame|center|Figure 8 - Enforced Cookie Write Protection]]

*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'''.

[[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!"]

[2] [http://msdn2.microsoft.com/en-us/library/ms533046.aspx Mitigating Cross-site Scripting with HTTP-Only Cookies]

[3] Howard, Michael. [http://msdn2.microsoft.com/en-us/library/ms972826.aspx Some Bad News and Some Good News]

HttpOnly

2007-08-10T20:24:26Z

Rknell:

== Overview ==

The goal of this section is to introduce, discuss, and provide language specific mitigation techniques for HTTPOnly.

<h3 style=color:#4682B4> <u> Who developed HTTPOnly? When? </u> </h3>

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. [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. Using the HTTPOnly flag helps mitigate the risk of client side script accessing the session cookie.

*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 or the web site that originally set the cookie. As a result, even if a cross-site scripting '''(XSS)''' flaw exists, and a user accidentally accesses a link that exploits this flaw, 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 cookie will be either ignored or demoted to a traditional, scriptable cookie. As a result, your session cookie becomes vulnerable. [http://msdn2.microsoft.com/en-us/library/ms533046.aspx Mitigating], [http://msdn2.microsoft.com/en-us/library/ms533046.aspx]

<h3 style=color:#4682B4> <u> Mitigating XSS using HTTPOnly </u> </h3>

According to [http://msdn2.microsoft.com/en-us/library/ms972826.aspx Michael Howard], Senior Security Program Manager in the Secure Windows Initiative group at Microsoft, the majority of XSS attacks succeed because a session cookie has been leaked. A server could help mitigate this issue by setting a flag within a ''HTTP response header,'' indicating a session cookie should never be accessed by the client.

If Internet Explorer detects a cookie containing the HTTPOnly flag, and client side script code attempts to read the cookie, Internet Explorer ''returns an empty string''. As a result, the attack fails by preventing the malicious XSS code from sending the data to an attacker's website. [http://msdn2.microsoft.com/en-us/library/ms972826.aspx Howard], [http://msdn2.microsoft.com/en-us/library/ms972826.aspx]

<h5 style=color:#2E8B57> <u> Using Java to Set HTTPOnly </u> </h5>

*'''Problem'''
**Most environments (e.g., Java EE) do not provide 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.

<h5 style=color:#2E8B57> <u> Using C#.NET to Set HTTPOnly </u> </h5>

*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
<httpCookies httpOnlyCookies="true" …>

*Or '''programmatically'''
HttpCookie myCookie = 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";

<h5 style=color:#2E8B57> <u> Using VB.NET to Set HTTPOnly </u> </h5>

*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
<httpCookies httpOnlyCookies="true" …>

*Or '''programmatically'''
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 capabilities. The results are listed below in '''table 1'''.

{|border="2" width="100%" align="center"
|+ '''Table 1:''' Browsers Supporting HTTPOnly
|-
! style="background:black; color:white" | '''Browser'''
! style="background:black; color:white" | '''Version'''
! style="background:black; color:white" | '''Supports HTTPOnly?'''
|-
| Microsoft Internet Explorer
| align="center" | 6 (SP1) - 7
| align="center" | Partially*
|-
| Mozilla Firefox
| align="center" | 2.0.0.5
| align="center" | Partially*
|-
| Netscape Navigator
| align="center" | 9.0b2
| align="center" | No
|-
| Opera
| align="center" | 9.22
| align="center" | No
|-
| Safari
| align="center" | 3.0
| align="center" | No
|}

<nowiki>*</nowiki> An attacker could still access the session identifier cookie using a '''[http://ha.ckers.org/blog/20070719/firefox-implements-httponly-and-is-vulnerable-to-xmlhttprequest/ 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.

<h3 style=color:#4682B4> <u> Getting Started </u> </h3>

[[Image:Click_link.JPG|thumb|175px|right|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.

<h3 style=color:#4682B4> <u> Lesson Goal </u> </h3>

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.

<h3 style=color:#4682B4> <u> Testing Web Browsers for HTTPOnly Support </u> </h3>

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.

<h5 style=color:#2E8B57> <u> Disabling HTTPOnly </u> </h5>

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

[[Image:Fig2-Disabling_HTTPOnly.PNG|frame|center|Figure 2 - Disabling HTTPOnly]]

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

[[Image:Fig3-Read_HTTPOnly_Off.PNG|frame|center|Figure 3 - Cookie Successfully Read with HTTPOnly Off]]

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

[[Image:Fig4-Write_HTTPOnly_Off.PNG|frame|center|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.

<h5 style=color:#2E8B57> <u> Enabling HTTPOnly </u> </h5>

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

[[Image:Fig5-Turning_HTTPOnly_On.PNG|frame|center|Figure 5 - Enabling HTTPOnly]]

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

[[Image:Fig6-Cookie_Read_Protection.PNG|frame|center|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'''.

[[Image:Fig7-No_Cookie_Read_Protection.PNG|frame|center|Figure 7 - Unenforced Cookie Read Protection]]

*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'''.

[[Image:Fig6-Cookie_Read_Protection.PNG|frame|center|Figure 8 - Enforced Cookie Write Protection]]

*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'''.

[[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!"]

[2] [http://msdn2.microsoft.com/en-us/library/ms533046.aspx Mitigating Cross-site Scripting with HTTP-Only Cookies]

[3] Howard, Michael. [http://msdn2.microsoft.com/en-us/library/ms972826.aspx Some Bad News and Some Good News]

HttpOnly

2007-08-10T20:21:04Z

Rknell:

== Overview ==

The goal of this section is to introduce, discuss, and provide language specific mitigation techniques for HTTPOnly.

<h3 style=color:#4682B4> <u> Who developed HTTPOnly? When? </u> </h3>

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. [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. Using the HTTPOnly flag helps mitigate the risk of client side script accessing the session cookie.

*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 or the web site that originally set the cookie. As a result, even if a cross-site scripting '''(XSS)''' flaw exists, and a user accidentally accesses a link that exploits this flaw, 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 cookie will be either ignored or demoted to a traditional, scriptable cookie. As a result, your session cookie becomes vulnerable. [http://msdn2.microsoft.com/en-us/library/ms533046.aspx Mitigating], [http://msdn2.microsoft.com/en-us/library/ms533046.aspx]

<h3 style=color:#4682B4> <u> Mitigating XSS using HTTPOnly </u> </h3>

According to [http://msdn2.microsoft.com/en-us/library/ms972826.aspx Michael Howard], Senior Security Program Manager in the Secure Windows Initiative group at Microsoft, the majority of XSS attacks succeed because a session cookie has been leaked. A server could help mitigate this issue by setting a flag within a ''HTTP response header,'' indicating a session cookie should never be accessed by the client.

If Internet Explorer detects a cookie containing the HttpOnly flag, and client side script code attempts to read the cookie, Internet Explorer ''returns an empty string''. As a result, the attack fails by preventing the malicious XSS code from sending the data to an attacker's website. [http://msdn2.microsoft.com/en-us/library/ms972826.aspx Howard], [http://msdn2.microsoft.com/en-us/library/ms972826.aspx]

<h5 style=color:#2E8B57> <u> Using Java to Set HTTPOnly </u> </h5>

*'''Problem'''
**Most environments (e.g., Java EE) do not provide 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.

<h5 style=color:#2E8B57> <u> Using C#.NET to Set HTTPOnly </u> </h5>

*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
<httpCookies httpOnlyCookies="true" …>

*Or '''programmatically'''
HttpCookie myCookie = 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";

<h5 style=color:#2E8B57> <u> Using VB.NET to Set HTTPOnly </u> </h5>

*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
<httpCookies httpOnlyCookies="true" …>

*Or '''programmatically'''
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 capabilities. The results are listed below in '''table 1'''.

{|border="2" width="100%" align="center"
|+ '''Table 1:''' Browsers Supporting HTTPOnly
|-
! style="background:black; color:white" | '''Browser'''
! style="background:black; color:white" | '''Version'''
! style="background:black; color:white" | '''Supports HTTPOnly?'''
|-
| Microsoft Internet Explorer
| align="center" | 6 (SP1) - 7
| align="center" | Partially*
|-
| Mozilla Firefox
| align="center" | 2.0.0.5
| align="center" | Partially*
|-
| Netscape Navigator
| align="center" | 9.0b2
| align="center" | No
|-
| Opera
| align="center" | 9.22
| align="center" | No
|-
| Safari
| align="center" | 3.0
| align="center" | No
|}

<nowiki>*</nowiki> An attacker could still access the session identifier cookie using a '''[http://ha.ckers.org/blog/20070719/firefox-implements-httponly-and-is-vulnerable-to-xmlhttprequest/ 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.

<h3 style=color:#4682B4> <u> Getting Started </u> </h3>

[[Image:Click_link.JPG|thumb|175px|right|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.

<h3 style=color:#4682B4> <u> Lesson Goal </u> </h3>

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.

<h3 style=color:#4682B4> <u> Testing Web Browsers for HTTPOnly Support </u> </h3>

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.

<h5 style=color:#2E8B57> <u> Disabling HTTPOnly </u> </h5>

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

[[Image:Fig2-Disabling_HTTPOnly.PNG|frame|center|Figure 2 - Disabling HTTPOnly]]

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

[[Image:Fig3-Read_HTTPOnly_Off.PNG|frame|center|Figure 3 - Cookie Successfully Read with HTTPOnly Off]]

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

[[Image:Fig4-Write_HTTPOnly_Off.PNG|frame|center|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.

<h5 style=color:#2E8B57> <u> Enabling HTTPOnly </u> </h5>

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

[[Image:Fig5-Turning_HTTPOnly_On.PNG|frame|center|Figure 5 - Enabling HTTPOnly]]

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

[[Image:Fig6-Cookie_Read_Protection.PNG|frame|center|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'''.

[[Image:Fig7-No_Cookie_Read_Protection.PNG|frame|center|Figure 7 - Unenforced Cookie Read Protection]]

*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'''.

[[Image:Fig6-Cookie_Read_Protection.PNG|frame|center|Figure 8 - Enforced Cookie Write Protection]]

*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'''.

[[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!"]

[2] [http://msdn2.microsoft.com/en-us/library/ms533046.aspx Mitigating Cross-site Scripting with HTTP-Only Cookies]

[3] Howard, Michael. [http://msdn2.microsoft.com/en-us/library/ms972826.aspx Some Bad News and Some Good News]

HttpOnly

2007-08-02T13:32:00Z

Rknell:

== Overview ==

The goal of this section is to introduce, discuss, and provide language specific mitigation techniques for HTTPOnly.

<h3 style=color:#4682B4> <u> Who developed HTTPOnly? When? </u> </h3>

According to a daily blog article in 2002 by Jordan Wiens, “No cookie for you!,” 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. Using the HTTPOnly flag helps mitigate the risk of client side script accessing the session cookie.

*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 or the web site that originally set the cookie. As a result, even if a cross-site scripting '''(XSS)''' flaw exists, and a user accidentally accesses a link that exploits this flaw, 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 cookie will be either ignored or demoted to a traditional, scriptable cookie. As a result, your session cookie becomes vulnerable. [http://msdn2.microsoft.com/en-us/library/ms533046.aspx Mitigating], [http://msdn2.microsoft.com/en-us/library/ms533046.aspx]

<h3 style=color:#4682B4> <u> Mitigating XSS using HTTPOnly </u> </h3>

According to [http://msdn2.microsoft.com/en-us/library/ms972826.aspx Michael Howard], Senior Security Program Manager in the Secure Windows Initiative group at Microsoft, the majority of XSS attacks succeed because a session cookie has been leaked. A server could help mitigate this issue by setting a flag within a ''HTTP response header,'' indicating a session cookie should never be accessed by the client.

If Internet Explorer detects a cookie containing the HttpOnly flag, and client side script code attempts to read the cookie, Internet Explorer ''returns an empty string''. As a result, the attack fails by preventing the malicious XSS code from sending the data to an attacker's website. [http://msdn2.microsoft.com/en-us/library/ms972826.aspx Howard], [http://msdn2.microsoft.com/en-us/library/ms972826.aspx]

<h5 style=color:#2E8B57> <u> Using Java to Set HTTPOnly </u> </h5>

*'''Problem'''
**Most environments (e.g., Java EE) do not provide 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.

<h5 style=color:#2E8B57> <u> Using C#.NET to Set HTTPOnly </u> </h5>

*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
<httpCookies httpOnlyCookies="true" …>

*Or '''programmatically'''
HttpCookie myCookie = 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";

<h5 style=color:#2E8B57> <u> Using VB.NET to Set HTTPOnly </u> </h5>

*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
<httpCookies httpOnlyCookies="true" …>

*Or '''programmatically'''
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 capabilities. The results are listed below in '''table 1'''.

{|border="2" width="100%" align="center"
|+ '''Table 1:''' Browsers Supporting HTTPOnly
|-
! style="background:black; color:white" | '''Browser'''
! style="background:black; color:white" | '''Version'''
! style="background:black; color:white" | '''Supports HTTPOnly?'''
|-
| Microsoft Internet Explorer
| align="center" | 6 (SP1) - 7
| align="center" | Partially*
|-
| Mozilla Firefox
| align="center" | 2.0.0.5
| align="center" | Partially*
|-
| Netscape Navigator
| align="center" | 9.0b2
| align="center" | No
|-
| Opera
| align="center" | 9.22
| align="center" | No
|-
| Safari
| align="center" | 3.0
| align="center" | No
|}

<nowiki>*</nowiki> An attacker could still access the session identifier cookie using a '''[http://ha.ckers.org/blog/20070719/firefox-implements-httponly-and-is-vulnerable-to-xmlhttprequest/ 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.

<h3 style=color:#4682B4> <u> Getting Started </u> </h3>

[[Image:Click_link.JPG|thumb|175px|right|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.

<h3 style=color:#4682B4> <u> Lesson Goal </u> </h3>

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.

<h3 style=color:#4682B4> <u> Testing Web Browsers for HTTPOnly Support </u> </h3>

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.

<h5 style=color:#2E8B57> <u> Disabling HTTPOnly </u> </h5>

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

[[Image:Fig2-Disabling_HTTPOnly.PNG|frame|center|Figure 2 - Disabling HTTPOnly]]

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

[[Image:Fig3-Read_HTTPOnly_Off.PNG|frame|center|Figure 3 - Cookie Successfully Read with HTTPOnly Off]]

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

[[Image:Fig4-Write_HTTPOnly_Off.PNG|frame|center|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.

<h5 style=color:#2E8B57> <u> Enabling HTTPOnly </u> </h5>

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

[[Image:Fig5-Turning_HTTPOnly_On.PNG|frame|center|Figure 5 - Enabling HTTPOnly]]

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

[[Image:Fig6-Cookie_Read_Protection.PNG|frame|center|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'''.

[[Image:Fig7-No_Cookie_Read_Protection.PNG|frame|center|Figure 7 - Unenforced Cookie Read Protection]]

*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'''.

[[Image:Fig6-Cookie_Read_Protection.PNG|frame|center|Figure 8 - Enforced Cookie Write Protection]]

*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'''.

[[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!"]

[2] [http://msdn2.microsoft.com/en-us/library/ms533046.aspx Mitigating Cross-site Scripting with HTTP-Only Cookies]

[3] Howard, Michael. [http://msdn2.microsoft.com/en-us/library/ms972826.aspx Some Bad News and Some Good News]

HttpOnly

2007-08-02T13:28:50Z

Rknell:

== Overview ==

The goal of this section is to introduce, discuss, and provide language specific mitigation techniques for HTTPOnly.

<h3 style=color:#4682B4> <u> Who developed HTTPOnly? When? </u> </h3>

According to a daily blog article in 2002 by Jordan Wiens, “No cookie for you!,” 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. Using the HTTPOnly flag helps mitigate the risk of client side script accessing the session cookie.

*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 or the web site that originally set the cookie. As a result, even if a cross-site scripting '''(XSS)''' flaw exists, and a user accidentally accesses a link that exploits this flaw, 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 cookie will be either ignored or demoted to a traditional, scriptable cookie. As a result, your session cookie becomes vulnerable. [http://msdn2.microsoft.com/en-us/library/ms533046.aspx Mitigating], [http://msdn2.microsoft.com/en-us/library/ms533046.aspx]

<h3 style=color:#4682B4> <u> Mitigating XSS using HTTPOnly </u> </h3>

According to [http://msdn2.microsoft.com/en-us/library/ms972826.aspx Michael Howard], Senior Security Program Manager in the Secure Windows Initiative group at Microsoft, the majority of XSS attacks succeed because a session cookie has been leaked. A server could help mitigate this issue by setting a flag within a ''HTTP response header,'' indicating a session cookie should never be accessed by the client.

If Internet Explorer detects a cookie containing the HttpOnly flag, and client side script code attempts to read the cookie, Internet Explorer ''returns an empty string''. As a result, the attack fails by preventing the malicious XSS code from sending the data to an attacker's website. [http://msdn2.microsoft.com/en-us/library/ms972826.aspx Howard], [http://msdn2.microsoft.com/en-us/library/ms972826.aspx]

<h5 style=color:#2E8B57> <u> Using Java to Set HTTPOnly </u> </h5>

*'''Problem'''
**Most environments (e.g., Java EE) do not provide 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.

<h5 style=color:#2E8B57> <u> Using C#.NET to Set HTTPOnly </u> </h5>

*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
<httpCookies httpOnlyCookies="true" …>

*Or '''programmatically'''
HttpCookie myCookie = 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";

<h5 style=color:#2E8B57> <u> Using VB.NET to Set HTTPOnly </u> </h5>

*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
<httpCookies httpOnlyCookies="true" …>

*Or '''programmatically'''
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 capabilities. The results are listed below in '''table 1'''.

{|border="2" width="100%" align="center"
|+ '''Table 1:''' Browsers Supporting HTTPOnly
|-
! style="background:black; color:white" | '''Browser'''
! style="background:black; color:white" | '''Version'''
! style="background:black; color:white" | '''Supports HTTPOnly?'''
|-
| Microsoft Internet Explorer
| align="center" | 6 (SP1) - 7
| align="center" | Partially*
|-
| Mozilla Firefox
| align="center" | 2.0.0.5
| align="center" | Partially*
|-
| Netscape Navigator
| align="center" | 9.0b2
| align="center" | No
|-
| Opera
| align="center" | 9.22
| align="center" | No
|-
| Safari
| align="center" | 3.0
| align="center" | No
|}

<nowiki>*</nowiki> An attacker could still access the session identifier cookie using a '''[http://ha.ckers.org/blog/20070719/firefox-implements-httponly-and-is-vulnerable-to-xmlhttprequest/ 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.

<h3 style=color:#4682B4> <u> Getting Started </u> </h3>

[[Image:Click_link.JPG|thumb|175px|right|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.

<h3 style=color:#4682B4> <u> Lesson Goal </u> </h3>

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.

<h3 style=color:#4682B4> <u> Testing Web Browsers for HTTPOnly Support </u> </h3>

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.

<h5 style=color:#2E8B57> <u> Disabling HTTPOnly </u> </h5>

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

[[Image:Fig2-Disabling_HTTPOnly.PNG|frame|center|Figure 2 - Disabling HTTPOnly]]

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

[[Image:Fig3-Read_HTTPOnly_Off.PNG|frame|center|Figure 3 - Cookie Successfully Read with HTTPOnly Off]]

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

[[Image:Fig4-Write_HTTPOnly_Off.PNG|frame|center|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.

<h5 style=color:#2E8B57> <u> Enabling HTTPOnly </u> </h5>

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

[[Image:Fig5-Turning_HTTPOnly_On.PNG|frame|center|Figure 5 - Enabling HTTPOnly]]

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

[[Image:Fig6-Cookie_Read_Protection.PNG|frame|center|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'''.

[[Image:Fig7-No_Cookie_Read_Protection.PNG|frame|center|Figure 7 - Unenforced Cookie Read Protection]]

*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'''.

[[Image:Fig6-Cookie_Read_Protection.PNG|frame|center|Figure 8 - Enforced Cookie Write Protection]]

*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'''.

[[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!"]

[2] [http://msdn2.microsoft.com/en-us/library/ms533046.aspx Mitigating Cross-site Scripting with HTTP-Only Cookies]

[3] Howard, Michael. [http://msdn2.microsoft.com/en-us/library/ms972826.aspx Some Bad News and Some Good News]

HttpOnly

2007-08-02T13:27:57Z

Rknell:

== Overview ==

The goal of this section is to introduce, discuss, and provide language specific mitigation techniques for HTTPOnly.

<h3 style=color:#4682B4> <u> Who developed HTTPOnly? When? </u> </h3>

According to a daily blog article in 2002 by Jordan Wiens, “No cookie for you!,” 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. Using the HTTPOnly flag helps mitigate the risk of client side script accessing the session cookie.

*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 or the web site that originally set the cookie. As a result, even if a cross-site scripting '''(XSS)''' flaw exists, and a user accidentally accesses a link that exploits this flaw, 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 cookie will be either ignored or demoted to a traditional, scriptable cookie. As a result, your session cookie becomes vulnerable. [http://msdn2.microsoft.com/en-us/library/ms533046.aspx Mitigating], [http://msdn2.microsoft.com/en-us/library/ms533046.aspx]

<h3 style=color:#4682B4> <u> Mitigating XSS using HTTPOnly </u> </h3>

According to [http://msdn2.microsoft.com/en-us/library/ms972826.aspx Michael Howard], Senior Security Program Manager in the Secure Windows Initiative group at Microsoft, the majority of XSS attacks succeed because a session cookie has been leaked. A server could help mitigate this issue by setting a flag within a ''HTTP response header,'' indicating a session cookie should never be accessed by the client.

If Internet Explorer detects a cookie containing the HttpOnly flag, and client side script code attempts to read the cookie, Internet Explorer ''returns an empty string''. As a result, the attack fails by preventing the malicious XSS code from sending the data to an attacker's website. [http://msdn2.microsoft.com/en-us/library/ms972826.aspx Howard], [http://msdn2.microsoft.com/en-us/library/ms972826.aspx]

<h5 style=color:#2E8B57> <u> Using Java to Set HTTPOnly </u> </h5>

*'''Problem'''
**Most environments (e.g., Java EE) do not provide 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.

<h5 style=color:#2E8B57> <u> Using C#.NET to Set HTTPOnly </u> </h5>

*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
<httpCookies httpOnlyCookies="true" …>

*Or '''programmatically'''
HttpCookie myCookie = 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";

<h5 style=color:#2E8B57> <u> Using VB.NET to Set HTTPOnly </u> </h5>

*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
<httpCookies httpOnlyCookies="true" …>

*Or '''programmatically'''
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 capabilities. The results are listed below in '''table 1'''.

{|border="2" width="100%" align="center"
|+ '''Table 1:''' Browsers Supporting HTTPOnly
|-
! style="background:black; color:white" | '''Browser'''
! style="background:black; color:white" | '''Version'''
! style="background:black; color:white" | '''Supports HTTPOnly?'''
|-
| Microsoft Internet Explorer
| align="center" | 6 (SP1) - 7
| align="center" | Partially*
|-
| Mozilla Firefox
| align="center" | 2.0.0.5
| align="center" | Partially*
|-
| Netscape Navigator
| align="center" | 9.0b2
| align="center" | No
|-
| Opera
| align="center" | 9.22
| align="center" | No
|-
| Safari
| align="center" | 3.0
| align="center" | No
|}

<nowiki>*</nowiki> An attacker could still access the session identifier cookie using a '''[http://ha.ckers.org/blog/20070719/firefox-implements-httponly-and-is-vulnerable-to-xmlhttprequest/ 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.

<h3 style=color:#4682B4> <u> Getting Started </u> </h3>

[[Image:Click_link.JPG|thumb|175px|right|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 that support HTTPOnly.

<h3 style=color:#4682B4> <u> Lesson Goal </u> </h3>

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.

<h3 style=color:#4682B4> <u> Testing Web Browsers for HTTPOnly Support </u> </h3>

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.

<h5 style=color:#2E8B57> <u> Disabling HTTPOnly </u> </h5>

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

[[Image:Fig2-Disabling_HTTPOnly.PNG|frame|center|Figure 2 - Disabling HTTPOnly]]

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

[[Image:Fig3-Read_HTTPOnly_Off.PNG|frame|center|Figure 3 - Cookie Successfully Read with HTTPOnly Off]]

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

[[Image:Fig4-Write_HTTPOnly_Off.PNG|frame|center|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.

<h5 style=color:#2E8B57> <u> Enabling HTTPOnly </u> </h5>

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

[[Image:Fig5-Turning_HTTPOnly_On.PNG|frame|center|Figure 5 - Enabling HTTPOnly]]

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

[[Image:Fig6-Cookie_Read_Protection.PNG|frame|center|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'''.

[[Image:Fig7-No_Cookie_Read_Protection.PNG|frame|center|Figure 7 - Unenforced Cookie Read Protection]]

*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'''.

[[Image:Fig6-Cookie_Read_Protection.PNG|frame|center|Figure 8 - Enforced Cookie Write Protection]]

*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'''.

[[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!"]

[2] [http://msdn2.microsoft.com/en-us/library/ms533046.aspx Mitigating Cross-site Scripting with HTTP-Only Cookies]

[3] Howard, Michael. [http://msdn2.microsoft.com/en-us/library/ms972826.aspx Some Bad News and Some Good News]

HttpOnly

2007-08-02T13:23:50Z

Rknell:

== Overview ==

The goal of this section is to introduce, discuss, and provide language specific mitigation techniques for HTTPOnly.

<h3 style=color:#4682B4> <u> Who developed HTTPOnly? When? </u> </h3>

According to a daily blog article in 2002 by Jordan Wiens, “No cookie for you!,” 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. Using the HTTPOnly flag helps mitigate the risk of client side script accessing the session cookie.

*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 or the web site that originally set the cookie. As a result, even if a cross-site scripting '''(XSS)''' flaw exists, and a user accidentally accesses a link that exploits this flaw, 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 cookie will be either ignored or demoted to a traditional, scriptable cookie. As a result, your session cookie becomes vulnerable. [http://msdn2.microsoft.com/en-us/library/ms533046.aspx Mitigating], [http://msdn2.microsoft.com/en-us/library/ms533046.aspx]

<h3 style=color:#4682B4> <u> Mitigating XSS using HTTPOnly </u> </h3>

According to [http://msdn2.microsoft.com/en-us/library/ms972826.aspx Michael Howard], Senior Security Program Manager in the Secure Windows Initiative group at Microsoft, the majority of XSS attacks succeed because a session cookie has been leaked. A server could help mitigate this issue by setting a flag within a ''HTTP response header,'' indicating a session cookie should never be accessed by the client.

If Internet Explorer detects a cookie containing the HttpOnly flag, and client side script code attempts to read the cookie, Internet Explorer ''returns an empty string''. As a result, the attack fails by preventing the malicious XSS code from sending the data to an attacker's website. [http://msdn2.microsoft.com/en-us/library/ms972826.aspx Howard], [http://msdn2.microsoft.com/en-us/library/ms972826.aspx]

<h5 style=color:#2E8B57> <u> Using Java to Set HTTPOnly </u> </h5>

*'''Problem'''
**Most environments (e.g., Java EE) do not provide 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.

<h5 style=color:#2E8B57> <u> Using C#.NET to Set HTTPOnly </u> </h5>

*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
<httpCookies httpOnlyCookies="true" …>

*Or '''programmatically'''
HttpCookie myCookie = 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";

<h5 style=color:#2E8B57> <u> Using VB.NET to Set HTTPOnly </u> </h5>

*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
<httpCookies httpOnlyCookies="true" …>

*Or '''programmatically'''
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 capabilities. The results are listed below in '''table 1'''.

{|border="2" width="100%" align="center"
|+ '''Table 1:''' Browsers Supporting HTTPOnly
|-
! style="background:black; color:white" | '''Browser'''
! style="background:black; color:white" | '''Version'''
! style="background:black; color:white" | '''Supports HTTPOnly?'''
|-
| Microsoft Internet Explorer
| align="center" | 6 (SP1) - 7
| align="center" | Partially*
|-
| Mozilla Firefox
| align="center" | 2.0.0.5
| align="center" | Partially*
|-
| Netscape Navigator
| align="center" | 9.0b2
| align="center" | No
|-
| Opera
| align="center" | 9.22
| align="center" | No
|-
| Safari
| align="center" | 3.0
| align="center" | No
|}

<nowiki>*</nowiki> An attacker could still access the session identifier cookie using a '''[http://ha.ckers.org/blog/20070719/firefox-implements-httponly-and-is-vulnerable-to-xmlhttprequest/ 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.

<h3 style=color:#4682B4> <u> Getting Started </u> </h3>

[[Image:Click_link.JPG|thumb|175px|right|Figure 1 - Accessing WebGoat's HTTPOnly Test Lesson]]

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.

<h3 style=color:#4682B4> <u> Lesson Goal </u> </h3>

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.

<h3 style=color:#4682B4> <u> Testing Web Browsers for HTTPOnly Support </u> </h3>

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.

<h5 style=color:#2E8B57> <u> Disabling HTTPOnly </u> </h5>

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

[[Image:Fig2-Disabling_HTTPOnly.PNG|frame|center|Figure 2 - Disabling HTTPOnly]]

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

[[Image:Fig3-Read_HTTPOnly_Off.PNG|frame|center|Figure 3 - Cookie Successfully Read with HTTPOnly Off]]

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

[[Image:Fig4-Write_HTTPOnly_Off.PNG|frame|center|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.

<h5 style=color:#2E8B57> <u> Enabling HTTPOnly </u> </h5>

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

[[Image:Fig5-Turning_HTTPOnly_On.PNG|frame|center|Figure 5 - Enabling HTTPOnly]]

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

[[Image:Fig6-Cookie_Read_Protection.PNG|frame|center|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'''.

[[Image:Fig7-No_Cookie_Read_Protection.PNG|frame|center|Figure 7 - Unenforced Cookie Read Protection]]

*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'''.

[[Image:Fig6-Cookie_Read_Protection.PNG|frame|center|Figure 8 - Enforced Cookie Write Protection]]

*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'''.

[[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!"]

[2] [http://msdn2.microsoft.com/en-us/library/ms533046.aspx Mitigating Cross-site Scripting with HTTP-Only Cookies]

[3] Howard, Michael. [http://msdn2.microsoft.com/en-us/library/ms972826.aspx Some Bad News and Some Good News]

HttpOnly

2007-08-02T13:17:50Z

Rknell:

== Overview ==

The goal of this section is to introduce, discuss, and provide language specific mitigation techniques for HTTPOnly.

<h3 style=color:#4682B4> <u> Who developed HTTPOnly? When? </u> </h3>

According to a daily blog article in 2002 by Jordan Wiens, “No cookie for you!,” 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. Using the HTTPOnly flag helps mitigate the risk of client side script accessing the session cookie.

*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 or the web site that originally set the cookie. As a result, even if a cross-site scripting '''(XSS)''' flaw exists, and a user accidentally accesses a link that exploits this flaw, 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 cookie will be either ignored or demoted to a traditional, scriptable cookie. As a result, your session cookie becomes vulnerable. [http://msdn2.microsoft.com/en-us/library/ms533046.aspx Mitigating], [http://msdn2.microsoft.com/en-us/library/ms533046.aspx]

<h3 style=color:#4682B4> <u> Mitigating XSS using HTTPOnly </u> </h3>

According to [http://msdn2.microsoft.com/en-us/library/ms972826.aspx Michael Howard], Senior Security Program Manager in the Secure Windows Initiative group at Microsoft, the majority of XSS attacks succeed because a session cookie has been leaked. A server could help mitigate this issue by setting a flag within a ''HTTP response header,'' indicating a session cookie should never be accessed by the client.

If Internet Explorer detects a cookie containing the HttpOnly flag, and client side script code attempts to read the cookie, Internet Explorer ''returns an empty string''. As a result, the attack fails by preventing the malicious XSS code from sending the data to an attacker's website. [http://msdn2.microsoft.com/en-us/library/ms972826.aspx Howard], [http://msdn2.microsoft.com/en-us/library/ms972826.aspx]

<h5 style=color:#2E8B57> <u> Using Java to Set HTTPOnly </u> </h5>

*'''Problem'''
**Most environments (e.g., Java EE) do not provide 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

<h5 style=color:#2E8B57> <u> Using C#.NET to Set HTTPOnly </u> </h5>

*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
<httpCookies httpOnlyCookies="true" …>

*Or '''programmatically'''
HttpCookie myCookie = 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";

<h5 style=color:#2E8B57> <u> Using VB.NET to Set HTTPOnly </u> </h5>

*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
<httpCookies httpOnlyCookies="true" …>

*Or '''programmatically'''
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 capabilities. The results are listed below in '''table 1'''.

{|border="2" width="100%" align="center"
|+ '''Table 1:''' Browsers Supporting HTTPOnly
|-
! style="background:black; color:white" | '''Browser'''
! style="background:black; color:white" | '''Version'''
! style="background:black; color:white" | '''Supports HTTPOnly?'''
|-
| Microsoft Internet Explorer
| align="center" | 6 (SP1) - 7
| align="center" | Partially*
|-
| Mozilla Firefox
| align="center" | 2.0.0.5
| align="center" | Partially*
|-
| Netscape Navigator
| align="center" | 9.0b2
| align="center" | No
|-
| Opera
| align="center" | 9.22
| align="center" | No
|-
| Safari
| align="center" | 3.0
| align="center" | No
|}

<nowiki>*</nowiki> An attacker could still access the session identifier cookie using a '''[http://ha.ckers.org/blog/20070719/firefox-implements-httponly-and-is-vulnerable-to-xmlhttprequest/ 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.

<h3 style=color:#4682B4> <u> Getting Started </u> </h3>

[[Image:Click_link.JPG|thumb|175px|right|Figure 1 - Accessing WebGoat's HTTPOnly Test Lesson]]

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.

<h3 style=color:#4682B4> <u> Lesson Goal </u> </h3>

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.

<h3 style=color:#4682B4> <u> Testing Web Browsers for HTTPOnly Support </u> </h3>

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.

<h5 style=color:#2E8B57> <u> Disabling HTTPOnly </u> </h5>

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

[[Image:Fig2-Disabling_HTTPOnly.PNG|frame|center|Figure 2 - Disabling HTTPOnly]]

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

[[Image:Fig3-Read_HTTPOnly_Off.PNG|frame|center|Figure 3 - Cookie Successfully Read with HTTPOnly Off]]

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

[[Image:Fig4-Write_HTTPOnly_Off.PNG|frame|center|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.

<h5 style=color:#2E8B57> <u> Enabling HTTPOnly </u> </h5>

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

[[Image:Fig5-Turning_HTTPOnly_On.PNG|frame|center|Figure 5 - Enabling HTTPOnly]]

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

[[Image:Fig6-Cookie_Read_Protection.PNG|frame|center|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'''.

[[Image:Fig7-No_Cookie_Read_Protection.PNG|frame|center|Figure 7 - Unenforced Cookie Read Protection]]

*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'''.

[[Image:Fig6-Cookie_Read_Protection.PNG|frame|center|Figure 8 - Enforced Cookie Write Protection]]

*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'''.

[[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!"]

[2] [http://msdn2.microsoft.com/en-us/library/ms533046.aspx Mitigating Cross-site Scripting with HTTP-Only Cookies]

[3] Howard, Michael. [http://msdn2.microsoft.com/en-us/library/ms972826.aspx Some Bad News and Some Good News]

HttpOnly

2007-07-31T16:29:13Z

Rknell: Added: Safari

== Overview ==

The goal of this section is to introduce, discuss, and provide language specific mitigation techniques 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. Using the HTTPOnly flag helps mitigate the risk of client side script accessing the session cookie.

*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 or the web site that originally set the cookie. As a result, even if a cross-site scripting '''(XSS)''' flaw exists, and a user accidentally accesses a link that exploits this flaw, 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 cookie will be either ignored or demoted to a traditional, scriptable cookie. As a result, your session cookie becomes vulnerable. [http://msdn2.microsoft.com/en-us/library/ms533046.aspx Mitigating], [http://msdn2.microsoft.com/en-us/library/ms533046.aspx]

<h3 style=color:#4682B4> <u> Mitigating XSS using HTTPOnly </u> </h3>

According to [http://msdn2.microsoft.com/en-us/library/ms972826.aspx Michael Howard], Senior Security Program Manager in the Secure Windows Initiative group at Microsoft, the majority of XSS attacks succeed because a session cookie has been leaked. A server could help mitigate this issue by setting a flag within a ''HTTP response header,'' indicating a session cookie should never be accessed by the client.

If Internet Explorer detects a cookie containing the HttpOnly flag, and client side script code attempts to read the cookie, Internet Explorer ''returns an empty string''. As a result, the attack fails by preventing the malicious XSS code from sending the data to an attacker's website. [http://msdn2.microsoft.com/en-us/library/ms972826.aspx Howard], [http://msdn2.microsoft.com/en-us/library/ms972826.aspx]

<h5 style=color:#2E8B57> <u> Using Java to Set HTTPOnly </u> </h5>

*'''Problem'''
**Most environments (e.g., Java EE) do not provide 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

<h5 style=color:#2E8B57> <u> Using C#.NET to Set HTTPOnly </u> </h5>

*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
<httpCookies httpOnlyCookies="true" …>

*Or '''programmatically'''
HttpCookie myCookie = 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";

<h5 style=color:#2E8B57> <u> Using VB.NET to Set HTTPOnly </u> </h5>

*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
<httpCookies httpOnlyCookies="true" …>

*Or '''programmatically'''
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 capabilities. The results are listed below in '''table 1'''.

{|border="2" width="100%" align="center"
|+ '''Table 1:''' Browsers Supporting HTTPOnly
|-
! style="background:black; color:white" | '''Browser'''
! style="background:black; color:white" | '''Version'''
! style="background:black; color:white" | '''Supports HTTPOnly?'''
|-
| Microsoft Internet Explorer
| align="center" | 6 (SP1) - 7
| align="center" | Partially*
|-
| Mozilla Firefox
| align="center" | 2.0.0.5
| align="center" | Partially*
|-
| Netscape Navigator
| align="center" | 9.0b2
| align="center" | No
|-
| Opera
| align="center" | 9.22
| align="center" | No
|-
| Safari
| align="center" | 3.0
| align="center" | No
|}

<nowiki>*</nowiki> An attacker could still access the session identifier cookie using a '''[http://ha.ckers.org/blog/20070719/firefox-implements-httponly-and-is-vulnerable-to-xmlhttprequest/ 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.

<h3 style=color:#4682B4> <u> Getting Started </u> </h3>

[[Image:Click_link.JPG|thumb|175px|right|Figure 1 - Accessing WebGoat's HTTPOnly Test Lesson]]

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.

<h3 style=color:#4682B4> <u> Lesson Goal </u> </h3>

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.

<h3 style=color:#4682B4> <u> Testing Web Browsers for HTTPOnly Support </u> </h3>

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.

<h5 style=color:#2E8B57> <u> Disabling HTTPOnly </u> </h5>

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

[[Image:Fig2-Disabling_HTTPOnly.PNG|frame|center|Figure 2 - Disabling HTTPOnly]]

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

[[Image:Fig3-Read_HTTPOnly_Off.PNG|frame|center|Figure 3 - Cookie Successfully Read with HTTPOnly Off]]

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

[[Image:Fig4-Write_HTTPOnly_Off.PNG|frame|center|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.

<h5 style=color:#2E8B57> <u> Enabling HTTPOnly </u> </h5>

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

[[Image:Fig5-Turning_HTTPOnly_On.PNG|frame|center|Figure 5 - Enabling HTTPOnly]]

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

[[Image:Fig6-Cookie_Read_Protection.PNG|frame|center|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'''.

[[Image:Fig7-No_Cookie_Read_Protection.PNG|frame|center|Figure 7 - Unenforced Cookie Read Protection]]

*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'''.

[[Image:Fig6-Cookie_Read_Protection.PNG|frame|center|Figure 8 - Enforced Cookie Write Protection]]

*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'''.

[[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!"]

[2] [http://msdn2.microsoft.com/en-us/library/ms533046.aspx Mitigating Cross-site Scripting with HTTP-Only Cookies]

[3] Howard, Michael. [http://msdn2.microsoft.com/en-us/library/ms972826.aspx Some Bad News and Some Good News]

HttpOnly

2007-07-30T13:51:09Z

Rknell:

== Overview ==

The goal of this section is to introduce, discuss, and provide language specific mitigation techniques 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. Using the HTTPOnly flag helps mitigate the risk of client side script accessing the session cookie.

*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 or the web site that originally set the cookie. As a result, even if a cross-site scripting '''(XSS)''' flaw exists, and a user accidentally accesses a link that exploits this flaw, 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 cookie will be either ignored or demoted to a traditional, scriptable cookie. As a result, your session cookie becomes vulnerable. [http://msdn2.microsoft.com/en-us/library/ms533046.aspx Mitigating], [http://msdn2.microsoft.com/en-us/library/ms533046.aspx]

<h3 style=color:#4682B4> <u> Mitigating XSS using HTTPOnly </u> </h3>

According to [http://msdn2.microsoft.com/en-us/library/ms972826.aspx Michael Howard], Senior Security Program Manager in the Secure Windows Initiative group at Microsoft, the majority of XSS attacks succeed because a session cookie has been leaked. A server could help mitigate this issue by setting a flag within a ''HTTP response header,'' indicating a session cookie should never be accessed by the client.

If Internet Explorer detects a cookie containing the HttpOnly flag, and client side script code attempts to read the cookie, Internet Explorer ''returns an empty string''. As a result, the attack fails by preventing the malicious XSS code from sending the data to an attacker's website. [http://msdn2.microsoft.com/en-us/library/ms972826.aspx Howard], [http://msdn2.microsoft.com/en-us/library/ms972826.aspx]

<h5 style=color:#2E8B57> <u> Using Java to Set HTTPOnly </u> </h5>

*'''Problem'''
**Most environments (e.g., Java EE) do not provide 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

<h5 style=color:#2E8B57> <u> Using C#.NET to Set HTTPOnly </u> </h5>

*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
<httpCookies httpOnlyCookies="true" …>

*Or '''programmatically'''
HttpCookie myCookie = 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";

<h5 style=color:#2E8B57> <u> Using VB.NET to Set HTTPOnly </u> </h5>

*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
<httpCookies httpOnlyCookies="true" …>

*Or '''programmatically'''
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 capabilities. The results are listed below in '''table 1'''.

{|border="2" width="100%" align="center"
|+ '''Table 1:''' Browsers Supporting HTTPOnly
|-
! style="background:black; color:white" | '''Browser'''
! style="background:black; color:white" | '''Version'''
! style="background:black; color:white" | '''Supports HTTPOnly?'''
|-
| Microsoft Internet Explorer
| align="center" | 6 (SP1) - 7
| align="center" | Partially*
|-
| Mozilla Firefox
| align="center" | 2.0.0.5
| align="center" | Partially*
|-
| Netscape Navigator
| align="center" | 9.0b2
| align="center" | No
|-
| Opera
| align="center" | 9.22
| align="center" | No
|}

<nowiki>*</nowiki> An attacker could still access the session identifier cookie using a '''[http://ha.ckers.org/blog/20070719/firefox-implements-httponly-and-is-vulnerable-to-xmlhttprequest/ 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.

<h3 style=color:#4682B4> <u> Getting Started </u> </h3>

[[Image:Click_link.JPG|thumb|175px|right|Figure 1 - Accessing WebGoat's HTTPOnly Test Lesson]]

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.

<h3 style=color:#4682B4> <u> Lesson Goal </u> </h3>

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.

<h3 style=color:#4682B4> <u> Testing Web Browsers for HTTPOnly Support </u> </h3>

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.

<h5 style=color:#2E8B57> <u> Disabling HTTPOnly </u> </h5>

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

[[Image:Fig2-Disabling_HTTPOnly.PNG|frame|center|Figure 2 - Disabling HTTPOnly]]

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

[[Image:Fig3-Read_HTTPOnly_Off.PNG|frame|center|Figure 3 - Cookie Successfully Read with HTTPOnly Off]]

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

[[Image:Fig4-Write_HTTPOnly_Off.PNG|frame|center|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.

<h5 style=color:#2E8B57> <u> Enabling HTTPOnly </u> </h5>

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

[[Image:Fig5-Turning_HTTPOnly_On.PNG|frame|center|Figure 5 - Enabling HTTPOnly]]

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

[[Image:Fig6-Cookie_Read_Protection.PNG|frame|center|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'''.

[[Image:Fig7-No_Cookie_Read_Protection.PNG|frame|center|Figure 7 - Unenforced Cookie Read Protection]]

*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'''.

[[Image:Fig6-Cookie_Read_Protection.PNG|frame|center|Figure 8 - Enforced Cookie Write Protection]]

*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'''.

[[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!"]

[2] [http://msdn2.microsoft.com/en-us/library/ms533046.aspx Mitigating Cross-site Scripting with HTTP-Only Cookies]

[3] Howard, Michael. [http://msdn2.microsoft.com/en-us/library/ms972826.aspx Some Bad News and Some Good News]

HttpOnly

2007-07-27T18:30:21Z

Rknell:

== Overview ==

The goal of this section is to introduce, discuss, and discuss language specific mitigation techniques 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. Using the HTTPOnly flag helps mitigate the risk of client side script accessing the session cookie.

*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 or the web site that originally set the cookie. As a result, even if a cross-site scripting '''(XSS)''' flaw exists, and a user accidentally accesses a link that exploits this flaw, 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 cookie will be either ignored or demoted to a traditional, scriptable cookie. As a result, your session cookie becomes vulnerable. [http://msdn2.microsoft.com/en-us/library/ms533046.aspx Mitigating], [http://msdn2.microsoft.com/en-us/library/ms533046.aspx]

<h3 style=color:#4682B4> <u> Mitigating XSS using HTTPOnly </u> </h3>

According to [http://msdn2.microsoft.com/en-us/library/ms972826.aspx Michael Howard], Senior Security Program Manager in the Secure Windows Initiative group at Microsoft, the majority of XSS attacks succeed because a session cookie has been leaked. A server could help mitigate this issue by setting a flag within a ''HTTP response header,'' indicating a session cookie should never be accessed by the client.

If Internet Explorer detects a cookie containing the HttpOnly flag, and client side script code attempts to read the cookie, Internet Explorer ''returns an empty string''. As a result, the attack fails by preventing the malicious XSS code from sending the data to an attacker's website. [http://msdn2.microsoft.com/en-us/library/ms972826.aspx Howard], [http://msdn2.microsoft.com/en-us/library/ms972826.aspx]

<h5 style=color:#2E8B57> <u> Using Java to Set HTTPOnly </u> </h5>

*'''Problem'''
**Most environments (e.g., Java EE) do not provide 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

<h5 style=color:#2E8B57> <u> Using C#.NET to Set HTTPOnly </u> </h5>

*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
<httpCookies httpOnlyCookies="true" …>

*Or '''programmatically'''
HttpCookie myCookie = 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";

<h5 style=color:#2E8B57> <u> Using VB.NET to Set HTTPOnly </u> </h5>

*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
<httpCookies httpOnlyCookies="true" …>

*Or '''programmatically'''
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 capabilities. The results are listed below in '''table 1'''.

{|border="2" width="100%" align="center"
|+ '''Table 1:''' Browsers Supporting HTTPOnly
|-
! style="background:black; color:white" | '''Browser'''
! style="background:black; color:white" | '''Version'''
! style="background:black; color:white" | '''Supports HTTPOnly?'''
|-
| Microsoft Internet Explorer
| align="center" | 6 (SP1) - 7
| align="center" | Partially*
|-
| Mozilla Firefox
| align="center" | 2.0.0.5
| align="center" | Partially*
|-
| Netscape Navigator
| align="center" | 9.0b2
| align="center" | No
|-
| Opera
| align="center" | 9.22
| align="center" | No
|}

<nowiki>*</nowiki> An attacker could still access the session identifier cookie using a '''[http://ha.ckers.org/blog/20070719/firefox-implements-httponly-and-is-vulnerable-to-xmlhttprequest/ 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.

<h3 style=color:#4682B4> <u> Getting Started </u> </h3>

[[Image:Click_link.JPG|thumb|175px|right|Figure 1 - Accessing WebGoat's HTTPOnly Test Lesson]]

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.

<h3 style=color:#4682B4> <u> Lesson Goal </u> </h3>

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.

<h3 style=color:#4682B4> <u> Testing Web Browsers for HTTPOnly Support </u> </h3>

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.

<h5 style=color:#2E8B57> <u> Disabling HTTPOnly </u> </h5>

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

[[Image:Fig2-Disabling_HTTPOnly.PNG|frame|center|Figure 2 - Disabling HTTPOnly]]

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

[[Image:Fig3-Read_HTTPOnly_Off.PNG|frame|center|Figure 3 - Cookie Successfully Read with HTTPOnly Off]]

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

[[Image:Fig4-Write_HTTPOnly_Off.PNG|frame|center|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.

<h5 style=color:#2E8B57> <u> Enabling HTTPOnly </u> </h5>

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

[[Image:Fig5-Turning_HTTPOnly_On.PNG|frame|center|Figure 5 - Enabling HTTPOnly]]

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

[[Image:Fig6-Cookie_Read_Protection.PNG|frame|center|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'''.

[[Image:Fig7-No_Cookie_Read_Protection.PNG|frame|center|Figure 7 - Unenforced Cookie Read Protection]]

*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'''.

[[Image:Fig6-Cookie_Read_Protection.PNG|frame|center|Figure 8 - Enforced Cookie Write Protection]]

*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'''.

[[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!"]

[2] [http://msdn2.microsoft.com/en-us/library/ms533046.aspx Mitigating Cross-site Scripting with HTTP-Only Cookies]

[3] Howard, Michael. [http://msdn2.microsoft.com/en-us/library/ms972826.aspx Some Bad News and Some Good News]

HttpOnly

2007-07-27T18:29:27Z

Rknell:

== Overview ==

The goal of this section is to introduce, discuss, and discuss language specific mitigation techniques 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. Using the HTTPOnly flag helps mitigate the risk of client side script accessing the session cookie.

*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 or the web site that originally set the cookie. As a result, even if a cross-site scripting '''(XSS)''' flaw exists, and a user accidentally accesses a link that exploits this flaw, 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 cookie will be either ignored or demoted to a traditional, scriptable cookie. Unfortunately, your session cookie now becomes vulnerable. [http://msdn2.microsoft.com/en-us/library/ms533046.aspx Mitigating], [http://msdn2.microsoft.com/en-us/library/ms533046.aspx]

<h3 style=color:#4682B4> <u> Mitigating XSS using HTTPOnly </u> </h3>

According to [http://msdn2.microsoft.com/en-us/library/ms972826.aspx Michael Howard], Senior Security Program Manager in the Secure Windows Initiative group at Microsoft, the majority of XSS attacks succeed because a session cookie has been leaked. A server could help mitigate this issue by setting a flag within a ''HTTP response header,'' indicating a session cookie should never be accessed by the client.

If Internet Explorer detects a cookie containing the HttpOnly flag, and client side script code attempts to read the cookie, Internet Explorer ''returns an empty string''. As a result, the attack fails by preventing the malicious XSS code from sending the data to an attacker's website. [http://msdn2.microsoft.com/en-us/library/ms972826.aspx Howard], [http://msdn2.microsoft.com/en-us/library/ms972826.aspx]

<h5 style=color:#2E8B57> <u> Using Java to Set HTTPOnly </u> </h5>

*'''Problem'''
**Most environments (e.g., Java EE) do not provide 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

<h5 style=color:#2E8B57> <u> Using C#.NET to Set HTTPOnly </u> </h5>

*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
<httpCookies httpOnlyCookies="true" …>

*Or '''programmatically'''
HttpCookie myCookie = 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";

<h5 style=color:#2E8B57> <u> Using VB.NET to Set HTTPOnly </u> </h5>

*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
<httpCookies httpOnlyCookies="true" …>

*Or '''programmatically'''
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 capabilities. The results are listed below in '''table 1'''.

{|border="2" width="100%" align="center"
|+ '''Table 1:''' Browsers Supporting HTTPOnly
|-
! style="background:black; color:white" | '''Browser'''
! style="background:black; color:white" | '''Version'''
! style="background:black; color:white" | '''Supports HTTPOnly?'''
|-
| Microsoft Internet Explorer
| align="center" | 6 (SP1) - 7
| align="center" | Partially*
|-
| Mozilla Firefox
| align="center" | 2.0.0.5
| align="center" | Partially*
|-
| Netscape Navigator
| align="center" | 9.0b2
| align="center" | No
|-
| Opera
| align="center" | 9.22
| align="center" | No
|}

<nowiki>*</nowiki> An attacker could still access the session identifier cookie using a '''[http://ha.ckers.org/blog/20070719/firefox-implements-httponly-and-is-vulnerable-to-xmlhttprequest/ 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.

<h3 style=color:#4682B4> <u> Getting Started </u> </h3>

[[Image:Click_link.JPG|thumb|175px|right|Figure 1 - Accessing WebGoat's HTTPOnly Test Lesson]]

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.

<h3 style=color:#4682B4> <u> Lesson Goal </u> </h3>

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.

<h3 style=color:#4682B4> <u> Testing Web Browsers for HTTPOnly Support </u> </h3>

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.

<h5 style=color:#2E8B57> <u> Disabling HTTPOnly </u> </h5>

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

[[Image:Fig2-Disabling_HTTPOnly.PNG|frame|center|Figure 2 - Disabling HTTPOnly]]

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

[[Image:Fig3-Read_HTTPOnly_Off.PNG|frame|center|Figure 3 - Cookie Successfully Read with HTTPOnly Off]]

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

[[Image:Fig4-Write_HTTPOnly_Off.PNG|frame|center|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.

<h5 style=color:#2E8B57> <u> Enabling HTTPOnly </u> </h5>

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

[[Image:Fig5-Turning_HTTPOnly_On.PNG|frame|center|Figure 5 - Enabling HTTPOnly]]

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

[[Image:Fig6-Cookie_Read_Protection.PNG|frame|center|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'''.

[[Image:Fig7-No_Cookie_Read_Protection.PNG|frame|center|Figure 7 - Unenforced Cookie Read Protection]]

*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'''.

[[Image:Fig6-Cookie_Read_Protection.PNG|frame|center|Figure 8 - Enforced Cookie Write Protection]]

*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'''.

[[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!"]

[2] [http://msdn2.microsoft.com/en-us/library/ms533046.aspx Mitigating Cross-site Scripting with HTTP-Only Cookies]

[3] Howard, Michael. [http://msdn2.microsoft.com/en-us/library/ms972826.aspx Some Bad News and Some Good News]

HttpOnly

2007-07-27T18:27:30Z

Rknell:

== Overview ==

The goal of this section is to introduce, discuss, and discuss language specific mitigation techniques 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. Using the HTTPOnly flag helps mitigate the risk of client side script accessing the session cookie.

*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 or the web site that originally set the cookie. As a result, even if a cross-site scripting '''(XSS)''' flaw exists, and a user accidentally accesses a link that exploits this flaw, 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 cookie will be 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 Mitigating], [http://msdn2.microsoft.com/en-us/library/ms533046.aspx]

<h3 style=color:#4682B4> <u> Mitigating XSS using HTTPOnly </u> </h3>

According to [http://msdn2.microsoft.com/en-us/library/ms972826.aspx Michael Howard], Senior Security Program Manager in the Secure Windows Initiative group at Microsoft, the majority of XSS attacks succeed because a session cookie has been leaked. A server could help mitigate this issue by setting a flag within a ''HTTP response header,'' indicating a session cookie should never be accessed by the client.

If Internet Explorer detects a cookie containing the HttpOnly flag, and client side script code attempts to read the cookie, Internet Explorer ''returns an empty string''. As a result, the attack fails by preventing the malicious XSS code from sending the data to an attacker's website. [http://msdn2.microsoft.com/en-us/library/ms972826.aspx Howard], [http://msdn2.microsoft.com/en-us/library/ms972826.aspx]

<h5 style=color:#2E8B57> <u> Using Java to Set HTTPOnly </u> </h5>

*'''Problem'''
**Most environments (e.g., Java EE) do not provide 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

<h5 style=color:#2E8B57> <u> Using C#.NET to Set HTTPOnly </u> </h5>

*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
<httpCookies httpOnlyCookies="true" …>

*Or '''programmatically'''
HttpCookie myCookie = 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";

<h5 style=color:#2E8B57> <u> Using VB.NET to Set HTTPOnly </u> </h5>

*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
<httpCookies httpOnlyCookies="true" …>

*Or '''programmatically'''
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 capabilities. The results are listed below in '''table 1'''.

{|border="2" width="100%" align="center"
|+ '''Table 1:''' Browsers Supporting HTTPOnly
|-
! style="background:black; color:white" | '''Browser'''
! style="background:black; color:white" | '''Version'''
! style="background:black; color:white" | '''Supports HTTPOnly?'''
|-
| Microsoft Internet Explorer
| align="center" | 6 (SP1) - 7
| align="center" | Partially*
|-
| Mozilla Firefox
| align="center" | 2.0.0.5
| align="center" | Partially*
|-
| Netscape Navigator
| align="center" | 9.0b2
| align="center" | No
|-
| Opera
| align="center" | 9.22
| align="center" | No
|}

<nowiki>*</nowiki> An attacker could still access the session identifier cookie using a '''[http://ha.ckers.org/blog/20070719/firefox-implements-httponly-and-is-vulnerable-to-xmlhttprequest/ 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.

<h3 style=color:#4682B4> <u> Getting Started </u> </h3>

[[Image:Click_link.JPG|thumb|175px|right|Figure 1 - Accessing WebGoat's HTTPOnly Test Lesson]]

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.

<h3 style=color:#4682B4> <u> Lesson Goal </u> </h3>

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.

<h3 style=color:#4682B4> <u> Testing Web Browsers for HTTPOnly Support </u> </h3>

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.

<h5 style=color:#2E8B57> <u> Disabling HTTPOnly </u> </h5>

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

[[Image:Fig2-Disabling_HTTPOnly.PNG|frame|center|Figure 2 - Disabling HTTPOnly]]

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

[[Image:Fig3-Read_HTTPOnly_Off.PNG|frame|center|Figure 3 - Cookie Successfully Read with HTTPOnly Off]]

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

[[Image:Fig4-Write_HTTPOnly_Off.PNG|frame|center|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.

<h5 style=color:#2E8B57> <u> Enabling HTTPOnly </u> </h5>

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

[[Image:Fig5-Turning_HTTPOnly_On.PNG|frame|center|Figure 5 - Enabling HTTPOnly]]

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

[[Image:Fig6-Cookie_Read_Protection.PNG|frame|center|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'''.

[[Image:Fig7-No_Cookie_Read_Protection.PNG|frame|center|Figure 7 - Unenforced Cookie Read Protection]]

*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'''.

[[Image:Fig6-Cookie_Read_Protection.PNG|frame|center|Figure 8 - Enforced Cookie Write Protection]]

*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'''.

[[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!"]

[2] [http://msdn2.microsoft.com/en-us/library/ms533046.aspx Mitigating Cross-site Scripting with HTTP-Only Cookies]

[3] Howard, Michael. [http://msdn2.microsoft.com/en-us/library/ms972826.aspx Some Bad News and Some Good News]

HttpOnly

2007-07-27T18:24:10Z

Rknell:

== Overview ==

The goal of this section is to introduce, discuss, and discuss language specific mitigation techniques 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. Using the HTTPOnly flag helps 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 or the web site that originally set the cookie. As a result, even if a cross-site scripting '''(XSS)''' flaw exists, and a user accidentally accesses a link that exploits this flaw, 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 cookie will be 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 Mitigating], [http://msdn2.microsoft.com/en-us/library/ms533046.aspx]

<h3 style=color:#4682B4> <u> Mitigating XSS using HTTPOnly </u> </h3>

According to [http://msdn2.microsoft.com/en-us/library/ms972826.aspx Michael Howard], Senior Security Program Manager in the Secure Windows Initiative group at Microsoft, the majority of XSS attacks succeed because a session cookie has been leaked. A server could help mitigate this issue by setting a flag within a ''HTTP response header,'' indicating a session cookie should never be accessed by the client.

If Internet Explorer detects a cookie containing the HttpOnly flag, and client side script code attempts to read the cookie, Internet Explorer ''returns an empty string''. As a result, the attack fails by preventing the malicious XSS code from sending the data to an attacker's website. [http://msdn2.microsoft.com/en-us/library/ms972826.aspx Howard], [http://msdn2.microsoft.com/en-us/library/ms972826.aspx]

<h5 style=color:#2E8B57> <u> Using Java to Set HTTPOnly </u> </h5>

*'''Problem'''
**Most environments (e.g., Java EE) do not provide 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

<h5 style=color:#2E8B57> <u> Using C#.NET to Set HTTPOnly </u> </h5>

*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
<httpCookies httpOnlyCookies="true" …>

*Or '''programmatically'''
HttpCookie myCookie = 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";

<h5 style=color:#2E8B57> <u> Using VB.NET to Set HTTPOnly </u> </h5>

*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
<httpCookies httpOnlyCookies="true" …>

*Or '''programmatically'''
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 capabilities. The results are listed below in '''table 1'''.

{|border="2" width="100%" align="center"
|+ '''Table 1:''' Browsers Supporting HTTPOnly
|-
! style="background:black; color:white" | '''Browser'''
! style="background:black; color:white" | '''Version'''
! style="background:black; color:white" | '''Supports HTTPOnly?'''
|-
| Microsoft Internet Explorer
| align="center" | 6 (SP1) - 7
| align="center" | Partially*
|-
| Mozilla Firefox
| align="center" | 2.0.0.5
| align="center" | Partially*
|-
| Netscape Navigator
| align="center" | 9.0b2
| align="center" | No
|-
| Opera
| align="center" | 9.22
| align="center" | No
|}

<nowiki>*</nowiki> An attacker could still access the session identifier cookie using a '''[http://ha.ckers.org/blog/20070719/firefox-implements-httponly-and-is-vulnerable-to-xmlhttprequest/ 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.

<h3 style=color:#4682B4> <u> Getting Started </u> </h3>

[[Image:Click_link.JPG|thumb|175px|right|Figure 1 - Accessing WebGoat's HTTPOnly Test Lesson]]

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.

<h3 style=color:#4682B4> <u> Lesson Goal </u> </h3>

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.

<h3 style=color:#4682B4> <u> Testing Web Browsers for HTTPOnly Support </u> </h3>

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.

<h5 style=color:#2E8B57> <u> Disabling HTTPOnly </u> </h5>

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

[[Image:Fig2-Disabling_HTTPOnly.PNG|frame|center|Figure 2 - Disabling HTTPOnly]]

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

[[Image:Fig3-Read_HTTPOnly_Off.PNG|frame|center|Figure 3 - Cookie Successfully Read with HTTPOnly Off]]

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

[[Image:Fig4-Write_HTTPOnly_Off.PNG|frame|center|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.

<h5 style=color:#2E8B57> <u> Enabling HTTPOnly </u> </h5>

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

[[Image:Fig5-Turning_HTTPOnly_On.PNG|frame|center|Figure 5 - Enabling HTTPOnly]]

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

[[Image:Fig6-Cookie_Read_Protection.PNG|frame|center|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'''.

[[Image:Fig7-No_Cookie_Read_Protection.PNG|frame|center|Figure 7 - Unenforced Cookie Read Protection]]

*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'''.

[[Image:Fig6-Cookie_Read_Protection.PNG|frame|center|Figure 8 - Enforced Cookie Write Protection]]

*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'''.

[[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!"]

[2] [http://msdn2.microsoft.com/en-us/library/ms533046.aspx Mitigating Cross-site Scripting with HTTP-Only Cookies]

[3] Howard, Michael. [http://msdn2.microsoft.com/en-us/library/ms972826.aspx Some Bad News and Some Good News]

HttpOnly

2007-07-27T18:20:44Z

Rknell:

== Overview ==

The goal of this section is to introduce, discuss, and discuss language specific mitigation techniques 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. Using the HTTPOnly flag helps 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 or the web site that originally set the cookie. As a result, even if a cross-site scripting '''(XSS)''' flaw exists, and a user accidentally accesses a link that exploits this flaw, 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 cookie will be 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 Mitigating], [http://msdn2.microsoft.com/en-us/library/ms533046.aspx]

<h3 style=color:#4682B4> <u> Mitigating XSS using HTTPOnly </u> </h3>

According to [http://msdn2.microsoft.com/en-us/library/ms972826.aspx Michael Howard], Senior Security Program Manager in the Secure Windows Initiative group at Microsoft, the majority of XSS attacks succeed because a session cookie has been leaked. A server could help mitigate this issue by setting a flag within a ''HTTP response header,'' indicating a session cookie should never be accessed by the client.

If Internet Explorer detects a cookie containing the HttpOnly flag, and client side script code attempts to read the cookie, Internet Explorer ''returns an empty string''. As a result, the attack fails by preventing the malicious XSS code from sending the data to an attacker's website. [http://msdn2.microsoft.com/en-us/library/ms972826.aspx Howard], [http://msdn2.microsoft.com/en-us/library/ms972826.aspx]

<h5 style=color:#2E8B57> <u> Java: Setting HTTPOnly </u> </h5>

*'''Problem'''
**Most environments (e.g., Java EE) do not provide 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

<h5 style=color:#2E8B57> <u> C#.NET: Setting HTTPOnly </u> </h5>

*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
<httpCookies httpOnlyCookies="true" …>

*Or '''programmatically'''
HttpCookie myCookie = 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";

<h5 style=color:#2E8B57> <u> VB.NET: Setting HTTPOnly </u> </h5>

*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
<httpCookies httpOnlyCookies="true" …>

*Or '''programmatically'''
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 capabilities. The results are listed below in '''table 1'''.

{|border="2" width="100%" align="center"
|+ '''Table 1:''' Browsers Supporting HTTPOnly
|-
! style="background:black; color:white" | '''Browser'''
! style="background:black; color:white" | '''Version'''
! style="background:black; color:white" | '''Supports HTTPOnly?'''
|-
| Microsoft Internet Explorer
| align="center" | 6 (SP1) - 7
| align="center" | Partially*
|-
| Mozilla Firefox
| align="center" | 2.0.0.5
| align="center" | Partially*
|-
| Netscape Navigator
| align="center" | 9.0b2
| align="center" | No
|-
| Opera
| align="center" | 9.22
| align="center" | No
|}

<nowiki>*</nowiki> An attacker could still access the session identifier cookie using a '''[http://ha.ckers.org/blog/20070719/firefox-implements-httponly-and-is-vulnerable-to-xmlhttprequest/ 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.

<h3 style=color:#4682B4> <u> Getting Started </u> </h3>

[[Image:Click_link.JPG|thumb|175px|right|Figure 1 - Accessing WebGoat's HTTPOnly Test Lesson]]

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.

<h3 style=color:#4682B4> <u> Lesson Goal </u> </h3>

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.

<h3 style=color:#4682B4> <u> Testing Web Browsers for HTTPOnly Support </u> </h3>

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.

<h5 style=color:#2E8B57> <u> Disabling HTTPOnly </u> </h5>

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

[[Image:Fig2-Disabling_HTTPOnly.PNG|frame|center|Figure 2 - Disabling HTTPOnly]]

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

[[Image:Fig3-Read_HTTPOnly_Off.PNG|frame|center|Figure 3 - Cookie Successfully Read with HTTPOnly Off]]

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

[[Image:Fig4-Write_HTTPOnly_Off.PNG|frame|center|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.

<h5 style=color:#2E8B57> <u> Enabling HTTPOnly </u> </h5>

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

[[Image:Fig5-Turning_HTTPOnly_On.PNG|frame|center|Figure 5 - Enabling HTTPOnly]]

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

[[Image:Fig6-Cookie_Read_Protection.PNG|frame|center|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'''.

[[Image:Fig7-No_Cookie_Read_Protection.PNG|frame|center|Figure 7 - Unenforced Cookie Read Protection]]

*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'''.

[[Image:Fig6-Cookie_Read_Protection.PNG|frame|center|Figure 8 - Enforced Cookie Write Protection]]

*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'''.

[[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!"]

[2] [http://msdn2.microsoft.com/en-us/library/ms533046.aspx Mitigating Cross-site Scripting with HTTP-Only Cookies]

[3] Howard, Michael. [http://msdn2.microsoft.com/en-us/library/ms972826.aspx Some Bad News and Some Good News]

HttpOnly

2007-07-27T18:19:37Z

Rknell:

== Overview ==

The goal of this section is to introduce, discuss, and discuss language specific mitigation techniques 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. Using the HTTPOnly flag helps 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 or the web site that originally set the cookie. As a result, even if a cross-site scripting '''(XSS)''' flaw exists, and a user accidentally accesses a link that exploits this flaw, 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 cookie will be 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 Mitigating], [http://msdn2.microsoft.com/en-us/library/ms533046.aspx]

<h3 style=color:#4682B4> <u> Mitigating XSS using HTTPOnly </u> </h3>

According to [http://msdn2.microsoft.com/en-us/library/ms972826.aspx Michael Howard], Senior Security Program Manager in the Secure Windows Initiative group at Microsoft, the majority of XSS attacks succeed because a session cookie has been leaked. A server could help mitigate this issue by setting a flag within a ''HTTP response header,'' indicating a session cookie should never be accessed by the client.

If Internet Explorer detects a cookie containing the HttpOnly flag, and client side script code attempts to read the cookie, Internet Explorer ''returns an empty string''. As a result, the attack fails by preventing the malicious XSS code from sending the data to an attacker's website. [http://msdn2.microsoft.com/en-us/library/ms972826.aspx Howard], [http://msdn2.microsoft.com/en-us/library/ms972826.aspx]

<h5 style=color:#2E8B57> <u> Java: Setting HTTPOnly </u> </h5>

*'''Problem'''
**Most environments (e.g., Java EE) do not provide 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

<h5 style=color:#2E8B57> <u> C#.NET: Setting HTTPOnly </u> </h5>

*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
<httpCookies httpOnlyCookies="true" …>

*Or '''programmatically'''
HttpCookie myCookie = 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";

<h5 style=color:#2E8B57> <u> VB.NET: Setting HTTPOnly </u> </h5>

*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
<httpCookies httpOnlyCookies="true" …>

*Or '''programmatically'''
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 capabilities. The results are listed below in '''table 1'''.

{|border="2" width="100%" align="center"
|+ '''Table 1:''' Browsers Supporting HTTPOnly
|-
! style="background:black; color:white" | '''Browser'''
! style="background:black; color:white" | '''Version'''
! style="background:black; color:white" | '''Supports HTTPOnly?'''
|-
| Microsoft Internet Explorer
| align="center" | 6 (SP1) - 7
| align="center" | Partially*
|-
| Mozilla Firefox
| align="center" | 2.0.0.5
| align="center" | Partially*
|-
| Netscape Navigator
| align="center" | 9.0b2
| align="center" | No
|-
| Opera
| align="center" | 9.22
| align="center" | No
|}

<nowiki>*</nowiki> An attacker could still access the session identifier cookie using a '''[http://ha.ckers.org/blog/20070719/firefox-implements-httponly-and-is-vulnerable-to-xmlhttprequest/ 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.

<h3 style=color:#4682B4> <u> Getting Started </u> </h3>

[[Image:Click_link.JPG|thumb|175px|right|Figure 1 - Accessing WebGoat's HTTPOnly Test Lesson]]

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.

<h3 style=color:#4682B4> <u> Lesson Goal </u> </h3>

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.

<h3 style=color:#4682B4> <u> Testing Web Browsers for HTTPOnly Support </u> </h3>

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.

<h5 style=color:#2E8B57> <u> Disabling HTTPOnly </u> </h5>

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

[[Image:Fig2-Disabling_HTTPOnly.PNG|frame|center|Figure 2 - Disabling HTTPOnly]]

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

[[Image:Fig3-Read_HTTPOnly_Off.PNG|frame|center|Figure 3 - Cookie Successfully Read with HTTPOnly Off]]

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

[[Image:Fig4-Write_HTTPOnly_Off.PNG|frame|center|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.

<h5 style=color:#2E8B57> <u> Enabling HTTPOnly </u> </h5>

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

[[Image:Fig5-Turning_HTTPOnly_On.PNG|frame|center|Figure 5 - Enabling HTTPOnly]]

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

[[Image:Fig6-Cookie_Read_Protection.PNG|frame|center|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'''.

[[Image:Fig7-No_Cookie_Read_Protection.PNG|frame|center|Figure 7 - Unenforced Cookie Read Protection]]

*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'''.

[[Image:Fig6-Cookie_Read_Protection.PNG|frame|center|Figure 8 - Enforced Cookie Write Protection]]

*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'''.

[[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!"]

[2] [http://msdn2.microsoft.com/en-us/library/ms533046.aspx Mitigating Cross-site Scripting with HTTP-Only Cookies]

[3] Howard, Michael. [http://msdn2.microsoft.com/en-us/library/ms972826.aspx Some Bad News and Some Good News]

HttpOnly

2007-07-27T18:10:10Z

Rknell: Updated Overview Section: Added Programming Language Specifics for setting HTTPOnly

== Overview ==

The goal of this section is to introduce, discuss, and discuss language specific mitigation techniques 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. Using the HTTPOnly flag helps 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 or the web site that originally set the cookie. As a result, even if a cross-site scripting '''(XSS)''' flaw exists, and a user accidentally accesses a link that exploits this flaw, 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 cookie will be 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 Mitigating], [http://msdn2.microsoft.com/en-us/library/ms533046.aspx]

<h3 style=color:#4682B4> <u> Mitigating XSS using HTTPOnly </u> </h3>

According to [http://msdn2.microsoft.com/en-us/library/ms972826.aspx Michael Howard], Senior Security Program Manager in the Secure Windows Initiative group at Microsoft, the majority of XSS attacks succeed because a session cookie has been leaked. A server could help mitigate this issue by setting a flag within a ''HTTP response header,'' indicating a session cookie should never be accessed by the client.

If Internet Explorer detects a cookie containing the HttpOnly flag, and client side script code attempts to read the cookie, Internet Explorer ''returns an empty string''. As a result, the attack fails by preventing the malicious XSS code from sending the data to an attacker's website. [http://msdn2.microsoft.com/en-us/library/ms972826.aspx Howard], [http://msdn2.microsoft.com/en-us/library/ms972826.aspx]

<h5 style=color:#2E8B57> <u> Java: Setting HTTPOnly </u> </h5>

*'''Problem'''
**Most environments (e.g., Java EE) do not provide 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

<h5 style=color:#2E8B57> <u> C#.NET: Setting HTTPOnly </u> </h5>

*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
<httpCookies httpOnlyCookies="true" …>

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

*However, in .NET 1.1, you’d have to do this manually, e.g.,
Response.Cookies[cookie].Path += ";HTTPOnly";

<h5 style=color:#2E8B57> <u> VB.NET: Setting HTTPOnly </u> </h5>

*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
<httpCookies httpOnlyCookies="true" …>

*Or programmatically
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 capabilities. The results are listed below in '''table 1'''.

{|border="2" width="100%" align="center"
|+ '''Table 1:''' Browsers Supporting HTTPOnly
|-
! style="background:black; color:white" | '''Browser'''
! style="background:black; color:white" | '''Version'''
! style="background:black; color:white" | '''Supports HTTPOnly?'''
|-
| Microsoft Internet Explorer
| align="center" | 6 (SP1) - 7
| align="center" | Partially*
|-
| Mozilla Firefox
| align="center" | 2.0.0.5
| align="center" | Partially*
|-
| Netscape Navigator
| align="center" | 9.0b2
| align="center" | No
|-
| Opera
| align="center" | 9.22
| align="center" | No
|}

<nowiki>*</nowiki> An attacker could still access the session identifier cookie using a '''[http://ha.ckers.org/blog/20070719/firefox-implements-httponly-and-is-vulnerable-to-xmlhttprequest/ 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.

<h3 style=color:#4682B4> <u> Getting Started </u> </h3>

[[Image:Click_link.JPG|thumb|175px|right|Figure 1 - Accessing WebGoat's HTTPOnly Test Lesson]]

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.

<h3 style=color:#4682B4> <u> Lesson Goal </u> </h3>

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.

<h3 style=color:#4682B4> <u> Testing Web Browsers for HTTPOnly Support </u> </h3>

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.

<h5 style=color:#2E8B57> <u> Disabling HTTPOnly </u> </h5>

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

[[Image:Fig2-Disabling_HTTPOnly.PNG|frame|center|Figure 2 - Disabling HTTPOnly]]

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

[[Image:Fig3-Read_HTTPOnly_Off.PNG|frame|center|Figure 3 - Cookie Successfully Read with HTTPOnly Off]]

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

[[Image:Fig4-Write_HTTPOnly_Off.PNG|frame|center|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.

<h5 style=color:#2E8B57> <u> Enabling HTTPOnly </u> </h5>

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

[[Image:Fig5-Turning_HTTPOnly_On.PNG|frame|center|Figure 5 - Enabling HTTPOnly]]

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

[[Image:Fig6-Cookie_Read_Protection.PNG|frame|center|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'''.

[[Image:Fig7-No_Cookie_Read_Protection.PNG|frame|center|Figure 7 - Unenforced Cookie Read Protection]]

*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'''.

[[Image:Fig6-Cookie_Read_Protection.PNG|frame|center|Figure 8 - Enforced Cookie Write Protection]]

*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'''.

[[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!"]

[2] [http://msdn2.microsoft.com/en-us/library/ms533046.aspx Mitigating Cross-site Scripting with HTTP-Only Cookies]

[3] Howard, Michael. [http://msdn2.microsoft.com/en-us/library/ms972826.aspx Some Bad News and Some Good News]

OWASP Stinger 3 Ideas

2007-07-27T17:43:44Z

Rknell: Linked keyword: HTTPOnly

== Overview ==

The OWASP Stinger 3.x series will be heavily driven by the community. Everyone is encouraged to contribute ideas and suggestions to make Stinger 3.x the most powerful and flexible web application firewall as possible. One major goal of the OWASP Stinger 3.x series is to develop a solid and flexible validation engine capable of implementing common web application security features.. With the help of the community, I believe this goal can be achieved!

==Development Complete==

The following is a list of ideas that have been fully implemented in the Stinger 3.x baseline:

:* Validation of the entire HTTP request: including URI, headers, cookies, and parameters
:* A robust "learning" mode to make rule generation simplistic and efficient.
:* A more flexible "Action" framework. Actions will be able to execute logic before and/or after the request is processed by the web application

==Under Development==

The following is a list of ideas currently under development in the Stinger 3.x baseline:

:* The ability to enforce web application firewall logic
::* Defining and enforcing URI level access control
::* Cross Site Request Forgery Guard
::* HTTP Cookie Guard
::* No-Cache Guard
::* 200 Response Codes (fooling web application scanners)
::* Request Rate Throttler
::* Enforce [[HTTPOnly]] on all cookies

==Planning to Develop==

The following is a list of ideas that will be integrated into the Stinger 3.x baseline:

:* A full web application dedicated to editing the OWASP Stinger configuration files

==Ideas Under Consideration==

The following is a list of ideas that are under consideration for the Stinger 3.x baseline:

:* The ability to validate the Java properties files used by the web application
:* The ability to to build rules for and validate rules against serialized objects

If you have an idea that you would like seen in Stinger 3.x, please email me at [mailto:eric.sheridan@owasp.org eric dot sheridan at owasp.org]

Talk:Testing for Cross site scripting

2007-07-27T17:42:08Z

Rknell: Linked keyword: HTTPOnly

(Meucci) NOTE: We can add this recommendations in the OWASP Guide. Are you agree?

The following general recommendations can help mitigate the risk associated with Cross-Site Scripting vulnerabilities. This is a complex problem area

so there is no one simple fix or solution:
* Ensure that your web application validates all forms, headers, cookie fields, hidden fields, and parameters, and converts scripts and script tags

to a non-executable form.
* Ensure that any executables on your server do not return scripts in executable form when passed scripts as malformed command parameters.
* Consider converting JavaScript and HTML tags into alternate HTML encodings (such as “<” to “<>.
* If your site runs online forums or message boards, disallow the use of HTML tags and Scripting in these areas.
* Keep up with the latest security vulnerabilities and bugs for all production applications and servers.
* Update your production servers with the latest XSS vulnerabilities by downloading current patches, and perform frequent security audits on all

deployed applications.
The root cause of Cross-Site Scripting is a failure to filter hazardous characters from web application input and output. The two most critical

programming practices you can institute to guard against Cross-Site Scripting are:
* Validate Input
* Encode output
Always filter data originating from outside your application by disallowing the use of special characters. Only display output to the browser that

has been sufficiently encoded. When possible, avoid simple character filters and write routines that validate user input against a set of allowed,

safe characters. Use regular expressions to confirm that data conforms to the allowed character set. This enhances application security and makes it

harder to bypass input validation routines.
There are different tools you can use to validate and encode your data, depending upon your development environment. Your goal in remediating

Cross-Site Scripting attacks is to filter and encode all potentially dangerous characters so that the application does not return data that the

browser will interpret as executable. Any unescaped or unecoded data that is returned to the browser is a potential security risk.
The following characters can be harmful and should be filtered whenever they appear in the application input or output. In output, you should

translate these characters to their HTML equivalents before returning data to the browser.<BR>
'''> < ( ) [ ] ' " ; : / |'''

<b>PHP</b>
The following PHP functions help mitigate Cross-Site Scripting Vulnerabilities:
* '''Strip_tags()''' removes HTML and PHP scripting tags from a string.
* '''Utf8_decode()''' converts UTF-8 encoding to single byte ASCII characters. Decoding Unicode input prior to filtering it can help you detect

attacks that the attacker has obfuscated with Unicode encoding.
* '''Htmlspecialcharacters()''' turns characters such as '''&,>,<,”''' into their HTML equivalents. Converting special characters to HTML prevents

them from being executed within browsers when outputted by an application.
* '''Strtr()''' filters any characters you specify. Make sure to filter “; : ( )” characters so that attackers cannot craft strings that generate

alerts. Many XSS attacks are possible without the use of HTML characters, so filtering and encoding parentheses mitigates these attacks.<BR>For

example:
'''" style="background:url(JavaScript:alert(Malicious Content));'''

<b>ASP.NET</b>
With ASP.NET, you can use the following functions to help prevent Cross-Site Scripting:
* Constrain input submitted via server controls by using ASP.NET validater controls, such as '''RegularExpressionValidator''', '''RangeValidator''',

and '''System.Text.RegularExpression.Regex'''. Using these methods as server-side controls to limit data input to only allowable character sequences

by validating input type, length, format, and character range.
* Use the '''HtmlUtility.HtmlEncode''' method to encode data if it originates from either a user or from a database. HtmlEncode replaces special

characters with their HTML equivalents, thus preventing the output from being executable in the browser. Use HtmlUtility.UrlEncode when writing URLs

that may have originated from user input or stored database information.
* Use the '''[[HTTPOnly]] cookie''' option for added protection.
* As a best practice, you should use regular expressions to constrain input to known safe characters. Do not rely solely on ASP.NET validateRequest,

but use it in addition to your other input validation and encoding mechanisms.

Kansas City June 2007 Meeting

2007-07-27T17:40:56Z

Rknell: Linked keyword: HTTPOnly

The OWASP [[Kansas City|Kansas City chapter]] meeting in June 2007 was held from 6:30 to 8:30 pm on 6/13/2007. The location of the meeting was at the offices of FishNet Security at 1627 Main Street in Kansas City, MO.

=== Meeting Summary ===

Dave Ferguson of FishNet Security started the meeting with a welcome and overview of OWASP. Attendee Rohini Sulatycki briefly described the new OWASP AJAX project, for which she is the project leader. Next, Dave Ferguson announced that he would be stepping down as the OWASP Kansas City chapter leader due to the fact that he is relocating to the Dallas, TX area. A search for a new chapter leader will begin.

Our first speaker was Jake Reynolds from FishNet Security. Jake described more than a dozen different Firefox extensions that involve some aspect of web application security. Some, such as TamperData and Web Developer, provide useful functionality for auditing/assessing the security of an application. Others, such as [[HTTPOnly]] and NoScript, are specialized extensions that can keep you safer when surfing the Internet.

Following a break, Barry Archer from American Century Investments presented on the topic of web application firewalls. Specifically, Barry talked about his experience with evaluating mod_security for Apache and a particular commercial WAF product. Issues such as negative vs. positive security models, the importance of having a well-designed log format, and how to handle updates to an application were discussed. Barry also explained why you need to understand HTTP in order to properly "tune" a WAF.

=== Documents ===
[[Media:KC_June_2007_Firefox_as_AppSec_Tool.zip|Firefox as a Web Application Security Assessment Tool]] (ppt within a zip)<br/>
[[Media:KC_June_2007_Evaluating_and_Tuning_WAFs.pdf|Evaluating and Tuning Web Application Firewalls]] (pdf)<br/>

Searching for Code in J2EE/Java

2007-07-27T17:39:17Z

Rknell:

== Searching for key indicators ==
The basis of the code review is to locate and analyse areas of code which may have application security implications.
Assuming the code reviewer has a thorough understanding of the code, what it is intended to do and the context upon which it is to be used, firstly one needs to sweep the code base for areas of interest.

This can be done by performing a text search on the code base looking for keywords relating to API's and functions.
Below is a guide for .NET framework 1.1 & 2.0

=== Searching for code in .NET ===

Firstly one needs to be familiar with the tools one can use in order to perform text searching following on from this one need to know what to look for.

In this section we will assume you have a copy of Visual Studio (VS) .NET at hand. VS has two types of search "'''Find in Files'''" and a cmd line tool called '''Findstr'''

The test search tools in XP is not great in my experience and if one has to use this make sure SP2 in installed as it works better.
To start off one should scan thorough the code looking for common patterns or keywords such as "User", "Password", "Pswd", "Key", "Http", etc...
This can be done using the "Find in Files" tool in VS or using findstring as follows:

[Find In Files HERE]

'''findstr /s /m /i /d:c:\projects\codebase\sec "http" *.*'''

====Http Request Strings====
Requests from external sources are onviously a key area of a secure code review. We need to ensure that all HTTP requests received are datavalidated for composition, max and min length and if the data falls with the relms of the parameter whitelist.
Bottom-line is this is a key area to look at and ensure security is enabled.

request.querystring
request.form
request.cookies
request.certificate
request.servervariables
request.IsSecureConnection
request.TotalBytes
request.BinaryRead

====HTML Output====
Here we are looking for responses to the client. Responses which go unvalidated or which echo external input without data validation are key areas to examine. Many client side attacks result from poor response validation. XSS relies on this somewhat.

response.write
<% =
HttpUtility
HtmlEncode
UrlEncode
innerText
innerHTML

====SQL & Database====
Locating where a database may be involved in the code is an important aspect of the code review. Looking at the database code will help determine if the application is vulnerable to SQL injection. One aspect of this is to verify that the code uses either ''SqlParameter'', ''OleDbParameter'', or ''OdbcParameter''(System.Data.SqlClient). These are typed and treats parameters as the literal value and not executable code in the database.

exec sp_executesql
execute sp_executesql
select from
Insert
update
delete from where
delete
exec sp_
execute sp_
exec xp_
execute sp_
exec @
execute @
executestatement
executeSQL
setfilter
executeQuery
GetQueryResultInXML
adodb
sqloledb
sql server
driver
Server.CreateObject
.Provider
.Open
ADODB.recordset
New OleDbConnection
ExecuteReader
DataSource
SqlCommand
Microsoft.Jet
SqlDataReader
ExecuteReader
GetString
SqlDataAdapter
CommandType
StoredProcedure
System.Data.sql

====Cookies====
Cookie manipulation can be key to various application security exploits such as session hijacking/fixation and parameter manipulation. One should examine any code relating to cookie functionality as this would have a bearing on session security.
System.Net.Cookie
[[HTTPOnly]]
document.cookie

==== HTML Tags====
Many of the HTML tags below can be used for client side attacks such as cross site scritping. It is important to examine the context in which these tags are used and to examine any relevant data validation associated with the display and use of such tags withing a web application.

HtmlEncode
URLEncode
<applet>
<frameset>
<embed>
<frame>
<html>
<iframe>
<img>
<style>
<layer>
<ilayer>
<meta>
<object>
<body>
<frame security
<iframe security

====Input Controls====
The input controls below are server classes used to produce and display web application form fields. Looking for such references helps locate entry points into the application.

system.web.ui.htmlcontrols.htmlinputhidden
system.web.ui.webcontrols.textbox
system.web.ui.webcontrols.listbox
system.web.ui.webcontrols.checkboxlist
system.web.ui.webcontrols.dropdownlist

====web.config====
The .NET Framework relies on .config files to define configuration settings. The .config files are text-based XML files. Many .config files can, and typically do, exist on a single system. Web applications refer to a web.config file located in the application’s root directory. For ASP.NET applications, web.config contains information about most aspects of the application’s operation.

requestEncoding
responseEncoding
trace
authorization
CustomErrors
httpRuntime
maxRequestLength
debug
forms protection
appSettings
ConfigurationSettings
authentication mode
allow
deny
credentials
identity impersonate
timeout

====global.asax====
Each application has its own Global.asax if one is required. Global.asax sets the event code and values for an application using scripts. One must ensure that application variables do not contain sensitive information, as they are accessible to the whole application and to all users within it.

Application_OnAuthenticateRequest
Application_OnAuthorizeRequest
Session_OnStart
Session_OnEnd

====logging====
Logging can be a source of information leakage. It is important to examing all calls to the logging subsystem and to determine if any sensitive information is being logged. Common mistakes are logging userID in conjunction with passwords within the authentication functionality or logging database requests which may contains sensitive data.

log4net
Console.WriteLine
System.Diagnostics.Debug
System.Diagnostics.Trace

====Machine.config====
Its important that many variables in machine.config can be overridden in the web.config file for a particular application.
validateRequest
enableViewState
enableViewStateMac

====Threads and Concurrancy====
Locating code that contains multithreaded functions. Concurrancy issues can result in race conditions which may result in security vulnerabilities. The Thread keyword is where new threads objects are created. Code that uses static global variables which hold sensitive security information may cause session issues. Code that uses static constructors may also cause issues between threads. Not synchronizing the Dispose method may cause issues if a number of threads call Dispose at the same time, this may cause resource release issues.

Thread
Dispose

====Class Design====
Public and Sealed relate to the design at class level. Classes whicch are not intended to be derived from should be sealed. Make sure all class fields are Public for a reason. Dont expose anything you dont need to.

Public
Sealed

====Reflection, Serialization====
Code may be generated dynamically at runtime. Code that is generated dynamically as a function of external input may give rise to issues. If your code contains sensitive data does it need to be serialized.

Serializable
AllowPartiallyTrustedCallersAttribute
GetObjectData
StrongNameIdentityPermission
StrongNameIdentity
System.Reflection

====Exceptions & Errors====
Ensure that the catch blocks do not leak information to the user in the case of an exception. Ensure when dealing with resources that the finally block is used. Having trace enabled is not great from an information leakage perspective. Ensure custonised errors are properly implemented.

catch{
Finally
trace enabled
customErrors mode

====Crypto====
If cryptography is used then is a strong enough cipher used i.e. AES or 3DES. What size key is used, the larger the better. Where is hashing performed. Are passwords that are being persisted hashed, they should be.
How are random numbers generated? Is the PRNG "random enough"?

RNGCryptoServiceProvider
SHA
MD5
base64
xor
DES
RC2
System.Random
Random
System.Security.Cryptography

====Storage====
If storing sensitive data in memory recommend one uses the following.
SecureString
ProtectedMemory

====Authorization, Assert & Revert====
Bypassing the code access security permission? Not a good idea. Also below is a list of potentially dangerous permissions such as calling unmanaged code, outside the CLR.

.RequestMinimum
.RequestOptional
Assert
Debug.Assert
CodeAccessPermission
ReflectionPermission.MemberAccess
SecurityPermission.ControlAppDomain
SecurityPermission.UnmanagedCode
SecurityPermission.SkipVerification
SecurityPermission.ControlEvidence
SecurityPermission.SerializationFormatter
SecurityPermission.ControlPrincipal
SecurityPermission.ControlDomainPolicy
SecurityPermission.ControlPolicy

====Leagcy methods====
printf
strcpy

=== Searching for code in J2EE/Java ===

====Input Streams====
Java.io
FileInputStream
ObjectInputStream
FilterInputStream
PipedInputStream
SequenceInputStream
StringBufferInputStream
BufferedReader
ByteArrayInputStream
CharArrayReader
File
ObjectInputStream
PipedInputStream
StreamTokenizer
getResourceAsStream

====Servlets====
javax.servlet.
getParameterNames
getParameterValues
getAttribute
getAttributeNames
isSecure
HttpServletRequest
getQueryString
getHeader
getPrincipal
isUserInRole
getOutputStream
getWriter
addCookie
addHeader
setHeader

====SQL & Database====
Searching for Java Database related code this list should help you pinpoint classes/methods which are involved in the persistance layer of the application being reviewed.
jdbc
executeQuery
select
insert
update
delete
execute
executestatement
====SSL====
com.sun.net.ssl
SSLContext
SSLSocketFactory
TrustManagerFactory
HttpsURLConnection
KeyManagerFactory

====Session Management====
getSession
invalidate
getId

====Data Validation====

====Legacy Interaction====

====Crypto====

====Security Manager====

====System====

====Logging====

====Architectural Analysis====
If we can identify major architectural components within that application (right away) it can help narrow our search, and we can then look for known vulnerabilities in those components and frameworks:

### Ajax
XMLHTTP
### Struts
org.apache.struts
### Spring
org.springframework
### Java Server Faces (JSF)
import javax.faces
### Hibernate
import org.hibernate
### Castor
org.exolab.castor
### JAXB
javax.xml
### JMS
JMS

===Generic keywords===
Developers say the darnedest things in their source code. Look for the following keywords as pointers to possible software vulnerabilities:

Hack
Kludge
Bypass
Steal
Stolen
Divert
Broke
Trick
Fix
ToDo

===Web 2.0===

====Ajax and JavaScript====
Look for Ajax usage, and possible JavaScript issues:

document.write
eval(
document.cookie
window.location
document.URL
XMLHTTP
window.createRequest

Searching for Code in J2EE/Java

2007-07-27T17:38:57Z

Rknell: Linked keyword HTTPOnly

== Searching for key indicators ==
The basis of the code review is to locate and analyse areas of code which may have application security implications.
Assuming the code reviewer has a thorough understanding of the code, what it is intended to do and the context upon which it is to be used, firstly one needs to sweep the code base for areas of interest.

This can be done by performing a text search on the code base looking for keywords relating to API's and functions.
Below is a guide for .NET framework 1.1 & 2.0

=== Searching for code in .NET ===

Firstly one needs to be familiar with the tools one can use in order to perform text searching following on from this one need to know what to look for.

In this section we will assume you have a copy of Visual Studio (VS) .NET at hand. VS has two types of search "'''Find in Files'''" and a cmd line tool called '''Findstr'''

The test search tools in XP is not great in my experience and if one has to use this make sure SP2 in installed as it works better.
To start off one should scan thorough the code looking for common patterns or keywords such as "User", "Password", "Pswd", "Key", "Http", etc...
This can be done using the "Find in Files" tool in VS or using findstring as follows:

[Find In Files HERE]

'''findstr /s /m /i /d:c:\projects\codebase\sec "http" *.*'''

====Http Request Strings====
Requests from external sources are onviously a key area of a secure code review. We need to ensure that all HTTP requests received are datavalidated for composition, max and min length and if the data falls with the relms of the parameter whitelist.
Bottom-line is this is a key area to look at and ensure security is enabled.

request.querystring
request.form
request.cookies
request.certificate
request.servervariables
request.IsSecureConnection
request.TotalBytes
request.BinaryRead

====HTML Output====
Here we are looking for responses to the client. Responses which go unvalidated or which echo external input without data validation are key areas to examine. Many client side attacks result from poor response validation. XSS relies on this somewhat.

response.write
<% =
HttpUtility
HtmlEncode
UrlEncode
innerText
innerHTML

====SQL & Database====
Locating where a database may be involved in the code is an important aspect of the code review. Looking at the database code will help determine if the application is vulnerable to SQL injection. One aspect of this is to verify that the code uses either ''SqlParameter'', ''OleDbParameter'', or ''OdbcParameter''(System.Data.SqlClient). These are typed and treats parameters as the literal value and not executable code in the database.

exec sp_executesql
execute sp_executesql
select from
Insert
update
delete from where
delete
exec sp_
execute sp_
exec xp_
execute sp_
exec @
execute @
executestatement
executeSQL
setfilter
executeQuery
GetQueryResultInXML
adodb
sqloledb
sql server
driver
Server.CreateObject
.Provider
.Open
ADODB.recordset
New OleDbConnection
ExecuteReader
DataSource
SqlCommand
Microsoft.Jet
SqlDataReader
ExecuteReader
GetString
SqlDataAdapter
CommandType
StoredProcedure
System.Data.sql

====Cookies====
Cookie manipulation can be key to various application security exploits such as session hijacking/fixation and parameter manipulation. One should examine any code relating to cookie functionality as this would have a bearing on session security.
System.Net.Cookie
[[HttpOnly]]
document.cookie

==== HTML Tags====
Many of the HTML tags below can be used for client side attacks such as cross site scritping. It is important to examine the context in which these tags are used and to examine any relevant data validation associated with the display and use of such tags withing a web application.

HtmlEncode
URLEncode
<applet>
<frameset>
<embed>
<frame>
<html>
<iframe>
<img>
<style>
<layer>
<ilayer>
<meta>
<object>
<body>
<frame security
<iframe security

====Input Controls====
The input controls below are server classes used to produce and display web application form fields. Looking for such references helps locate entry points into the application.

system.web.ui.htmlcontrols.htmlinputhidden
system.web.ui.webcontrols.textbox
system.web.ui.webcontrols.listbox
system.web.ui.webcontrols.checkboxlist
system.web.ui.webcontrols.dropdownlist

====web.config====
The .NET Framework relies on .config files to define configuration settings. The .config files are text-based XML files. Many .config files can, and typically do, exist on a single system. Web applications refer to a web.config file located in the application’s root directory. For ASP.NET applications, web.config contains information about most aspects of the application’s operation.

requestEncoding
responseEncoding
trace
authorization
CustomErrors
httpRuntime
maxRequestLength
debug
forms protection
appSettings
ConfigurationSettings
authentication mode
allow
deny
credentials
identity impersonate
timeout

====global.asax====
Each application has its own Global.asax if one is required. Global.asax sets the event code and values for an application using scripts. One must ensure that application variables do not contain sensitive information, as they are accessible to the whole application and to all users within it.

Application_OnAuthenticateRequest
Application_OnAuthorizeRequest
Session_OnStart
Session_OnEnd

====logging====
Logging can be a source of information leakage. It is important to examing all calls to the logging subsystem and to determine if any sensitive information is being logged. Common mistakes are logging userID in conjunction with passwords within the authentication functionality or logging database requests which may contains sensitive data.

log4net
Console.WriteLine
System.Diagnostics.Debug
System.Diagnostics.Trace

====Machine.config====
Its important that many variables in machine.config can be overridden in the web.config file for a particular application.
validateRequest
enableViewState
enableViewStateMac

====Threads and Concurrancy====
Locating code that contains multithreaded functions. Concurrancy issues can result in race conditions which may result in security vulnerabilities. The Thread keyword is where new threads objects are created. Code that uses static global variables which hold sensitive security information may cause session issues. Code that uses static constructors may also cause issues between threads. Not synchronizing the Dispose method may cause issues if a number of threads call Dispose at the same time, this may cause resource release issues.

Thread
Dispose

====Class Design====
Public and Sealed relate to the design at class level. Classes whicch are not intended to be derived from should be sealed. Make sure all class fields are Public for a reason. Dont expose anything you dont need to.

Public
Sealed

====Reflection, Serialization====
Code may be generated dynamically at runtime. Code that is generated dynamically as a function of external input may give rise to issues. If your code contains sensitive data does it need to be serialized.

Serializable
AllowPartiallyTrustedCallersAttribute
GetObjectData
StrongNameIdentityPermission
StrongNameIdentity
System.Reflection

====Exceptions & Errors====
Ensure that the catch blocks do not leak information to the user in the case of an exception. Ensure when dealing with resources that the finally block is used. Having trace enabled is not great from an information leakage perspective. Ensure custonised errors are properly implemented.

catch{
Finally
trace enabled
customErrors mode

====Crypto====
If cryptography is used then is a strong enough cipher used i.e. AES or 3DES. What size key is used, the larger the better. Where is hashing performed. Are passwords that are being persisted hashed, they should be.
How are random numbers generated? Is the PRNG "random enough"?

RNGCryptoServiceProvider
SHA
MD5
base64
xor
DES
RC2
System.Random
Random
System.Security.Cryptography

====Storage====
If storing sensitive data in memory recommend one uses the following.
SecureString
ProtectedMemory

====Authorization, Assert & Revert====
Bypassing the code access security permission? Not a good idea. Also below is a list of potentially dangerous permissions such as calling unmanaged code, outside the CLR.

.RequestMinimum
.RequestOptional
Assert
Debug.Assert
CodeAccessPermission
ReflectionPermission.MemberAccess
SecurityPermission.ControlAppDomain
SecurityPermission.UnmanagedCode
SecurityPermission.SkipVerification
SecurityPermission.ControlEvidence
SecurityPermission.SerializationFormatter
SecurityPermission.ControlPrincipal
SecurityPermission.ControlDomainPolicy
SecurityPermission.ControlPolicy

====Leagcy methods====
printf
strcpy

=== Searching for code in J2EE/Java ===

====Input Streams====
Java.io
FileInputStream
ObjectInputStream
FilterInputStream
PipedInputStream
SequenceInputStream
StringBufferInputStream
BufferedReader
ByteArrayInputStream
CharArrayReader
File
ObjectInputStream
PipedInputStream
StreamTokenizer
getResourceAsStream

====Servlets====
javax.servlet.
getParameterNames
getParameterValues
getAttribute
getAttributeNames
isSecure
HttpServletRequest
getQueryString
getHeader
getPrincipal
isUserInRole
getOutputStream
getWriter
addCookie
addHeader
setHeader

====SQL & Database====
Searching for Java Database related code this list should help you pinpoint classes/methods which are involved in the persistance layer of the application being reviewed.
jdbc
executeQuery
select
insert
update
delete
execute
executestatement
====SSL====
com.sun.net.ssl
SSLContext
SSLSocketFactory
TrustManagerFactory
HttpsURLConnection
KeyManagerFactory

====Session Management====
getSession
invalidate
getId

====Data Validation====

====Legacy Interaction====

====Crypto====

====Security Manager====

====System====

====Logging====

====Architectural Analysis====
If we can identify major architectural components within that application (right away) it can help narrow our search, and we can then look for known vulnerabilities in those components and frameworks:

### Ajax
XMLHTTP
### Struts
org.apache.struts
### Spring
org.springframework
### Java Server Faces (JSF)
import javax.faces
### Hibernate
import org.hibernate
### Castor
org.exolab.castor
### JAXB
javax.xml
### JMS
JMS

===Generic keywords===
Developers say the darnedest things in their source code. Look for the following keywords as pointers to possible software vulnerabilities:

Hack
Kludge
Bypass
Steal
Stolen
Divert
Broke
Trick
Fix
ToDo

===Web 2.0===

====Ajax and JavaScript====
Look for Ajax usage, and possible JavaScript issues:

document.write
eval(
document.cookie
window.location
document.URL
XMLHTTP
window.createRequest

Lesson Plans

2007-07-27T17:37:39Z

Rknell: Linked keyword: HTTPOnly

[[WebGoat User Guide Table of Contents]]
__TOC__

The lesson plans included WebGoat 5.0 (1/31/07) include:
{| border=1
|-
|| General || HTTP Basics
|-
|| || HTTP Splitting and Cache Poisining
|-
|| || How to Exploit Thread Safety Problems
|-
|| || How to add a new WebGoat lesson
|-
|| Code Quality || How to Discover Clues in the HTML
|-
|| Unvalidated Parameters || How to Exploit Hidden Fields
|-
|| || How to Exploit Unchecked Email
|-
|| || How to Bypass Client Side JavaScript Validation
|-
|| Broken Access Control || Using an Access Control Matrix
|-
|| || How to Bypass a Path Based Access Control Scheme
|-
|| || How to Perform Cross Site Request Forgery (CSRF)
|-
|| || LAB: Role based Access Control
|-
|| || Remote Admin Access
|-
|| Broken Authentication || Forgot Password
|-
|| || How to Spoof an Authentication Cookie
|-
|| || How to Hijack a Session
|-
|| || Basic Authentication
|-
|| Cross Site Scripting (Xss) || LAB: Cross Site Scripting
|-
|| || How to Perform Stored Cross Site Scripting (XSS)
|-
|| || How to Perform Reflected Cross Site Scripting (XSS)
|-
|| || [[HTTPOnly]] Test
|-
|| || How to Perform Cross Site Tracing (XST) Attacks
|-
|| Buffer Overflows || Buffer Overflow
|-
|| Injection Flaws || How to Perform Command Injection
|-
|| || How to Perform Blind SQL Injection
|-
|| || How to Perform Numeric SQL Injection
|-
|| || How to Perform Log Spoofing
|-
|| || How to Perform XPATH Injection
|-
|| || How to Perform String SQL Injection
|-
|| || LAB: SQL Injection
|-
|| || How to Use Database Backdoors
|-
|| Improper Error Handling || How to Bypass a Fail Open Authentication Scheme
|-
|| Insecure Storage || Encoding Basics
|-
|| Denial of Service || Denial of Service From Multiple Logins
|-
|| Insecure Configuration Management || Forced Browsing
|-
|| Web Services || How to Create a SOAP Request
|-
|| || WSDL Scanning
|-
|| || Web Service SAX Injection
|-
|| || Web Service SQL Injection
|-
|| AJAX Security || DOM Injection
|-
|| || XML Injection
|-
|| || JSON Injection
|-
|| || Silent Transactions Attacks
|-
|| Challenge || The Challenge
|-

|-
|}

For each lesson within WebGoat, an overview and objectives are provided. These are accessed through the ''Show Lesson Plan'' button.

[[Image:WebGoat Show Lesson Plan.gif|Figure 3: Show Lesson Plan]]

These lesson plans describe the operation of each aspect of the target application, the areas of interest relating to the security assessment and the type of attack that should be attempted.

[[WebGoat User Guide Table of Contents]]
[[Category:OWASP WebGoat Project]]

WebGoat User Guide Introduction

2007-07-27T17:36:03Z

Rknell: Linked keyword: HTTPOnly

[[WebGoat User and Install Guide Table of Contents]]

==Overview ==
The WebGoatv5 application is designed to illustrate typical security flaws within web-applications. It is intended to teach a structured approach to testing for, and exploiting such vulnerabilities within the context of an Application Security Assessment.

A full Application Security Assessment testing methodology is being documented by <u>http://www.owasp.org/index.php/OWASP_Testing_Project</u> and this will provide a superset of the issues demonstrated within the WebGoat. If may include a formal design and code review, for example. The WebGoat lessons aim to give practical training and examples relating to the ''Implementation'' ''Review'' phase of the OWASP Web Application Security Testing Methodology.

The WebGoatv5 Application provides a testing platform for a typical application security assessment. The assessor is given the same information and rights as a typical customer or client of an on-line application.
* The application is web based
* The attack simulations are remote
All of the described techniques may be performed from any connected location.
* The testing is black-box
Source code is not supplied, but it can be viewed and downloaded.
* Credentials and operational information is provided

Of course, the teaching aspect of WebGoat means that certain information will be revealed that would not typically be available. This makes it possible to guide the tester through an assessment process.

The current lesson plans provided in WebGoatv5 include:

{| border=1
|| HTTP Basics
|-
|| HTTP Splitting and Cache Poisining
|-
|| How to Exploit Thread Safety Problems
|-
|| How to Discover Clues in the HTML
|-
|| How to Exploit Hidden Fields
|-
|| How to Exploit Unchecked Email
|-
|| How to Bypass Client Side JavaScript Validation
|-
|| How to Force Browser Web Resources
|-
|| How to Bypass a Role Based Access Control Scheme
|-
|| How to Bypass a Path Based Access Control Scheme
|-
|| LAB: Role based Access Control
|-
|| Using an Access Control Matrix
|-
|| How to Exploit the Forgot Password Page
|-
|| How to Spoof an Authentication Cookie
|-
|| How to Hijack a Session
|-
|| Basic Authentication
|-
|| LAB: Cross Site Scripting
|-
|| How to Perform Stored Cross Site Scripting (XSS)
|-
|| How to Perform Reflected Cross Site Scripting (XSS)
|-
|| How to Perform Cross Site Trace Attacks (XSS)
|-
|| Buffer Overflow (TBD)
|-
|| [[HTTPOnly]] Test
|-
|| How to Perform Command Injection
|-
|| How to Perform Parameter Injection
|-
|| How to Perform Blind SQL Injection
|-
|| How to Perform Numeric SQL Injection
|-
|| How to Perform String SQL Injection
|-
|| How to Perform Log Spoofing
|-
|| How to Perform XPATH Injection Attacks
|-
|| LAB: SQL Injection
|-
|| How to Bypass a Fail Open Authentication Scheme
|-
|| How to Peform Basic Encoding
|-
|| Denial of Service from Multiple Logins
|-
|| How to Create a SOAP Request
|-
|| How to Perform WSDL Scanning
|-
|| How to Perform Web Service SAX Injection
|-
|| How to Perform Web Service SQL Injection
|-
|| How to Perform DOM Injection Attack
|-
|| How to Perform XML Injection Attacks
|-
|| How to Perform JSON Injection Attack
|-
|| How to Perform Silent Transactions Attacks
|-
|| How to Add a New Lesson
|-
|| The Challenge
|-
|}

Future releases of WebGoat will include more lessons and functionality. Should you have any suggestions for improvement or new lessons please contact [mailto:bill@owasp.org bill@owasp.org] with your ideas.

[[WebGoat User and Install Guide Table of Contents]]

[[Category:OWASP WebGoat Project]]

Testing for Session Management Schema (OTG-SESS-001)

2007-07-27T17:32:30Z

Rknell:

[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]]<br>
{{Template:OWASP Testing Guide v2}}

== Brief Summary ==
In order to avoid continuous authentication for each page of a website or service, web applications implement various mechanisms to store and validate credentials for a pre-determined timespan.<br><br>
These mechanisms are known as Session Management and while they're most important in order to increase the ease of use and user-friendliness of the application, they can be exploited by a pen tester to gain access to a user account without the need to provide correct credentials.
<br>

== Description of the Issue ==
The session management schema should be considered alongside the authentication and authorization schema, and cover at least the questions below from a non-technical point of view:
* Will the application be accessed from shared systems? e.g. Internet Café <br>
* Is application security of prime concern to the visiting client/customer? <br>
* How many concurrent sessions may a user have? <br>
* How long is the inactive timeout on the application?<br>
* How long is the active timeout? <br>
* Are sessions transferable from one source IP to another? <br>
* Is ‘remember my username’ functionality provided? <br>
* Is ‘automatic login’ functionality provided? <br>
Having identified the schema in place, the application and its logic must be examined to ensure the proper implementation of the schema.
This phase of testing is intrinsically linked with general application security testing. Whilst the first Schema questions (is the schema suitable for the site and does the schema meet the application provider’s requirements?) can be analysed in abstract, the final question (does the site implement the specified schema?) must be considered alongside other technical testing. <br>

The identified schema should be analyzed against best practice within the context of the site during our penetration test.
Where the defined schema deviates from security best practice, the associated risks should be identified and described within the context of the environment. Security risks and issues should be detailed and quantified, but ultimately the application provider must make decisions based on the security and usability of the application.
For example, if it is determined that the site has been designed without inactive session timeouts, the application provider should be advised about risks such as replay attacks, long-term attacks based on stolen or compromised Session IDs, and abuse of a shared terminal where the application was not logged out. They must then consider these against other requirements such as convenience of use for clients and disruption of the application by forced re-authentication.
<br>
''' Session Management Implementation'''<br>
In this Chapter we describe how to analyse a Session Schema and how to test it. Technical security testing of Session Management implementation covers two key areas:
* Integrity of Session ID creation
* Secure management of active sessions and Session IDs
The Session ID should be sufficiently unpredictable and abstracted from any private information, and the Session management should be logically secured to prevent any manipulation or circumvention of application security.
These two key areas are interdependent, but should be considered separately for a number of reasons.
Firstly, the choice of underlying technology to provide the sessions is bewildering and can already include a large number of OTS products and an almost unlimited number of bespoke or proprietary implementations. Whilst the same technical analysis must be performed on each, established vendor solutions may require a slightly different testing approach, and existing security research may exist on the implementation.
Secondly, even an unpredictable and abstract Session ID may be rendered completely ineffectual should the Session management be flawed. Similarly, a strong and secure session management implementation may be undermined by a poor Session ID implementation.
Furthermore, the analyst should closely examine how (and if) the application uses the available Session management. It is not uncommon to see Microsoft ISS server ASP Session IDs passed religiously back and forth during interaction with an application, only to discover that these are not used by the application logic at all. It is therefore not correct to say that because an application is built on a ‘proven secure’ platform its Session Management is automatically secure.

== Black Box testing and example ==

''' Session Analysis'''<br>

The Session Tokens (Cookie, SessionID or Hidden Field) themselves should be examined to ensure their quality from a security perspective. They should be tested against criteria such as their randomness, uniqueness, resistance to statistical and cryptographic analysis and information leakage.<br>
* Token Structure & Information Leakage
The first stage is to examine the structure and content of a Session ID provided by the application. A common mistake is to include specific data in the Token instead of issuing a generic value and referencing real data at the server side.
If the Session ID is clear-text, the structure and pertinent data may be immediately obvious as the following:
<pre>
192.168.100.1:owaspuser:password:15:58
</pre>

If part or the entire Token appears to be encoded or hashed, it should be compared to various techniques to check for obvious obfuscation.
For example the string “192.168.100.1:owaspuser:password:15:58” is represented in Hex, Base64 and as an MD5 hash:
<pre>
Hex 3139322E3136382E3130302E313A6F77617370757365723A70617373776F72643A31353A3538
Base64 MTkyLjE2OC4xMDAuMTpvd2FzcHVzZXI6cGFzc3dvcmQ6MTU6NTg=
MD5 01c2fc4f0a817afd8366689bd29dd40a
</pre>

Having identified the type of obfuscation, it may be possible to decode back to the original data. In most cases, however, this is unlikely. Even so, it may be useful to enumerate the encoding in place from the format of the message. Furthermore, if both the format and obfuscation technique can be deduced, automated brute-force attacks could be devised.
Hybrid tokens may include information such as IP address or User ID together with an encoded portion, as the following:
<pre>
owaspuser:192.168.100.1: a7656fafe94dae72b1e1487670148412
</pre>

Having analysed a single Session Token, the representative sample should be examined.
A simple analysis of the Tokens should immediately reveal any obvious patterns. For example, a 32 bit Token may include 16 bits of static data and 16 bits of variable data. This may indicate that the first 16 bits represent a fixed attribute of the user – e.g. the username or IP address.
If the second 16 bit chunk is incrementing at a regular rate, it may indicate a sequential or even time-based element to the Token generation. See Examples.
If static elements to the Tokens are identified, further samples should be gathered, varying one potential input element at a time. For example, login attempts through a different user account or from a different IP address may yield a variance in the previously static portion of the Session Token.
The following areas should be addressed during the single and multiple Session ID structure testing:
* What parts of the Session ID are static?
* What clear-text proprietary information is stored in the Session ID?
e.g. usernames/UID, IP addresses
* What easily decoded proprietary information is stored?
* What information can be deduced from the structure of the Session ID?
* What portions of the Session ID are static for the same login conditions?
* What obvious patterns are present in the Session ID as a whole, or individual portions?

'''Session ID Predictability and Randomness'''<br>
Analysis of the variable areas (if any) of the Session ID should be undertaken to establish the existence of any recognizable or predictable patterns.
These analysis may be performed manually and with bespoke or OTS statistical or cryptanalytic tools in order to deduce any patterns in Session ID content.
Manual checks should include comparisons of Session IDs issued for the same login conditions – e.g. the same username, password and IP address. Time is an important factor which must also be controlled. High numbers of simultaneous connections should be made in order to gather samples in the same time window and keep that variable constant. Even a quantization of 50ms or less may be too coarse and a sample taken in this way may reveal time-based components that would otherwise be missed.
Variable elements should be analysed over time to determine whether they are incremental in nature. Where they are incremental, patterns relating to absolute or elapsed time should be investigated. Many systems use time as a seed for their pseudo random elements.
Where the patterns are seemingly random, one-way hashes of time or other environmental variations should be considered as a possibility. Typically, the result of a cryptographic hash is a decimal or hexadecimal number so should be identifiable.
In analysing Session IDs sequences, patterns or cycles, static elements and client dependencies should all be considered as possible contributing elements to the structure and function of the application.
* Are the Session IDs provably random in nature? e.g. Can the result be reproduced?
* Do the same input conditions produce the same ID on a subsequent run?
* Are the Session IDs provably resistant to statistical or cryptanalysis?
* What elements of the Session IDs are time-linked?
* What portions of the Session IDs are predictable?
* Can the next ID be deduced even given full knowledge of the generation algorithm and previous IDs?

'''Brute Force Attacks'''<br>
Brute force attacks inevitably lead on from questions relating to predictability and randomness.
The variance within the Session IDs must be considered together with application session durations and timeouts. If the variation within the Session IDs is relatively small, and Session ID validity is long, the likelihood of a successful brute-force attack is much higher.
A long session ID (or rather one with a great deal of variance) and a shorter validity period would make it far harder to succeed in a brute force attack.
* How long would a brute-force attack on all possible Session IDs take?
* Is the Session ID space large enough to prevent brute forcing? e.g. is the length of the key sufficient when compared to the valid life-span
* Do delays between connection attempts with different Session IDs mitigate the risk of this attack?

== Gray Box testing and example ==
If you can access to session management schema implementation, you can check for the following:
* Random Session Token
The sessionID or Cookie issued to the client should not be easily predictable (don't use linear algorithm based on predictable variables or client IPArddr). The use of cryptographic algorithms with key lenght of 256 bits is encouraged (like AES).
* Token length
SessionID will be at least 50 characters length.
* Session Time-out
Session token should have a defined time-out (it depends on the criticality of the application managed data)
* Cookie configuration
** non-persistent: only RAM memory
** secure (set only on HTTPS channel): Set Cookie: cookie=data; path=/; domain=.aaa.it; secure
** [[HTTPOnly]] (not readable by a script): Set Cookie: cookie=data; path=/; domain=.aaa.it; [[HTTPOnly]]

== References ==
'''Whitepapers'''<br>
* Gunter Ollmann: "Web Based Session Management" - http://www.technicalinfo.net
* RFCs 2109 & 2965: "HTTP State Management Mechanism" - http://www.ietf.org/rfc/rfc2965.txt, http://www.ietf.org/rfc/rfc2109.txt
* RFC 2616: "Hypertext Transfer Protocol -- HTTP/1.1" - http://www.ietf.org/rfc/rfc2616.txt

<br>

{{Category:OWASP Testing Project AoC}}

Testing for Session Management Schema (OTG-SESS-001)

2007-07-27T17:31:55Z

Rknell: Linked keyword HTTPOnly

[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]]<br>
{{Template:OWASP Testing Guide v2}}

== Brief Summary ==
In order to avoid continuous authentication for each page of a website or service, web applications implement various mechanisms to store and validate credentials for a pre-determined timespan.<br><br>
These mechanisms are known as Session Management and while they're most important in order to increase the ease of use and user-friendliness of the application, they can be exploited by a pen tester to gain access to a user account without the need to provide correct credentials.
<br>

== Description of the Issue ==
The session management schema should be considered alongside the authentication and authorization schema, and cover at least the questions below from a non-technical point of view:
* Will the application be accessed from shared systems? e.g. Internet Café <br>
* Is application security of prime concern to the visiting client/customer? <br>
* How many concurrent sessions may a user have? <br>
* How long is the inactive timeout on the application?<br>
* How long is the active timeout? <br>
* Are sessions transferable from one source IP to another? <br>
* Is ‘remember my username’ functionality provided? <br>
* Is ‘automatic login’ functionality provided? <br>
Having identified the schema in place, the application and its logic must be examined to ensure the proper implementation of the schema.
This phase of testing is intrinsically linked with general application security testing. Whilst the first Schema questions (is the schema suitable for the site and does the schema meet the application provider’s requirements?) can be analysed in abstract, the final question (does the site implement the specified schema?) must be considered alongside other technical testing. <br>

The identified schema should be analyzed against best practice within the context of the site during our penetration test.
Where the defined schema deviates from security best practice, the associated risks should be identified and described within the context of the environment. Security risks and issues should be detailed and quantified, but ultimately the application provider must make decisions based on the security and usability of the application.
For example, if it is determined that the site has been designed without inactive session timeouts, the application provider should be advised about risks such as replay attacks, long-term attacks based on stolen or compromised Session IDs, and abuse of a shared terminal where the application was not logged out. They must then consider these against other requirements such as convenience of use for clients and disruption of the application by forced re-authentication.
<br>
''' Session Management Implementation'''<br>
In this Chapter we describe how to analyse a Session Schema and how to test it. Technical security testing of Session Management implementation covers two key areas:
* Integrity of Session ID creation
* Secure management of active sessions and Session IDs
The Session ID should be sufficiently unpredictable and abstracted from any private information, and the Session management should be logically secured to prevent any manipulation or circumvention of application security.
These two key areas are interdependent, but should be considered separately for a number of reasons.
Firstly, the choice of underlying technology to provide the sessions is bewildering and can already include a large number of OTS products and an almost unlimited number of bespoke or proprietary implementations. Whilst the same technical analysis must be performed on each, established vendor solutions may require a slightly different testing approach, and existing security research may exist on the implementation.
Secondly, even an unpredictable and abstract Session ID may be rendered completely ineffectual should the Session management be flawed. Similarly, a strong and secure session management implementation may be undermined by a poor Session ID implementation.
Furthermore, the analyst should closely examine how (and if) the application uses the available Session management. It is not uncommon to see Microsoft ISS server ASP Session IDs passed religiously back and forth during interaction with an application, only to discover that these are not used by the application logic at all. It is therefore not correct to say that because an application is built on a ‘proven secure’ platform its Session Management is automatically secure.

== Black Box testing and example ==

''' Session Analysis'''<br>

The Session Tokens (Cookie, SessionID or Hidden Field) themselves should be examined to ensure their quality from a security perspective. They should be tested against criteria such as their randomness, uniqueness, resistance to statistical and cryptographic analysis and information leakage.<br>
* Token Structure & Information Leakage
The first stage is to examine the structure and content of a Session ID provided by the application. A common mistake is to include specific data in the Token instead of issuing a generic value and referencing real data at the server side.
If the Session ID is clear-text, the structure and pertinent data may be immediately obvious as the following:
<pre>
192.168.100.1:owaspuser:password:15:58
</pre>

If part or the entire Token appears to be encoded or hashed, it should be compared to various techniques to check for obvious obfuscation.
For example the string “192.168.100.1:owaspuser:password:15:58” is represented in Hex, Base64 and as an MD5 hash:
<pre>
Hex 3139322E3136382E3130302E313A6F77617370757365723A70617373776F72643A31353A3538
Base64 MTkyLjE2OC4xMDAuMTpvd2FzcHVzZXI6cGFzc3dvcmQ6MTU6NTg=
MD5 01c2fc4f0a817afd8366689bd29dd40a
</pre>

Having identified the type of obfuscation, it may be possible to decode back to the original data. In most cases, however, this is unlikely. Even so, it may be useful to enumerate the encoding in place from the format of the message. Furthermore, if both the format and obfuscation technique can be deduced, automated brute-force attacks could be devised.
Hybrid tokens may include information such as IP address or User ID together with an encoded portion, as the following:
<pre>
owaspuser:192.168.100.1: a7656fafe94dae72b1e1487670148412
</pre>

Having analysed a single Session Token, the representative sample should be examined.
A simple analysis of the Tokens should immediately reveal any obvious patterns. For example, a 32 bit Token may include 16 bits of static data and 16 bits of variable data. This may indicate that the first 16 bits represent a fixed attribute of the user – e.g. the username or IP address.
If the second 16 bit chunk is incrementing at a regular rate, it may indicate a sequential or even time-based element to the Token generation. See Examples.
If static elements to the Tokens are identified, further samples should be gathered, varying one potential input element at a time. For example, login attempts through a different user account or from a different IP address may yield a variance in the previously static portion of the Session Token.
The following areas should be addressed during the single and multiple Session ID structure testing:
* What parts of the Session ID are static?
* What clear-text proprietary information is stored in the Session ID?
e.g. usernames/UID, IP addresses
* What easily decoded proprietary information is stored?
* What information can be deduced from the structure of the Session ID?
* What portions of the Session ID are static for the same login conditions?
* What obvious patterns are present in the Session ID as a whole, or individual portions?

'''Session ID Predictability and Randomness'''<br>
Analysis of the variable areas (if any) of the Session ID should be undertaken to establish the existence of any recognizable or predictable patterns.
These analysis may be performed manually and with bespoke or OTS statistical or cryptanalytic tools in order to deduce any patterns in Session ID content.
Manual checks should include comparisons of Session IDs issued for the same login conditions – e.g. the same username, password and IP address. Time is an important factor which must also be controlled. High numbers of simultaneous connections should be made in order to gather samples in the same time window and keep that variable constant. Even a quantization of 50ms or less may be too coarse and a sample taken in this way may reveal time-based components that would otherwise be missed.
Variable elements should be analysed over time to determine whether they are incremental in nature. Where they are incremental, patterns relating to absolute or elapsed time should be investigated. Many systems use time as a seed for their pseudo random elements.
Where the patterns are seemingly random, one-way hashes of time or other environmental variations should be considered as a possibility. Typically, the result of a cryptographic hash is a decimal or hexadecimal number so should be identifiable.
In analysing Session IDs sequences, patterns or cycles, static elements and client dependencies should all be considered as possible contributing elements to the structure and function of the application.
* Are the Session IDs provably random in nature? e.g. Can the result be reproduced?
* Do the same input conditions produce the same ID on a subsequent run?
* Are the Session IDs provably resistant to statistical or cryptanalysis?
* What elements of the Session IDs are time-linked?
* What portions of the Session IDs are predictable?
* Can the next ID be deduced even given full knowledge of the generation algorithm and previous IDs?

'''Brute Force Attacks'''<br>
Brute force attacks inevitably lead on from questions relating to predictability and randomness.
The variance within the Session IDs must be considered together with application session durations and timeouts. If the variation within the Session IDs is relatively small, and Session ID validity is long, the likelihood of a successful brute-force attack is much higher.
A long session ID (or rather one with a great deal of variance) and a shorter validity period would make it far harder to succeed in a brute force attack.
* How long would a brute-force attack on all possible Session IDs take?
* Is the Session ID space large enough to prevent brute forcing? e.g. is the length of the key sufficient when compared to the valid life-span
* Do delays between connection attempts with different Session IDs mitigate the risk of this attack?

== Gray Box testing and example ==
If you can access to session management schema implementation, you can check for the following:
* Random Session Token
The sessionID or Cookie issued to the client should not be easily predictable (don't use linear algorithm based on predictable variables or client IPArddr). The use of cryptographic algorithms with key lenght of 256 bits is encouraged (like AES).
* Token length
SessionID will be at least 50 characters length.
* Session Time-out
Session token should have a defined time-out (it depends on the criticality of the application managed data)
* Cookie configuration
** non-persistent: only RAM memory
** secure (set only on HTTPS channel): Set Cookie: cookie=data; path=/; domain=.aaa.it; secure
** [[HTTPOnly]] (not readable by a script): Set Cookie: cookie=data; path=/; domain=.aaa.it; [[HttpOnly]]

== References ==
'''Whitepapers'''<br>
* Gunter Ollmann: "Web Based Session Management" - http://www.technicalinfo.net
* RFCs 2109 & 2965: "HTTP State Management Mechanism" - http://www.ietf.org/rfc/rfc2965.txt, http://www.ietf.org/rfc/rfc2109.txt
* RFC 2616: "Hypertext Transfer Protocol -- HTTP/1.1" - http://www.ietf.org/rfc/rfc2616.txt

<br>

{{Category:OWASP Testing Project AoC}}

Test HTTP Methods (OTG-CONFIG-006)

2007-07-27T17:26:48Z

Rknell: Linked keyword HTTPOnly

[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]]<br>
{{Template:OWASP Testing Guide v2}}

== Brief Summary ==
In this test we check that the web server is not configured to allow potentially dangerous HTTP commands (methods) and that Cross Site Tracing (XST) is not possible<br>
== Short Description of the Issue (Topic and Explanation) ==
While GET and POST are by far the most common methods that are used to access information provided by a web server, the Hypertext Transfer Protocol (HTTP) allows several other (and somewhat less known) methods. RFC 2616 (which describes HTTP version 1.1 which is the today standard) defines the following eight methods:

* HEAD
* GET
* POST
* PUT
* DELETE
* TRACE
* OPTIONS
* CONNECT

Some of these methods can potentially pose a security risk for a web application, as they allow an attacker to modify the files stored on the web server and, in some scenarios, steal the credentials of legitimate users. More specifically, the methods that should be disabled are the following:

* PUT: This method allows a client to upload new files on the web server. An attacker can exploit it by uploading malicious files (e.g.: an asp file that executes commands by invoking cmd.exe), or by simply using the victim server as a file repository
* DELETE: This method allows a client to delete a file on the web server. An attacker can exploit it as a very simple and direct way to deface a web site or to mount a DoS attack
* CONNECT: This method could allow a client to use the web server as a proxy
* TRACE: This method simply echoes back to the client whatever string has been sent to the server, and it is used mainly for debugging purposes. This method, apparently harmless, can be used to mount an attack known as Cross Site Tracing, which has been discovered by Jeremiah Grossman (see links at the bottom of the page)

If an application needs one or more of these methods, it is important to check that their use is properly limited to trusted users and safe conditions.
== Black Box testing and example ==
'''Discover the Supported Methods''' <br>
To perform this test, we need some way to figure out which HTTP methods are supported by the web server we are examining. The OPTIONS HTTP method provides us with the most direct and effective way to do that. RFC 2616 states that “The OPTIONS method represents a request for information about the communication options available on the request/response chain identified by the Request-URI”.

The testing method is extremely straightforward and we only need to fire up netcat (or telnet):
<pre>
icesurfer@nightblade ~ $ nc www.victim.com 80
OPTIONS / HTTP/1.1
Host: www.victim.com

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Tue, 31 Oct 2006 08:00:29 GMT
Connection: close
Allow: GET, HEAD, POST, TRACE, OPTIONS
Content-Length: 0

icesurfer@nightblade ~ $
</pre>
As we can see in the example, OPTIONS provides a list of the methods that are supported by the web server, and in this case we can see, for instance, that TRACE method is enabled. The danger that is posed by this method is illustrated in the following section<br><br>
'''Test XST Potential'''<br>
Note: in order to understand the logic and the goals of this attack you need to be familiar with [[Cross_site_scripting_AoC | Cross Site Scripting attacks]].

The TRACE method, while apparently harmless, can be successfully leveraged in some scenarios to steal legitimate users' credentials. This attack technique was discovered by Jeremiah Grossman in 2003, in an attempt to bypass the [[HTTPOnly]] tag that Microsoft introduced in Internet Explorer 6 sp1 to protect cookies from being accessed by JavaScript. As a matter of fact, one of the most recurring attack patterns in Cross Site Scripting is to access the document.cookie object and send it to a web server controlled by the attacker so that he/she can hijack the victim's session. Tagging a cookie as httpOnly forbids JavaScript to access it, protecting it from being sent to a third party. However, the TRACE method can be used to bypass this protection and access the cookie even in this scenario.

As mentioned before, TRACE simply returns any string that is sent to the web server. In order to verify its presence (or to double-check the results of the OPTIONS request shown above), we can proceed as shown in the following example:
<pre>
icesurfer@nightblade ~ $ nc www.victim.com 80
TRACE / HTTP/1.1
Host: www.victim.com

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Tue, 31 Oct 2006 08:01:48 GMT
Connection: close
Content-Type: message/http
Content-Length: 39

TRACE / HTTP/1.1
Host: www.victim.com
</pre>
As we can see, the response body is exactly a copy of our original request, meaning that our target allows this method. Now, where is the danger lurking? If we instruct a browser to issue a TRACE request to the web server, and this browser has a cookie for that domain, the cookie will be automatically included in the request headers, and will therefore echoed back in the resulting response. At that point, the cookie string will be accessible by JavaScript and it will be finally possible to send it to a third party even when the cookie is tagged as httpOnly.

There are multiple ways to make a browser issue a TRACE request, as the XMLHTTP ActiveX control in Internet Explorer and XMLDOM in Mozilla and Netscape. However, for security reasons the browser is allowed to start a connection only to the domain where the hostile script resides. This is a mitigating factor, as the attacker needs to combine the TRACE method with another vulnerability in order to mount the attack. Basically, an attacker has two ways to successfully launch a Cross Site Tracing attack:

* 1.Leveraging another server-side vulnerability: the attacker injects the hostile JavaScript snippet, that contains the TRACE request, in the vulnerable application, as in a normal Cross Site Scripting attack
* 2.Leveraging a client-side vulnerability: the attacker creates a malicious website that contains the hostile JavaScript snippet and exploits some cross-domain vulnerability of the browser of the victim, in order to make the JavaScript code successfully perform a connection to the site that supports the TRACE method and that originated the cookie that the attacker is trying to steal.

More detailed information, together with code samples, can be found in the original whitepaper written by Jeremiah Grossman.<br>

== Gray Box testing and example ==
The testing in a Gray Box scenario follows the same steps of a Black Box scenario
<br><br>
== References ==
'''Whitepapers'''<br>
* RFC 2616: “Hypertext Transfer Protocol -- HTTP/1.1”
* RFC 2109 and RFC 2965: “HTTP State Management Mechanism”
* Jeremiah Grossman: "Cross Site Tracing (XST)" - http://www.cgisecurity.com/whitehat-mirror/WH-WhitePaper_XST_ebook.pdf<br>
* Amit Klein: "XS(T) attack variants which can, in some cases, eliminate the need for TRACE" - http://www.securityfocus.com/archive/107/308433
'''Tools'''
* NetCat - http://www.vulnwatch.org/netcat
<br>

{{Category:OWASP Testing Project AoC}}

HttpOnly

2007-07-27T16:04:47Z

Rknell: Updated 'overview' and 'references' section

== 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. Using the HTTPOnly flag helps 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 or the web site that originally set the cookie. As a result, even if a cross-site scripting '''(XSS)''' flaw exists, and a user accidentally accesses a link that exploits this flaw, 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 cookie will be 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 Mitigating], [http://msdn2.microsoft.com/en-us/library/ms533046.aspx]

<h3 style=color:#4682B4> <u> Mitigating XSS using HTTPOnly </u> </h3>

According to [http://msdn2.microsoft.com/en-us/library/ms972826.aspx Michael Howard], Senior Security Program Manager in the Secure Windows Initiative group at Microsoft, the majority of XSS attacks succeed because a session cookie has been leaked. A server could help mitigate this issue by setting a flag within a ''HTTP response header,'' indicating a session cookie should never be accessed by the client.

If Internet Explorer detects a cookie containing the HttpOnly flag, and client side script code attempts to read the cookie, Internet Explorer ''returns an empty string''. As a result, the attack fails by preventing the malicious XSS code from sending the data to an attacker's website. [http://msdn2.microsoft.com/en-us/library/ms972826.aspx Howard], [http://msdn2.microsoft.com/en-us/library/ms972826.aspx]

== 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'''.

{|border="2" width="100%" align="center"
|+ '''Table 1:''' Browsers Supporting HTTPOnly
|-
! style="background:black; color:white" | '''Browser'''
! style="background:black; color:white" | '''Version'''
! style="background:black; color:white" | '''Supports HTTPOnly?'''
|-
| Microsoft Internet Explorer
| align="center" | 6 (SP1) - 7
| align="center" | Partially*
|-
| Mozilla Firefox
| align="center" | 2.0.0.5
| align="center" | Partially*
|-
| Netscape Navigator
| align="center" | 9.0b2
| align="center" | No
|-
| Opera
| align="center" | 9.22
| align="center" | No
|}

<nowiki>*</nowiki> An attacker could still access the session identifier cookie using a '''[http://ha.ckers.org/blog/20070719/firefox-implements-httponly-and-is-vulnerable-to-xmlhttprequest/ XmlHttpRequest]'''.

== Using WebGoat to Test for HTTPOnly Capabilities ==

<h3 style=color:#4682B4> <u> Getting Started </u> </h3>

[[Image:Click_link.JPG|thumb|175px|right|Figure 1 - Accessing WebGoat's HTTPOnly Test Lesson]]

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.

<h3 style=color:#4682B4> <u> Lesson Goal </u> </h3>

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.

<h3 style=color:#4682B4> <u> Testing Web Browsers for HTTPOnly Support </u> </h3>

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.

<h5 style=color:#2E8B57> <u> Disabling HTTPOnly </u> </h5>

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

[[Image:Fig2-Disabling_HTTPOnly.PNG|frame|center|Figure 2 - Disabling HTTPOnly]]

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

[[Image:Fig3-Read_HTTPOnly_Off.PNG|frame|center|Figure 3 - Cookie Successfully Read with HTTPOnly Off]]

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

[[Image:Fig4-Write_HTTPOnly_Off.PNG|frame|center|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.

<h5 style=color:#2E8B57> <u> Enabling HTTPOnly </u> </h5>

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

[[Image:Fig5-Turning_HTTPOnly_On.PNG|frame|center|Figure 5 - Enabling HTTPOnly]]

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

[[Image:Fig6-Cookie_Read_Protection.PNG|frame|center|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'''.

[[Image:Fig7-No_Cookie_Read_Protection.PNG|frame|center|Figure 7 - Unenforced Cookie Read Protection]]

*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'''.

[[Image:Fig6-Cookie_Read_Protection.PNG|frame|center|Figure 8 - Enforced Cookie Write Protection]]

*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'''.

[[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!"]

[2] [http://msdn2.microsoft.com/en-us/library/ms533046.aspx Mitigating Cross-site Scripting with HTTP-Only Cookies]

[3] Howard, Michael. [http://msdn2.microsoft.com/en-us/library/ms972826.aspx Some Bad News and Some Good News]

HttpOnly

2007-07-27T15:31:59Z

Rknell: Added references and two headings including text within overview section

== 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 ==

Using WebGoat's HTTPOnly lesson, the following web browsers have been tested for HTTPOnly capabilities. The results are listed below in '''table 1'''.

{|border="2" width="100%" align="center"
|+ '''Table 1:''' Browsers Supporting HTTPOnly
|-
! style="background:black; color:white" | '''Browser'''
! style="background:black; color:white" | '''Version'''
! style="background:black; color:white" | '''Supports HTTPOnly?'''
|-
| Microsoft Internet Explorer
| align="center" | 6 (SP1) - 7
| align="center" | Partially*
|-
| Mozilla Firefox
| align="center" | 2.0.0.5
| align="center" | Partially*
|-
| Netscape Navigator
| align="center" | 9.0b2
| align="center" | No
|-
| Opera
| align="center" | 9.22
| align="center" | No
|}

<nowiki>*</nowiki> An attacker could still access the session identifier cookie using a '''[http://ha.ckers.org/blog/20070719/firefox-implements-httponly-and-is-vulnerable-to-xmlhttprequest/ XmlHttpRequest]'''.

== Using WebGoat to Test for HTTPOnly Capabilities ==

<h3 style=color:#4682B4> <u> Getting Started </u> </h3>

[[Image:Click_link.JPG|thumb|175px|right|Figure 1 - Accessing WebGoat's HTTPOnly Test Lesson]]

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.

<h3 style=color:#4682B4> <u> Lesson Goal </u> </h3>

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.

<h3 style=color:#4682B4> <u> Testing Web Browsers for HTTPOnly Support </u> </h3>

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.

<h5 style=color:#2E8B57> <u> Disabling HTTPOnly </u> </h5>

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

[[Image:Fig2-Disabling_HTTPOnly.PNG|frame|center|Figure 2 - Disabling HTTPOnly]]

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

[[Image:Fig3-Read_HTTPOnly_Off.PNG|frame|center|Figure 3 - Cookie Successfully Read with HTTPOnly Off]]

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

[[Image:Fig4-Write_HTTPOnly_Off.PNG|frame|center|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.

<h5 style=color:#2E8B57> <u> Enabling HTTPOnly </u> </h5>

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

[[Image:Fig5-Turning_HTTPOnly_On.PNG|frame|center|Figure 5 - Enabling HTTPOnly]]

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

[[Image:Fig6-Cookie_Read_Protection.PNG|frame|center|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'''.

[[Image:Fig7-No_Cookie_Read_Protection.PNG|frame|center|Figure 7 - Unenforced Cookie Read Protection]]

*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'''.

[[Image:Fig6-Cookie_Read_Protection.PNG|frame|center|Figure 8 - Enforced Cookie Write Protection]]

*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'''.

[[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!"]

HttpOnly

2007-07-27T13:09:57Z

Rknell:

== Overview ==

== 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'''.

{|border="2" width="100%" align="center"
|+ '''Table 1:''' Browsers Supporting HTTPOnly
|-
! style="background:black; color:white" | '''Browser'''
! style="background:black; color:white" | '''Version'''
! style="background:black; color:white" | '''Supports HTTPOnly?'''
|-
| Microsoft Internet Explorer
| align="center" | 6 (SP1) - 7
| align="center" | Partially*
|-
| Mozilla Firefox
| align="center" | 2.0.0.5
| align="center" | Partially*
|-
| Netscape Navigator
| align="center" | 9.0b2
| align="center" | No
|-
| Opera
| align="center" | 9.22
| align="center" | No
|}

<nowiki>*</nowiki> An attacker could still access the session identifier cookie using a '''[http://ha.ckers.org/blog/20070719/firefox-implements-httponly-and-is-vulnerable-to-xmlhttprequest/ XmlHttpRequest]'''.

== Using WebGoat to Test for HTTPOnly Capabilities ==

<h3 style=color:#4682B4> <u> Getting Started </u> </h3>

[[Image:Click_link.JPG|thumb|175px|right|Figure 1 - Accessing WebGoat's HTTPOnly Test Lesson]]

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.

<h3 style=color:#4682B4> <u> Lesson Goal </u> </h3>

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.

<h3 style=color:#4682B4> <u> Testing Web Browsers for HTTPOnly Support </u> </h3>

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.

<h5 style=color:#2E8B57> <u> Disabling HTTPOnly </u> </h5>

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

[[Image:Fig2-Disabling_HTTPOnly.PNG|frame|center|Figure 2 - Disabling HTTPOnly]]

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

[[Image:Fig3-Read_HTTPOnly_Off.PNG|frame|center|Figure 3 - Cookie Successfully Read with HTTPOnly Off]]

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

[[Image:Fig4-Write_HTTPOnly_Off.PNG|frame|center|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.

<h5 style=color:#2E8B57> <u> Enabling HTTPOnly </u> </h5>

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

[[Image:Fig5-Turning_HTTPOnly_On.PNG|frame|center|Figure 5 - Enabling HTTPOnly]]

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

[[Image:Fig6-Cookie_Read_Protection.PNG|frame|center|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'''.

[[Image:Fig7-No_Cookie_Read_Protection.PNG|frame|center|Figure 7 - Unenforced Cookie Read Protection]]

*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'''.

[[Image:Fig6-Cookie_Read_Protection.PNG|frame|center|Figure 8 - Enforced Cookie Write Protection]]

*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'''.

[[Image:Fig9-No_Cookie_Write_Protection.PNG|frame|center|Figure 9 - Unenforced Cookie Write Protection]]

HttpOnly

2007-07-26T20:41:34Z

Rknell:

== Overview ==

== 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'''.

{|border="2" width="100%" align="center"
|+ '''Table 1:''' Browsers Supporting HTTPOnly
|-
! style="background:black; color:white" | '''Browser'''
! style="background:black; color:white" | '''Version'''
! style="background:black; color:white" | '''Supports HTTPOnly?'''
|-
| Microsoft Internet Explorer
| align="center" | 6 (SP1) - 7
| align="center" | Partially*
|-
| Mozilla Firefox
| align="center" | 2.0.0.5
| align="center" | Partially*
|-
| Netscape Navigator
| align="center" | 9.0b2
| align="center" | No
|-
| Opera
| align="center" | 9.22
| align="center" | No
|}

<nowiki>*</nowiki> An attacker could still access the session identifier cookie using a '''[http://ha.ckers.org/blog/20070719/firefox-implements-httponly-and-is-vulnerable-to-xmlhttprequest/ XmlHttpRequest]'''.

== Using WebGoat to Test for HTTPOnly Capabilities ==

<h3 style=color:#4682B4> <u> Getting Started </u> </h3>

[[Image:Click_link.JPG|thumb|175px|right|Figure 1 - Accessing WebGoat's HTTPOnly Test Lesson]]

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.

<h3 style=color:#4682B4> <u> Lesson Goal </u> </h3>

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.

<h3 style=color:#4682B4> <u> Testing Web Browsers for HTTPOnly Support </u> </h3>

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.

<h5 style=color:#2E8B57> <u> Disabling HTTPOnly </u> </h5>

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

[[Image:Fig2-Disabling_HTTPOnly.PNG|frame|center|Figure 2 - Disabling HTTPOnly]]

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

[[Image:Fig3-Read_HTTPOnly_Off.PNG|frame|center|Figure 3 - Cookie Successfully Read with HTTPOnly Off]]

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

[[Image:Fig4-Write_HTTPOnly_Off.PNG|frame|center|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.

<h5 style=color:#2E8B57> <u> Enabling HTTPOnly </u> </h5>

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

[[Image:Fig5-Turning_HTTPOnly_On.PNG|frame|center|Figure 5 - Enabling HTTPOnly]]

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

*If the browser enforces the HTTPOnly flag properly, an alert dialog box will display on the screen only containing the session ID, not the contents of the '''‘unique2u’ cookie''' as shown below in '''figure 6'''.

[[Image:Fig6-Cookie_Read_Protection.PNG|frame|center|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'''.

[[Image:Fig7-No_Cookie_Read_Protection.PNG|frame|center|Figure 7 - Unenforced Cookie Read Protection]]

*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'''.

[[Image:Fig6-Cookie_Read_Protection.PNG|frame|center|Figure 7 - Enforced Cookie Write Protection]]

*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'''.

[[Image:Fig9-No_Cookie_Write_Protection.PNG|frame|center|Figure 9 - Unenforced Cookie Write Protection]]

HttpOnly

2007-07-26T20:39:34Z

Rknell: Added h5 headings for ease of scanning

== Overview ==

== 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'''.

{|border="2" width="100%" align="center"
|+ '''Table 1:''' Browsers Supporting HTTPOnly
|-
! style="background:black; color:white" | '''Browser'''
! style="background:black; color:white" | '''Version'''
! style="background:black; color:white" | '''Supports HTTPOnly?'''
|-
| Microsoft Internet Explorer
| align="center" | 6 (SP1) - 7
| align="center" | Partially*
|-
| Mozilla Firefox
| align="center" | 2.0.0.5
| align="center" | Partially*
|-
| Netscape Navigator
| align="center" | 9.0b2
| align="center" | No
|-
| Opera
| align="center" | 9.22
| align="center" | No
|}

<nowiki>*</nowiki> An attacker could still access the session identifier cookie using a '''[http://ha.ckers.org/blog/20070719/firefox-implements-httponly-and-is-vulnerable-to-xmlhttprequest/ XmlHttpRequest]'''.

== Using WebGoat to Test for HTTPOnly Capabilities ==

<h3 style=color:#4682B4> <u> Getting Started </u> </h3>

[[Image:Click_link.JPG|thumb|175px|right|Figure 1 - Accessing WebGoat's HTTPOnly Test Lesson]]

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.

<h3 style=color:#4682B4> <u> Lesson Goal </u> </h3>

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.

<h3 style=color:#4682B4> <u> Testing Web Browsers for HTTPOnly Support </u> </h3>

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.

<h5 style=color:#2E8B57> <u> HTTPOnly Disabled </u> </h5>

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

[[Image:Fig2-Disabling_HTTPOnly.PNG|frame|center|Figure 2 - Disabling HTTPOnly]]

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

[[Image:Fig3-Read_HTTPOnly_Off.PNG|frame|center|Figure 3 - Cookie Successfully Read with HTTPOnly Off]]

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

[[Image:Fig4-Write_HTTPOnly_Off.PNG|frame|center|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.

<h5 style=color:#2E8B57> <u> HTTPOnly Enabled </u> </h5>

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

[[Image:Fig5-Turning_HTTPOnly_On.PNG|frame|center|Figure 5 - Enabling HTTPOnly]]

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

*If the browser enforces the HTTPOnly flag properly, an alert dialog box will display on the screen only containing the session ID, not the contents of the '''‘unique2u’ cookie''' as shown below in '''figure 6'''.

[[Image:Fig6-Cookie_Read_Protection.PNG|frame|center|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'''.

[[Image:Fig7-No_Cookie_Read_Protection.PNG|frame|center|Figure 7 - Unenforced Cookie Read Protection]]

*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'''.

[[Image:Fig6-Cookie_Read_Protection.PNG|frame|center|Figure 7 - Enforced Cookie Write Protection]]

*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'''.

[[Image:Fig9-No_Cookie_Write_Protection.PNG|frame|center|Figure 9 - Unenforced Cookie Write Protection]]

HttpOnly

2007-07-26T20:32:48Z

Rknell:

== Overview ==

== 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'''.

{|border="2" width="100%" align="center"
|+ '''Table 1:''' Browsers Supporting HTTPOnly
|-
! style="background:black; color:white" | '''Browser'''
! style="background:black; color:white" | '''Version'''
! style="background:black; color:white" | '''Supports HTTPOnly?'''
|-
| Microsoft Internet Explorer
| align="center" | 6 (SP1) - 7
| align="center" | Partially*
|-
| Mozilla Firefox
| align="center" | 2.0.0.5
| align="center" | Partially*
|-
| Netscape Navigator
| align="center" | 9.0b2
| align="center" | No
|-
| Opera
| align="center" | 9.22
| align="center" | No
|}

<nowiki>*</nowiki> An attacker could still access the session identifier cookie using a '''[http://ha.ckers.org/blog/20070719/firefox-implements-httponly-and-is-vulnerable-to-xmlhttprequest/ XmlHttpRequest]'''.

== Using WebGoat to Test for HTTPOnly Capabilities ==

<h3 style=color:#4682B4> <u> Getting Started </u> </h3>

[[Image:Click_link.JPG|thumb|175px|right|Figure 1 - Accessing WebGoat's HTTPOnly Test Lesson]]

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.

<h3 style=color:#4682B4> <u> Lesson Goal </u> </h3>

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.

<h3 style=color:#4682B4> <u> Testing Web Browsers for HTTPOnly Support </u> </h3>

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.

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

[[Image:Fig2-Disabling_HTTPOnly.PNG|frame|center|Figure 2 - Disabling HTTPOnly]]

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

[[Image:Fig3-Read_HTTPOnly_Off.PNG|frame|center|Figure 3 - Cookie Successfully Read with HTTPOnly Off]]

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

[[Image:Fig4-Write_HTTPOnly_Off.PNG|frame|center|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.

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

[[Image:Fig5-Turning_HTTPOnly_On.PNG|frame|center|Figure 5 - Enabling HTTPOnly]]

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

*If the browser enforces the HTTPOnly flag properly, an alert dialog box will display on the screen only containing the session ID, not the contents of the '''‘unique2u’ cookie''' as shown below in '''figure 6'''.

[[Image:Fig6-Cookie_Read_Protection.PNG|frame|center|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'''.

[[Image:Fig7-No_Cookie_Read_Protection.PNG|frame|center|Figure 7 - Unenforced Cookie Read Protection]]

*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'''.

[[Image:Fig6-Cookie_Read_Protection.PNG|frame|center|Figure 7 - Enforced Cookie Write Protection]]

*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'''.

[[Image:Fig9-No_Cookie_Write_Protection.PNG|frame|center|Figure 9 - Unenforced Cookie Write Protection]]

HttpOnly

2007-07-26T20:20:27Z

Rknell: Step 6 Completed with images implemented

== Overview ==

== 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'''.

{|class="wikitable sortable" border="1" width="100%" align="center"
|+ Table 1: Browsers Supporting HTTPOnly
|-
! style="background:black; color:white" | '''Browser'''
! style="background:black; color:white" | '''Version'''
! style="background:black; color:white" | '''Supports HTTPOnly?'''
|-
| Microsoft Internet Explorer
| align="center" | 6 (SP1) - 7
| align="center" | Partially*
|-
| Mozilla Firefox
| align="center" | 2.0.0.5
| align="center" | Partially*
|-
| Netscape Navigator
| align="center" | 9.0b2
| align="center" | No
|-
| Opera
| align="center" | 9.22
| align="center" | No
|}

*An attacker could still access the session identifier cookie using a '''[http://ha.ckers.org/blog/20070719/firefox-implements-httponly-and-is-vulnerable-to-xmlhttprequest/ XmlHttpRequest]'''.

== Using WebGoat to Test for HTTPOnly Capabilities ==

<h3 style=color:#4682B4> <u> Getting Started </u> </h3>

[[Image:Click_link.JPG|thumb|175px|right|Figure 1 - Accessing WebGoat's HTTPOnly Test Lesson]]

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.

<h3 style=color:#4682B4> <u> Lesson Goal </u> </h3>

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.

<h3 style=color:#4682B4> <u> Testing Web Browsers for HTTPOnly Support </u> </h3>

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.

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

[[Image:Fig2-Disabling_HTTPOnly.PNG|frame|center|Figure 2 - Disabling HTTPOnly]]

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

[[Image:Fig3-Read_HTTPOnly_Off.PNG|frame|center|Figure 3 - Cookie Successfully Read with HTTPOnly Off]]

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

[[Image:Fig4-Write_HTTPOnly_Off.PNG|frame|center|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.

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

[[Image:Fig5-Turning_HTTPOnly_On.PNG|frame|center|Figure 5 - Enabling HTTPOnly]]

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

*If the browser enforces the HTTPOnly flag properly, an alert dialog box will display on the screen only containing the session ID, not the contents of the '''‘unique2u’ cookie''' as shown below in '''figure 6'''.

[[Image:Fig6-Cookie_Read_Protection.PNG|frame|center|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'''.

[[Image:Fig7-No_Cookie_Read_Protection.PNG|frame|center|Figure 7 - Unenforced Cookie Read Protection]]

*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'''.

[[Image:Fig6-Cookie_Read_Protection.PNG|frame|center|Figure 7 - Enforced Cookie Write Protection]]

*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'''.

[[Image:Fig9-No_Cookie_Write_Protection.PNG|frame|center|Figure 9 - Unenforced Cookie Write Protection]]

File:Fig9-No Cookie Write Protection.PNG

2007-07-26T20:17:47Z

Rknell: Screen shot of unenforced cookie write protection for WebGoat's HTTPOnly lesson.

Screen shot of unenforced cookie write protection for WebGoat's HTTPOnly lesson.

HttpOnly

2007-07-26T20:13:42Z

Rknell: Updated: Step 6

== Overview ==

== 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'''.

{|class="wikitable sortable" border="1" width="100%" align="center"
|+ Table 1: Browsers Supporting HTTPOnly
|-
! style="background:black; color:white" | '''Browser'''
! style="background:black; color:white" | '''Version'''
! style="background:black; color:white" | '''Supports HTTPOnly?'''
|-
| Microsoft Internet Explorer
| align="center" | 6 (SP1) - 7
| align="center" | Partially*
|-
| Mozilla Firefox
| align="center" | 2.0.0.5
| align="center" | Partially*
|-
| Netscape Navigator
| align="center" | 9.0b2
| align="center" | No
|-
| Opera
| align="center" | 9.22
| align="center" | No
|}

*An attacker could still access the session identifier cookie using a '''[http://ha.ckers.org/blog/20070719/firefox-implements-httponly-and-is-vulnerable-to-xmlhttprequest/ XmlHttpRequest]'''.

== Using WebGoat to Test for HTTPOnly Capabilities ==

<h3 style=color:#4682B4> <u> Getting Started </u> </h3>

[[Image:Click_link.JPG|thumb|175px|right|Figure 1 - Accessing WebGoat's HTTPOnly Test Lesson]]

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.

<h3 style=color:#4682B4> <u> Lesson Goal </u> </h3>

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.

<h3 style=color:#4682B4> <u> Testing Web Browsers for HTTPOnly Support </u> </h3>

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.

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

[[Image:Fig2-Disabling_HTTPOnly.PNG|frame|center|Figure 2 - Disabling HTTPOnly]]

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

[[Image:Fig3-Read_HTTPOnly_Off.PNG|frame|center|Figure 3 - Cookie Successfully Read with HTTPOnly Off]]

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

[[Image:Fig4-Write_HTTPOnly_Off.PNG|frame|center|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.

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

[[Image:Fig5-Turning_HTTPOnly_On.PNG|frame|center|Figure 5 - Enabling HTTPOnly]]

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

*If the browser enforces the HTTPOnly flag properly, an alert dialog box will display on the screen only containing the session ID, not the contents of the '''‘unique2u’ cookie''' as shown below in '''figure 6'''.

[[Image:Fig6-Cookie_Read_Protection.PNG|frame|center|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'''.

[[Image:Fig7-No_Cookie_Read_Protection.PNG|frame|center|Figure 7 - Unenforced Cookie Read Protection]]

*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'''.

HttpOnly

2007-07-26T20:08:46Z

Rknell: Updated: Text as well as implemented figures 6 & 7

== Overview ==

== 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'''.

{|class="wikitable sortable" border="1" width="100%" align="center"
|+ Table 1: Browsers Supporting HTTPOnly
|-
! style="background:black; color:white" | '''Browser'''
! style="background:black; color:white" | '''Version'''
! style="background:black; color:white" | '''Supports HTTPOnly?'''
|-
| Microsoft Internet Explorer
| align="center" | 6 (SP1) - 7
| align="center" | Partially*
|-
| Mozilla Firefox
| align="center" | 2.0.0.5
| align="center" | Partially*
|-
| Netscape Navigator
| align="center" | 9.0b2
| align="center" | No
|-
| Opera
| align="center" | 9.22
| align="center" | No
|}

*An attacker could still access the session identifier cookie using a '''[http://ha.ckers.org/blog/20070719/firefox-implements-httponly-and-is-vulnerable-to-xmlhttprequest/ XmlHttpRequest]'''.

== Using WebGoat to Test for HTTPOnly Capabilities ==

<h3 style=color:#4682B4> <u> Getting Started </u> </h3>

[[Image:Click_link.JPG|thumb|175px|right|Figure 1 - Accessing WebGoat's HTTPOnly Test Lesson]]

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.

<h3 style=color:#4682B4> <u> Lesson Goal </u> </h3>

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.

<h3 style=color:#4682B4> <u> Testing Web Browsers for HTTPOnly Support </u> </h3>

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.

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

[[Image:Fig2-Disabling_HTTPOnly.PNG|frame|center|Figure 2 - Disabling HTTPOnly]]

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

[[Image:Fig3-Read_HTTPOnly_Off.PNG|frame|center|Figure 3 - Cookie Successfully Read with HTTPOnly Off]]

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

[[Image:Fig4-Write_HTTPOnly_Off.PNG|frame|center|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.

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

[[Image:Fig5-Turning_HTTPOnly_On.PNG|frame|center|Figure 5 - Enabling HTTPOnly]]

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

*If the browser enforces the HTTPOnly flag properly, an alert dialog box will display on the screen only containing the session ID, not the contents of the '''‘unique2u’ cookie''' as shown below in '''figure 6'''.

[[Image:Fig6-Cookie_Read_Protection.PNG|frame|center|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'''.

[[Image:Fig7-No_Cookie_Read_Protection.PNG|frame|center|Figure 7 - Unenforced Cookie Read Protection]]

File:Fig7-No Cookie Read Protection.PNG

2007-07-26T20:01:07Z

Rknell: Screen shot of no cookie read protection for WebGoat HTTPOnly Lesson.

Screen shot of no cookie read protection for WebGoat HTTPOnly Lesson.

File:Fig6-Cookie Read Protection.PNG

2007-07-26T20:00:25Z

Rknell: Screen shot of cookie read protection for WebGoat HTTPOnly Lesson.

Screen shot of cookie read protection for WebGoat HTTPOnly Lesson.

File:Fig5-Turning HTTPOnly On.PNG

2007-07-26T19:59:38Z

Rknell: Screen shot of enabling HTTPOnly within WebGoat HTTPOnly lesson

Screen shot of enabling HTTPOnly within WebGoat HTTPOnly lesson

HttpOnly

2007-07-26T19:52:50Z

Rknell:

HttpOnly

2007-07-26T19:48:43Z

Rknell: Text and figures 3 & 4 implemented

File:Fig4-Write HTTPOnly Off.PNG

2007-07-26T19:39:16Z

Rknell: Screen shot of WebGoat HTTPOnly Lesson

Screen shot of WebGoat HTTPOnly Lesson

File:Fig3-Read HTTPOnly Off.PNG

2007-07-26T19:38:11Z

Rknell: WebGoat HTTPOnly lesson screenshot

WebGoat HTTPOnly lesson screenshot

HttpOnly

2007-07-26T19:32:42Z

Rknell: Changed Figure 1 to a thumbnail

HttpOnly

2007-07-26T19:13:58Z

Rknell: