Hunting Cross-Site Scripting (XSS) If you are not familiar with XSS attacks, make sure you read the OWASP article “Cross Site Scripting (XSS)” at http://tinyurl.com/3hl5rxt. Here are the main points you need to know about XSS:
- XSS is a client-side attack executed in the browser.
- XSS is prevented by implementing proper output validation.
Nowadays it’s difficult to find XSS vulnerabilities, even if the developer did not implement any output validation, because the browsers have built-in protection for this attack.
When hunting XSS vulnerabilities, the first step is to identify the input fields (cookies, headers, forms, and so on) in the web application that will send back to the browser the data entered in those fields, either immediately (reflected XSS) or later after a specific query (stored XSS). Here are some common scenarios where XSS can be found:
- Search Fields The search term entered will be reflected in the response (for example, “The name <search-term-you-entered> was not found”).
- Contact Form This is where most of XSS is found. Usually, if the user enters a value not valid in the form, such as wrong email address, date, and so on, the error is detected and all the information entered will be sent back, filling out the contact form automatically so that the user only needs to fix the appropriate field. Attackers will take advantage of this behavior by purposely entering a wrong email address, for example, and the injection in another field will be executed while the contact form is being filled out again in the browser.
- Error Message Many XSS bugs have been found in the error messages returned by application such as Apache, .NET, Java, PHP, Perl, and more. This usually occurs when a wrong URL, an invalid filename, or an invalid data format is entered.
- HTML Links The data entered in the input fields is used to generate dynamic HTML links in the response.