Almost every day we hear or read about the eCommerce sites losing customer credit card data or other critical operational data. The companies lose critical information such as credit cards data, patient health records, and social security numbers to the hackers due to vulnerabilities in their customer facing web applications. While it may be impossible to guarantee the perfect safety, but by understanding how web vulnerabilities get exploited, you can make it extremely hard for hackers to attack your web applications. In this article, we discuss some techniques to protect your web applications.

While hackers use a variety to attacking techniques to attack the web sites, the Cross Site Scripting (also known as XSS or CSS) is one of the most common application layer hacking techniques. The web developers who put the web applications together either lack the understanding of the security threats, or do not have enough time/ resources to do proper code reviews of the large code base resulting in vulnerable application code. Despite it being a popular application layer attack technique, XSS still remains the most common security vulnerability in web applications today. As a matter of fact, today’s news came that a very popular Fancybox WordPress plugin used by thousands is vulnerable to XSS attack.

XSS flaws are quite difficult to fully remove from a large app even with the modern test tools. XSS vulnerabilities can have consequences such as tampering and sensitive data theft. Therefore, understanding XSS or CSS (not to be confused with css used for styling HTML), how it works is fundamental to avoiding such breach of data.

So what is a Cross-Site Scripting Attack?

A dynamically generated web page includes dynamic generated contents and images mixed with HTM tags and some java scripts. In a typical XSS attack the hacker infects a legitimate web page with his malicious client-side script. His aim is to embed malicious JavaScript, VBScript, ActiveX, HTML, or Flash into a vulnerable dynamic page of a trust worthy site to fool the victim, executing the script on his machine in order to gather data. Because a hacker is able to run a malicious script on the machine of a victim, it allows him to steal a session, user password and other data.

You would think that a hacker will have to break the server to install the malicious script on a good site. That is not often required since a malicious script or a link to a malicious can be embedded simply by filling some user forms. For example, on a forum web site a hacker can add a link in a comment. And when other user reads the comment, he will be unknowingly running the malicious script.

XSS vulnerabilities may occur if:

1. Input coming into Web applications is not validated before storing them in any database
2. Output to the browser is not HTML encoded

Types of XSS Attacks

XSS attacks can generally be categorized into three categories: stored, reflected and DOM based XSS attack.

1. Stored or Persistent XSS Attacks

Stored or persistent attacks are those where the injected malicious script is permanently stored on the target servers. This can be stored such as in a database, in a message forum, visitor log, comment field, etc. The victim then retrieves the malicious script from the server when it requests the stored information. A persistent script is often embedded using many clever techniques under various HTML tags to mask the harmful nature of the malicious script.

2. Reflected or Non-Persistent XSS Attacks

Reflected or Non-Persistent attacks are those where the injected malicious script is reflected off the web server such as in an error message, search result, or any other response that includes some or all of the input sent to the server as part of the request.

There are many ways in which an attacker can entice a victim into initiating a reflective XSS request. For example, the attacker could send the victim a misleading email with a link containing malicious JavaScript or a user can be duped clicking on some fake reward collection form. If the victim clicks on the link, the HTTP request is initiated from the victim’s browser and sent to the vulnerable Web application. The malicious JavaScript is then reflected back to the victim’s browser, where it is executed in the context of the victim user’s session.

3. DOM XSS Vulnerabilities

The Document Object Model is a convention for representing and working with objects in an HTML document. DOM XSS vulnerability occurs when the XSS vector executes as a result of a DOM modification on a website in a user’s browser. On the client side, the HTTP response does not change but the script executes in malicious manner. This is the most advanced and least-known type of XSS. Most of the time, this vulnerability exists because developers do not understand how it works.

How to Protect Your Applications

1. During the Development Stage

The simplest and arguably the easiest form of XSS protection would be to for developers to sanitize any user input.

The normal technique in PHP or .NET or Java is to pass all external data through a filter which will remove dangerous keywords, such as the infamous <script> tag, JavaScript commands, CSS styles and other dangerous HTML markup (such as those that contain event handler. The quality of filter depends on its ability to deal with all possible trick of the trade. Hackers can try to hide malicious scripts using various clever techniques to circumvent simple filters. They use techniques such as hex encoding, Unicode character variations, line breaks and null characters in strings etc. Hence, one must use a filter that is tested, used by large number of users, and updated often.

2. Already Deployed Applications

XSS flaws can be difficult to identify and remove completely from a web application. The best way to find flaws is to perform a security review of the application code and search for all places where input from an HTTP request could possibly make its way into the HTML output. Note that a variety of different HTML tags can be used to transmit a malicious JavaScript. So, the code reviews can reveal many vulnerabilities, and the code can be fixed to sanitize the user input.

Open Source Nessus, and many other available web security tools can help scan a website for many cross site scripting and security flaws. They can help but not fully eliminate the possibilities.

To check for Cross Site Scripting vulnerabilities, use any good quality Web Vulnerability Scanner. A Web Vulnerability Scanner crawls your entire website and automatically checks for Cross-site Scripting vulnerabilities. It will indicate which URLs/scripts are vulnerable to these attacks so that you can fix the vulnerability easily. Besides Cross-site Scripting vulnerabilities a web application scanner will also check for SQL Injection & other web vulnerabilities.

As we mentioned that XSS vulnerabilities can be very difficult to remove. Hopefully, this article will help you to understand them and their associated consequences. It will also help you plan suitable remedial actions.