Protect Data From Cross-Site Scripting (XSS) Attacks

Security is always going to be a concern for both developers and ecommerce business owners alike, since providing a secure environment for making transactions is not only a matter of gaining customer trust, it is also a legal requirement. As websites become more interactive they are utilizing more and more client-side scripting, such as JavaScript, to provide a rich user experience. At the same time, user submitted content is also becoming a standard feature of most websites, the combination of which can leave a website open to what is called a Cross Site Scripting (XSS) attack, which can threaten the privacy of your confidential data.

A common XSS attack will utilize JavaScript, which is run locally on a user’s computer, to capture some bit of information and deliver it to the attacker. Most commonly, attackers will configure a script that will harvest cookies from a user’s machine. The hope is that the script was run while the user was logged into a protected interface that stores user information in a cookie. Once the attacker has the user information, it can be used to log into the victim’s website, with full administrative access. Of course, this is just one type of XSS attack, but it is probably the most common one developers need to worry about.

So how is this done? It all seems so abstract, that a piece of scripting code being run by a user and some seemingly insignificant piece of data being stolen can bring the entire castle down. As with most things, an example seems to help. Let’s take a website that allows users to post comments. A malicious user might post a comment with HTML code in it, such as a script tag that contains JavaScript code to steal cookie information. The user submits his/her comment to the website, where it is put into an approval queue, and waits for the fun to begin.

The website owner then logs into his/her administrative interface for the website and starts to review comments. As they click to view the comment from our malicious user, the JavaScript is executed by the browser without any knowledge of the website owner. This script (behind the scenes), collects the cookie information for that user’s administrative account, and sends it to the attacker’s website. The attacker can then use that information to log into the website owner’s administrative interface, where the attacker proceeds to download account information and credit card numbers for the website’s customers.

How could this have been prevented? The simple answer is to not allow visitors to post HTML code or any other markup language. In this extreme defense tactic, all HTML code is dynamically stripped from user submitted content when it is received. However, in many cases this is simply not a viable option, and administrators would like their users to be able to post markup code. Developers should look at making sure that HTML code is escaped (and therefore not executed by a browser) when initially viewing user submitted content, and that it is not displayed (allowed to be rendered by a browser) until an administrator has a chance to review it and clear it. Most scripting languages have functions that will automatically strip out or disable HTML code, such as strip_html() in PHP and h() in Ruby.

It’s important to remember that we have just outlined one type of Cross Site Scripting attack. There are different variations of XSS attacks that can be used in different ways, so it’s important for developers to become familiar with where security holes can exist and how to develop applications that minimize the risk of attack.