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=...alert('You just found a XSS vulnerability')
<script></script>
tags, they would be html encoded and not cause the vulnerability
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
</script></script> 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