Cross-site scripting, also known as “XSS,” is a class of security exploit that has gotten a fair bit of attention in the last few years. Many users, and even Web developers, aren’t entirely clear on what the term means, however. I’ll explain cross-site scripting for you, so you will know where the dangers lie.
Defining cross-site scripting
Types of cross-site scripting
There are currently three major categories of cross-site scripting. Others may be discovered in the future, however, so don’t think this sort of misuse of Web page vulnerability is necessarily limited to these three types.
Reflected: Probably the most common type of cross-site scripting exploit is the reflected exploit. It targets vulnerabilities that occur in some websites when data submitted by the client is immediately processed by the server to generate results that are then sent back to the browser on the client system. An exploit is successful if it can send code to the server that is included in the Web page results sent back to the browser, and when those results are sent the code is not encoded using HTML special character encoding — thus being interpreted by the browser rather than being displayed as inert visible text.
The most common way to make use of this exploit probably involves a link using a malformed URL, such that a variable passed in a URL to be displayed on the page contains malicious code. Something as simple as another URL used by the server-side code to produce links on the page, or even a user’s name to be included in the text page so that the user can be greeted by name, can become a vulnerability employed in a reflected cross-site scripting exploit.
Stored: Also known as HTML injection attacks, stored cross-site scripting exploits are those where some data sent to the server is stored (typically in a database) to be used in the creation of pages that will be served to other users later. This form of cross-site scripting exploit can affect any visitor to your website, if your site is subject to a stored cross-site scripting vulnerability. The classic example of this sort of vulnerability is content management software such as forums and bulletin boards where users are allowed to use raw HTML and XHTML to format their posts.
As with preventing reflected exploits, the key to securing your site against stored exploits is ensuring that all submitted data is translated to display entities before display so that it will not be interpreted by the browser as code.
In a local cross-site scripting exploit, unlike reflected and stored exploits, no malicious code is sent to the server at all. The behavior of the exploit takes place entirely on the local client system, but it alters the pages provided by the otherwise benign Website before they are interpreted by the browser so that they behave as though they carried the malicious payload to the client from the server. This means that server-side protections that filter out or block malicious cross-site scripting will not work with this sort of exploit. For more about local cross-site scripting, see the explanation at DOM Based Cross Site Scripting.
Protection Against Cross-Site Scripting
Another way to protect your Website from cross-site scripting exploits is to never directly use any user-provided input in your pages. Accepting a limited number of values in user-provided input that are each used as “keys,” for lack of a better term, to choose from among certain predefined options is an example of how user-provided input can be used to define output, but obviously greatly limits the dynamic nature of Web applications. If your website does not need greater dynamism than this provides, however, this may be your safest option for generating output based on user input.
Similarly, input validation that simply strips out all characters unauthorized for specific, limited input types (such as removing everything but dashes, parentheses, periods, and digits from input expected to contain telephone numbers), or that rejects input containing unauthorized characters entirely, can be used. This is a useful technique for many forms of input, but not all. Such validation techniques should be used whenever possible, because they not only provide some protection against cross-site scripting, but also against direct attempts to compromise the server itself through buffer overflows, SQL injection, and other attempts to exceed the bounds of the system.
Cookies are often used to provide some form of security against cross-site scripting. Many cross-site scripting exploits are designed to “steal” session cookies, but a cookie can be “tied” to a particular IP address so that hijacked cookies fail validation when employed by cross-site scripting exploits. There are potential work-arounds for this sort of security, such as when the legitimate user of a given cookie and a cross-site scripting exploit both originate from behind the same proxy server or NAT device, of course. Internet Explorer implements an HTTPOnly flag that prevents local scripts from affecting a cookie to try to guard against this sort of cookie abuse, but it is ineffective against cross-site request forgery attacks, where unintended requests may be sent via cross-site scripting exploits alongside a cookie used to authorize the requests at the server.