Cross-site scripting (XSS) is one of the most common OWASP vulnerabilities, affecting both small businesses and giant corporations. OWASP is a non-profit organization with the goal of enhancing the security of software and the internet.
What is Cross-site Scripting (XSS)?
Cross-Site Scripting (XSS) attacks are a sort of injection, during which malicious scripts are injected into otherwise benign and trusted sites. XSS attacks occur when malicious actor uses a web application to send malicious code, typically in the form of a browser side script, to a distinct user. Flaws that permit these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user among the output it generates without validating or encoding it.
An attacker will use XSS to send a malicious script to an unsuspecting user. The user’s browser has no way to understand that the script should not be trusted, and will execute the script. As a result of it thinks the script came from a trusted source, the malicious script will access any cookies, session tokens, or sensitive information maintained by the browser and used that website. These scripts can even rewrite the content of the HTML page.
How Does XSS Attack Occur?
Typically, a cross-site scripting attack takes place as follows:
Attackers discover that a web page that accepts users’ inputs is susceptible to XSS attacks. It may be accepting users’ inputs via comment boxes, login forms, or search boxes.
The attackers create a malicious script (payload) and redirects it to an unsuspecting user. They could insert the payload into a phishing link and lure the victim into clicking it.
When the victim clicks the malicious link, they are redirected to the vulnerable web page, that the victim hitherto trusts.
The payload is injected into the vulnerable web page, and the victim’s web browser treats it as legitimate source code.
When the unsuspecting user enters some inputs and submits them, the payload gets executed based on the attacker’s instructions.
Types of Cross-Site Scripting Attacks
Cross-site scripting attacks are generally categorized into two main groups:
Non-persistent attacks (Reflected attacks)
Persistent attacks (Stored attacks)
Non-Persistent Attacks (Reflected Attacks)
A non-persistent attack, conjointly referred to as a reflected attack, is a sort of XSS attack that takes place when the web application returns a response that contains some or all of the attack vector. The vulnerable application basically reflects (or displays) the injected script, and doesn’t store it.
The non-persistent attack needs a vulnerability that enables user input to be returned properly sanitizing the information. For instance, it can exist in an error message, search result, or any response that contains user-provided information.
Reflected XSS attacks are typically delivered to the victims via innocent-looking avenues, like phishing emails, obscured URLs on websites, or malicious links on text messages.
In case the unsuspecting user clicks the crooked link, submits a corrupted form, or perhaps simply visits an unscrupulous website, the malicious script moves to the vulnerable web application and gets injected into its source code. The application can then reflect the payload on the victim’s browser, which executes the code as a result of it, came from a “trusted” origin.
Persistent attacks (Stored attacks)
A persistent attack, conjointly referred to as a Stored attack, is a form of XSS attack that happens once the malicious code is permanently stored on the server of the vulnerable web application. As a result, the malicious code is conferred to the victim anytime they perform a desired action on the corrupted web content.
The persistent cross-site scripting attack takes place similar to the non-persistent attack the only distinction is that the former’s injected code is saved constantly on the application.
There are also other less common flavors of XSS flaws that get their own grouping based on the person you’re talking to. These are:
In DOM-based XSS attacks, the cybercriminal takes advantage of the various techniques for accessing a web page’s DOM elements, and uses them to stage an attack.
Just like a reflected cross-site scripting attack, a DOM-based attack is delivered via a URL containing a malicious script. However, rather than loading the payload within the HTTP response, the attack is administered by maliciously manipulating the DOM surroundings.
A self-XSS attack is a variant of cross-site scripting attack that uses social engineering techniques to trick victims into running the harmful script themselves. For instance, a user is lured into copying and pasting harmful code into their own web browser’s address bar.
This type of attack may not be considered of as a “true” cross-site scripting attack as a result of it depends on socially engineering a user instead of leveraging a particular vulnerability on the web application. Nonetheless Self-XSS attacks can still lead to similar damages as other types of attacks, if carried out appropriately
Impact of cross-site scripting vulnerabilities
Read all cookies (that don’t seem to be protected by Http only), together with session cookies. By doing so, an attacker could take over the session.
View anything the user sees, and steal sensitive information.
Change what the user sees and manipulate information
Basically do everything a standard user could, because the attacker see and alter anything given to the user. This includes bypass of all CSRF-protections. To put it into context; if the attacker successfully tricks an admin to execute the XSS, the attacker can do everything an admin may do.
Do things that the vulnerable domain has access to do, which may obtain access to the user’s web camera, microphone or location.
How to Determine If You Are Vulnerable
How to Prevent XSS Attacks
Do not trust any user input
Since each user input on a web page introduces a risk of a cross-site scripting attack, you must treat them as untrusted and validate them as much as possible.
A simple effective technique you’ll use is to pass each inputted data via a security filter that detects and removes harmful keywords.
You can configure the filter to spot some common scripting strings that don’t seem to be expected from the inputted information and forestall them from being executed. An example of such a scripting string is the HTML <SCRIPT> tag.
This technique modifies certain standard characters within the user’s data and ensures they’re not taken as active content.
It’s suggested to use existing libraries for escaping or encoding the user’s information.
If the user’s generated content contains HTML, escaping or encoding them could break all the valid tags. You need to use a security-focused library for parsing and cleaning the HTML formatted text in such cases.
Use Content Security Policy (CSP)
CSP is a browser-side mechanism that lets you white list the trusted sources in HTTP headers. You can use the technique to approve sources of content that browsers are permitted to load on your website.
Scan Regularly To Mitigate XSS Vulnerabilities
Apart from the earlier mentioned XSS hindrance strategies, it’s vital to scan your codebase often for the presence of cross-site scripting vulnerabilities. Using external libraries might introduce XSS vulnerabilities in your application. If you import a compromised library into your project, it can be a large security risk.
Therefore, you would like to frequently scan your web applications employing a powerful automatic scanner, like the WhiteSource Bolt. It’s a free tool that permits you to search out and fix open source vulnerabilities in your web applications. Bolt is the tool you need to code with confidence and ward off security risks from your project, as well as XSS vulnerabilities.
Cyber Security Hive with its Cloud-based, AI-powered Vulnerability Management and Penetration Testing Platform called ThreatScan would be able to identify all the cross site scripting vulnerabilities in your application.