Cross Site Scripting Overview

Cross Site Scripting vulnerabilities are sometimes referred to XSS or CSS vulnerabilities. Typically XSS is preferred over the use of CSS. CSS typically refers to the Cascading Style Sheet commonly used in website design. XSS vulnerabilities are a dangerous type of attack. Especially since the sudden infusion of the Internet and all the many web applications that are on the Internet. Typically a website that uses dynamic content are the only websites that can have a Cross Site Scripting vulnerability, which is the majority of websites out there today. There are two types of XSS attacks. Reflected and stored.
What is a Reflected Cross Site Scripting vulnerability

The malicious user has discovered that a field within a website or web application holds a XSS vulnerability. This malicious user then crafts a way to use the vulnerability to execute something malicious to some unknown user. Reflected XSS vulnerabilities occur when a unknowing user is directed to a web application that has a XSS vulnerability, by the malicious user. Once the unknowing user gets to the web site or application the malicious user’s attack is executed.

The attack is crafted by a series of url parameters that are sent via a url. The malicious user then sends his/her malicious url with the url parameters to unknowing users. This is typically sent by email, instant messages, blogs or forums, or any other possible methods.

You think that the unknowing user would not click on some link that looked like it does something bad. But the reflected attack can occur using javascript that once an email is opened or even the website is viewed the attack is executed. Additionally the attack is typically url encoded, hex coded, or some other encoding method to try and make the url appear as something valid.
What is a Stored Cross Site Scripting vulnerability

A Stored Cross Site Scripting vulnerability occurs when the malicious user can store some attack which will be called at a later time upon some other unknowing user. The attack is actually stored in some method to be later executed.

The storage of a method could involve a database, or a wiki, or blog. Basically the malicious user has stored some type of attack, that when an unknowing user will encounter this, the attack will be executed. The stored method actually not only has the problem of incorrect checking for input validation, but also for output validation. Even if data has been sanitized upon input, it should also be checked for in the output process. By checking and validated the output, you could also uncover unknown issues during the input validation process.

Stored Cross Site Scripting vulnerabilities typically are more dangerous than reflected. The reason being is that the reflected attack is a dynamic attack, while the stored attack can just be set once. That does not mean that you should only test for Stored Cross Site Scripting vulnerabilities. Both should be tested for and both should be fixed. XSS vulnerabilities and attacks are very common today and you don’t want your software application to ship will one or more of these types of vulnerabilities.

There is another method that a Stored Cross Site Scripting vulnerability could be executed. If a database is shared with other applications, be warned, another application could stored a cross site scripting attack and your application could use the same content. If you have no ability to test or verify that the data stored by the other application is validated, then remember your application must validate the output of the message. If the application does not validate the output then even though you have validated your input, your application could still be vulnerable.

Remember to always check all methods that data could be stored and retrieved. Just because input is validated, does not mean that some other method or application could store malicious data which your application could recall.
How to test for XSS Injection vulnerabilities

You can determine if a web-based application is vulnerable to XSS attacks very easily. A simple easy test is to take a current parameter that is sent in the HTTP GET request and modify it. Take for example the following request in the browser address URL bar. This url will take a name parameter that you enter in a textbox and print something on the page. Like “Hello George, thank you for coming to my site”

http://www.yoursite.com/index.html?name=george

And modify it so that add an extra some additional information to the parameter. For example try entering something similar to the following request in the browser address URL bar.

http://www.yoursite.com/index.html?name=

If this pops up an alert message box stating “You just found a XSS vulnerability”, then you know this parameter is vulnerable to XSS attacks. The parameter name is not being validating, it is allowing anything to be processed as a name, including a malicious script that is injected into the parameter passed in. Basically what is occurring is normally where the name George would be entered on the page the message is instead being written to the dynamic page. The alert message just is an example of how to test for the XSS vulnerability. A malicious hacker would be much more devious to this type of security vulnerability.

There are many, many different methods to test for XSS vulnerabilities. This only describes a few of the different methods to test for a XSS vulnerability.
How do you fix XSS vulnerabilities?

Input Validation is very important. (Seems like a theme here) The developer needs to validate the input as it’s coming in. But additionally the output needs to be verified. The output should be correctly html encoded. If the output is correctly encoded, then instead of executed the tags, they would be html encoded and not cause the vulnerability