Yes, technological advancements are incredible. But, as you are probably aware if you are reading this post, not everything in the digital world is perfect. If you’ve ever asked, “What is cross-site scripting?” or “How do I avoid cross-site scripting attacks?” you’re probably aware that browsing the internet isn’t without its dangers (think drive-by download attacks). We can avoid the carefully laid traps set by cybercriminals by arming ourselves with intelligence and a few resources.
This article takes a move toward that popular goal by discussing one of the most common web application vulnerabilities today: cross-site scripting attacks.
XSS Attacks: What Is Cross Site Scripting?
Cross-site scripting (XSS) is a code injection technique that can affect either the client or the server. Over the years, XSS has continued to appear in the OWASP top vulnerabilities lists. Though it has fallen down the list, this isn’t actually due to a decrease in the risks, but rather to other risks being more serious. But what is cross-site scripting, and why is it so important?
In order for an XSS attack to succeed, three actors must be involved: an intruder, a victim, and a vulnerable web application. The aim is to take advantage of the victim’s confidence in the website or application by exploiting their interactions. A threat actor in an XSS attack:
Now that we have a better understanding of what cross-site scripting is, let’s look at how it functions in more detail and look at the different forms of XSS before we look at how to avoid cross-site scripting.
How Cross Site Scripting Works
Assume your local library has a website where you can browse the catalogue and see if the book you want to read is in stock or in circulation. You go to the web, type your search query, and when you send the request, the created URL could look like this:
The library’s backend database is queried in the background to see if the book you’re searching for is in their database. If it is, their device verifies that it is available before displaying the results page. In a vulnerable web app, however, if a malicious query is submitted for processing instead of a legitimate one, the script will run in the user’s browser, as shown below:
https://mylibrary.com/search?query=<script>alert(“This could have been malicious!”)</script>
Despite the fact that the resulting page is based on your search query, no part of the user feedback should be used in rendering the page without first being completely stripped of any malicious markup. Treating all user information as untrusted data and using correct encoding or output escaping techniques is one way to do this.
Types of Cross Site Scripting Attacks (XSS Attacks)
According to OWASP, there are three types of XSS attacks: mirrored, stored, and DOM-based. The aim of these attacks, in the end, is to steal sensitive information from users and conduct sensitive operations by exploiting vulnerabilities in vulnerable web applications.
Let’s take a closer look at each of these categories:
An attacker uses a reflected XSS attack (also known as non-persistent XSS) to trick the victim into making a request that they can manipulate. The threat actor either embeds malicious links on their own websites or persuades the victim to click on a connection sent via email, SMS, or social media.
Finally, if you look at existing phishing numbers, you’ll see that convincing unsuspecting users to click on unknown links isn’t one of the most challenging tasks in the world. While in charge, the intruder may steal cookies, account information, or impersonate legitimate users to carry out operations while the application is unaware.
Reflected XSS is more popular than stored XSS, despite the fact that it is less risky. What makes it even more dangerous is that it could be used to create a malicious URL on any page that accepts a user-modifiable parameter through a GET or POST request and returns the parameter to the user.
When an attacker injects a malicious script directly into a vulnerable web application, this is known as stored XSS (also known as a second-order or persistent XSS attack). The information entered into the application can come from a variety of places, including comments, posts from social media sites, and so on.
A message board on a website that enables HTML tags to be inserted, for example, can be used to store malicious scripts, as seen in the diagram below. Any user who accesses the site can see the script run as part of the application.
DOM Based XSS
The Document Object Model (DOM) is a language-independent convention for defining and dealing with objects in an XML or HTML document using a tree structure.
To get a better understanding of how DOM XSS functions, consider the following example.
Assume that a dashboard for displaying revenue projections can be made in a variety of languages based on user preference, with English as the default language. The following URL will take you to the website.
Since the portion of the URL after the “#” is not received by the server, DOM XSS may not show up in server logs. The client browser connects to example.com via HTTP and loads the static HTML tab. It populates the document.url property with the malicious connection while building the DOM. When the browser parses the page, it extracts all of the content from the document.url object and runs the script.
You should be able to address the question “what is cross-site scripting?” and know how dangerous it can be if your application is vulnerable to this attack at this stage. As a result, identifying and addressing these threats is important. Let’s take a look at how to avoid cross-site scripting and what measures we should take to protect our applications from a security violation caused by an XSS flaw.
How to Prevent Cross Site Scripting
The method you use to fix XSS vulnerabilities is determined by a few factors:
The location of the bugs, the application’s sophistication, and the way the web app handles dynamic content or user-controllable data are all factors to consider.
When it comes to preventing cross-site scripting, we can use a combination of the countermeasures mentioned below to avoid XSS vulnerabilities from emerging in our application:
The data should be input filters based on expected values that fall within the constraints you identify at the application’s entry points where user input is accepted (with reasonable restrictions on the permitted set of characters).
Apply validation checks to see whether the data approved can be an integer, can be alphanumeric, and so on if a new user is filling out the user registration form and there are fields like name, age, region, city, and so on. Filter var(), a built-in filter, or functions like is numeric(), preg match(), and others can be used to accomplish this. To sanitise user-supplied data, different languages have different functions that can be used.
Additionally, instead of manually punching in values, use dropdown lists, calendars, and other similar resources where possible.
Wherever there’s a chance that user input strings will be expressed in output responses, encode them to prevent them from being perceived as active information, depending on the output context. The use of URLEncode, HTMLEncode, and other encoding methods, as well as performance escaping, reduces the possibility of executing a malicious script. In response headers, specifically define appropriate headers and character sets and disallow modifying encoding types. Consider the following scenario:
Content-Type: text/html; charset=ISO-8859-1
Discarding Unsafe Script Insertion Points
Inserting user-supplied data into existing script code enables attackers to gain control of the context of the data they can exploit, which can be used as a springboard for malicious behaviour.
When it comes to applications (like blogs) where users need to be able to use HTML tags for formatting, whitelisting can be a safe choice if only a small subset of HTML tags are allowed. The application’s confidence may, however, be violated. Instead, try using an intermediate markup language, which the framework can translate to HTML markup.
Other mitigation strategies include:
- Cookie security (using HTTPOnly flag),
- Using content security policy (CSP) to prevent XSS,
- Employing appropriate modern frameworks, and
- Applying the X-XSS-Protection Response Header.
According to a TrustWave study from 2018, applications vulnerable to XSS accounted for the largest share of high-risk vulnerabilities among the most important vulnerabilities. While we haven’t gone into the particular tactics used in these attacks (we don’t want to support budding black hat hackers, after all! ), we hope this has answered your question about what cross site scripting is. We’ve also spoken about the different ways of cross-site scripting and tried to discuss how to avoid it.
An XSS, alone or in conjunction with other security vulnerabilities such as cross-site request forgery (CSRF), may be used to steal confidential information from users (such as usernames and passwords), manipulate or track the victim’s browser remotely, or participate in other nefarious activities. Conducting routine vulnerability scans and manual penetration checks to detect and remediate these risks as soon as possible is in the best interest (and that of your consumers or users).