Cross Site Scripting in JavaScript: Everything You Need to Know
What is Cross Site Scripting (XSS)
With Cross Site Scripting, attackers execute malicious JavaScript within a victim’s browser to steal session cookies and impersonate a user, as well as using XSS to deface websites, spread malware, phish for user credentials, support social engineering techniques, and more.
In this article:
- Types of XSS
- How XSS Vulnerability Happens in JavaScript
- How to Prevent Cross Site Scripting Attacks in JavaScript
- XSS Protection in JavaScript using Bright
Types Of XSS
There are three types of cross site scripting, namely:
- Reflected XSS
- Dom-based XSS
- Stored XSS
Reflected XSS
Reflected XSS occurs when the website allows for malicious scripts to be injected into it. An attacker then sends the link of the targeted website containing the malicious script to other users. Once the link (mostly anchor links) is opened, the script executes and the attacker is able to steal the user’s session cookies.
This is an efficient attack as it allows for the script to fire off every time a new user opens the malicious link.
For example, a website “https://www.vulnerable-website.com/” could have a search functionality that would look like: https://www.vulnerable-website.com/search
Once the user inputs the data into the search field, the url would look like this:
https://www.vulnerable-website.com/search/?input=”test”
However, the lack of proper sanitization could result in malicious code being injected into the input value. It would look something like this:
https://www.vulnerable-website.com/search/?input=<script>/*snippet of dangerous code*/</script>
This is all that’s required for an attacker to spread the malicious code to every visitor using this link, and is why Reflected XSS is so dangerous and widespread. Additionally, it doesn’t even need to store the data to the servers of the web application, allowing it to fly under the radar.
DOM-based XSS
Dom-based cross site scripting is mainly used for hijacking the user sessions, allowing the attacker to gain unauthorized access to the website.
An attacker sends the malicious code to vulnerable functions such as eval(), prompting JavaScript to execute the code via the said function. As a consequence, the victim application runs the malicious script, giving the attacker access.
Stored XSS
Stored XSS attacks use HTTP requests to gain unauthorized access and exploit vulnerabilities on the website.
Simply put, the attacker exploits the lack of input sanitation and manages to add malicious JavaScript code to the request. If the website requests an input field, the lack of proper sanitation allows the attacker to introduce this code, exploiting vulnerabilities on the website.
Any user that opens the affected page of the website is affected, given that the malicious code executes in the browser.
How XSS Vulnerability Happens in JavaScript
There are multiple ways to inject an XSS vulnerability in JavaScript. In fact, JavaScript is the weak point of most websites and applications, given that JavaScript can dynamically add content to the rendered page. If an attacker manages to send their own snippet of JavaScript code to the server, it will execute and result in potentially dangerous attacks to your web application.
The primary cause for this is due to a lack of input sanitisation by the developer. This occurs predominantly with contact forms or similar input fields. If they aren’t handled properly, the attacker can inject their malicious code into that input field, causing the website to run the malicious code.
A good example of a dangerous snippet of code on a website is innerHTML. This allows the attacker to directly modify the website by sending malicious data via JavaScript, and executing it using innerHTML.
How to Prevent Cross Site Scripting Attacks in JavaScript
There are a few popular methods in preventing Cross Site Scripting attacks:
- Input validation
- WAF (Web Application Firewall)
- Content security policy
Input Validation
The best way to prevent cross site scripting attacks is to ensure every input field is validated.
You should always replace sensitive characters that may cause disruption with their entities. Even though they display the same way, entities cannot generate HTML, saving you potential failures in the future.
There are many ways in which you can validate the user’s input using JavaScript, such as using vanillaJS, or external libraries such as jQuery’s validator, which is highly regarded for its simplicity in practical terms.
Even though it’s often impossible to do so, try restricting the user input to a specified list whenever you can, such as when selecting a currency, country, etc.
WAF
Another method of defending against XSS, as well as various other attacks, is by using a Web application firewall (WAF). which continuously monitor and intercept these attacks. However, WAFs should be used as a last-resort defensive measure and do not offer 100% protection – being secure by design should be your main priority.
Content Security Policy
Creating content security policy (CSP) is perhaps the most efficient way of preventing XSS and other vulnerabilities. It prevents XSS by white-listing URLs the browser can load and execute JavaScript from. By specifying specific CSP directives, the server prevents the browser from executing any JavaScript that comes from an untrusted URL. The CSP works as a white list, where only domains listed are allowed to execute and everything else is blocked.
XSS Protection in JavaScript with Bright
As a developer, being able to easily detect and fix XSS issues before they hit production is a must.
With Bright you can easily detect XSS, either as a standalone scanner or fully and seamlessly integrated into your development pipelines, with NO false positives.
Sign up for a FREE account here to start scanning your web applications and APIs today
