XSS Reflected and XSS 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.