XSS, also known as CSS (Cross-Site Scripting, not Cascading Style Sheets) is actually one of the most common forms of web application vulnerability, and is becoming just as popular as SQL Injection.
XSS does not only affect end users, having an XSS attack on ones website can cause damage to the trust in the website and the business running behind it. This can cause huge consequences for that said businesses.
There are three types of Cross-Site Scripting, in this post I will cover the first two and if there is enough interest I will cover the third. Don’t be worried about the names, the overview below will explain the differences and why the names came about.
- Stored (Persistent) XSS
- Reflected XSS
- DOM based XSS
Stored (Persistent) XSS
Often referred to as more dangerous than any other form of XSS, a stored attack is embedded into a web application. This is usually done by submitting data from a form, an example of this would be in an open guestbook, blog or forum.
The process of the attack would be close or identical to:
- An attacker submits malicious data to a guest book
- A victim visits this guestbook
- The inserted data which contains the malicious script is displayed and executed in the victims browser
- The victim is then vulnerable to the attack
This type of attack can be prevented by the web application developers doing sufficient checks on the input data, for example not allowing HTML or any other form of script to be entered.
Reflected (Non-persistent) XSS
Reflected attacks are considered by far the most common type of XSS attack around. Such attacks require end user interaction, usually by clicking a link in an email, a message (chat service) or links in your inbox on popular websites, such as Facebook.
These attacks work by an attacker linking a victim to a page which accepts user input through the query string. For example displaying a welcome message on a web page that accepts a name through the query string (Example: domain.com/index.php?name=Steve), where the name parameter is taken and used to display the value in the webpage – but not checked for malicious behavior, for example not checking that the name parameter contains script.
An example of an attack:
- An attacker sends a victim a malformed link
- The victim clicks the malformed link
- Upon opening of the page the script in the malformed link is executed
- The victim is then potentially compromised
This type of attack can also be prevented by the web application developers performing sufficient checks on query data, end users can also protect themselves by only following links from trusted sources. This includes websites and users.
An XSS attack can be potentially damaging to large websites and companies alike. A solution to prevent XSS attacks for web application developers is checking user input while a solution for an end user is to be weary of links provided to you from sources unknown.