Cross-site scripting (XSS) attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user in the output it generates, without validating or encoding it.
How to secure a site against XSS attacks
Malicious script can be stored/persisted in a database and shall not execute until retrieved by a user. This can also be the case in bulletin boards and some early web email clients. This incubated attack can sit dormant for a long period of time until a user decides to view the page where the injected script is present. At this point the script shall execute on the user’s browser.
The original source of input for the injected script may be from another vulnerable application, which is common in enterprise architectures. Therefore the application at hand may have good input data validation but the data persisted may not have been entered via this application per se, but via another application.
In this case we cannot be 100% sure the data to be displayed to the user is safe (as it could have found its way in via another path in the enterprise). The approach to mitigate against this is to ensure that data sent to the browser with the purpose of being displayed literally is not going to be interpreted by the browser as mark-up.
We encode known bad to mitigate against this “enemy within”. This, in effect, assures that the browser interprets any special characters as data and markup. How is this done? HTML encoding usually means < becomes <, > becomes >, & becomes &, and " becomes ".
| From | To |
| < |
< |
| > |
> |
| ( |
( |
| ) |
) |
| # |
# |
| & |
& |
| " |
" |
So, for example, if the application has a string "<script>" and it wants a browser to display it as "<script>", it can first HTML-encode it to the form "<script>" before including it in the web page that gets sent to the browser.
It is possible to secure a site against an XSS attack in three ways:
- By performing in-house input filtering (sometimes called input sanitation). For each user input -- be it a parameter or an HTTP header -- in each script written in-house, advanced filtering against HTML tags, including JavaScript code, should be applied. For example, the welcome.cgi script from the previous case study should filter the <script> tag after it is through decoding the name parameter. This method has some severe downsides, though:
- It requires the application programmer to be well-versed in security.
- It requires the programmer to cover all possible input sources (query parameters, body parameters of POSTrequests, HTTP headers).
- It cannot defend against vulnerabilities in third-party scripts or servers. For example, it won't defend against problems in error pages in Web servers (which display the path of the resource).
- By performing "output filtering," that is, filtering the user data when it is sent back to the browser, rather than when it is received by a script. A good example for this would be a script that inserts the input data to a database and then presents it. In this case, it is important not to apply the filter to the original input string, but only to the output version. The drawbacks are similar to the ones for input filtering.
- By installing a third-party application firewall, which intercepts XSS attacks before they reach the Web server and the vulnerable scripts, and blocks them. Application firewalls can cover all input methods in a generic way (including path and HTTP headers), regardless of the script or path from the in-house application, a third-party script, or a script describing no resource at all (for example, one designed to provoke a 404 page response from the server). For each input source, the application firewall inspects the data against various HTML tag patterns and JavaScript patterns. If any match, the request is rejected, and the malicious input does not arrive at the server.
