Common Methods
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. Some example of such input data are the following:
<script>alert(123)</script>“><script>alert(document.cookie)</script>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:
> (greater than)
< (less than)
& (ampersand)
' (apostrophe or single quote)
" (double quote)However, a full list of entities is defined by the HTML and XML specifications. Wikipedia has a complete reference [1].
Within the context of an HTML action or JavaScript code, a different set of special characters will need to be escaped, encoded, replaced, or filtered out. These characters include:
\n (new line)
\r (carriage return)
\' (apostrophe or single quote)
\" (double quote)
\\ (backslash)
\uXXXX (unicode values)For a more complete reference, see the Mozilla JavaScript guide. [2]
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:
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.
Example 2: XSS-href*
1.Reconnaissance
Step 1
The application invites you to fill a website in the input box, that will be used from the "visit my website!" link to redirect to it.
If we insert https://google.com, and click on "visit my website!" we will be redirected to the Google website. As we can see in the screenshot below our input is reflected in the page inside an href attribute.
Step 2
The next step is to see if we could include JavaScript that can be executed in the href attribute.
href="javascript:JS PAYLOAD"
Autoescape is disabled by default so every characters will be reflected in the following snippet in the template.
Exploitation
Step 1
Now we have seen where the user input is being reflected in the href, we can craft the payload to trigger an alert box and exploit our XSS.
and clicking the button, we achieve what we were looking for.
2.Let's try other piece of code (link):
This produces the following behavior:
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
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:
Then an attacker could submit the following code:
Example 4: Different syntax or encoding
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:
Example 5: Bypassing non-recursive filtering
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:
Example 6: Including external script
Now suppose that developers of the target site implemented the following code to protect the input from the inclusion of external script:
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
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, http://example/.
Example 7: HTTP Parameter Pollution (HPP)
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 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.
Regular attack:
Attack using HPP:
Result expected 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.
Last updated