Practical Ecommerce

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.

Brian Getting

Brian Getting

Bio   •   RSS Feed


email-news-env

Sign up for our email newsletter

Comments ( 4 )

  1. Legacy User June 26, 2007 Reply

    Now that I'm totally frightened, please tell this very small web site owner, what to do. I don't have an "administrator" (I'm it, I guess), nor do I have a developer (I'm it again). Can this type of attack happen with email comments sent through the website? Should small ecommerce site owners, like myself, not offer their customers the "contact us" option for sending comments? Thanks for any help you can offer.

    — *Janet*

  2. Legacy User June 26, 2007 Reply

    I wouldn't worry about it. Email clients don't usually run JavaScript, but if you are using web-based email you will want to watch out for that. To defend against the attacks described above, simply don't allow your visitors to post HTML code. Or if they can post HTML code (even if they aren't supposed to), then make sure that you get to see it (the raw code) and delete it before it is ever rendered in a browser.

    For example, if users can submit HTML comments to your website, then make sure that you can view the code to make sure there are no malicious scripts before allowing the code to be interpreted and rendered in a browser.

    — *Brian Getting*

  3. Legacy User June 26, 2007 Reply

    In this sophisticated technology world, Cross-Site Scripting (XSS) Attacks are just one of the attacks that we have to pay attention to. There are still lots of other attacks like SQL injection, session hijacking, DDOS, and more. To answer the poster: Janet, if your website feedback form (email) doesn't link to database, there is no much worry about this kind of attack if you are doing the job well (with security), like converting HTML input to HTML entities and regular expression. To minimize the threats, what we can do is always read and learn, keep our security knowledge up-to-date by reading more and more
    security articles that are posted online. Good luck to everybody.

    — *Kaven N*

  4. Legacy User July 30, 2007 Reply

    I'm just a learning developer and this article gave me information on securing the sites that I'm creating.

    Thanks a lot.

    — *Glenn*