Skip to main content

What is Cross-Site Scripting (XSS)?

Today's websites offer more functionality than the old static web pages and provide unique conveniences to their users. As it is known, sometimes convenience also means security problems. In terms of functionality, Javascript is the technology mostly used by websites. Web developers use Javascripts to provide superior convenience for websites users but this turns to a gun in the wrong hands with the use of cross-site (XSS) command. In the OWASP Top 10, XSS is the second most prevalent issue, appearing in nearly two-thirds of all apps. XSS has a serious effect on remote code execution on the victim's browser, such as stealing credentials or delivering malware to him/her.

Some XSS issues can be detected automatically by automated tools, particularly in mature technologies such as J2EE/JSP, ASP.NET, and PHP.

In this article, we will explain what XSS means, what types it has, how it works, how it can be blocked, and how it differs from some other web attack techniques.

What does Cross-Site Scripting Mean?

Cross-Site Scripting (XSS) attacks are injection attacks in which malicious scripts are inserted into otherwise trustworthy and innocent websites. When an attacker uses a web application to send malicious code to a different end-user, generally in the form of a browser-side script, this is known as an XSS attack.

If a web page or web application generates output that contains unsanitized user input, it is vulnerable to XSS. The victim's browser must then parse this user input. In VBScript, ActiveX, Flash, and even CSS, XSS attacks are achievable. They are, nevertheless, most prevalent in JavaScript, since JavaScript is essential to most browser experiences.

Malicious content delivered through XSS can be shown immediately or at regular intervals, such as when a website is loaded or a certain action is taken. XSS attacks are designed to target users of a web application, and they can be especially successful if they appear on a reputable website.

What are the Types of Cross-Site Scripting?

XSS attacks can be divided into five categories:

  1. Persistent XSS
  2. Reflective XSS
  3. DOM-Based XSS
  4. Mutated XSS (mXSS)
  5. Self XSS

1. Persistent XSS

When an application gets data from an untrusted source and incorporates that data in an unsafe way inside its subsequent HTTP answers, this is known as persistent cross-site scripting (also known as second-order or stored XSS ).

Attackers inject malicious scripts into susceptible websites and store them on the server for later use. Users that view web pages receive the payload, which is processed in their context. As a result, the payload can be executed without the victims having to click on a malicious link (as in the case of Non-Persistent XSS). All they have to do is go to a susceptible web page.

2. Reflected XSS

The most basic sort of cross-site scripting vulnerability is non-persistent XSS, also known as reflected XSS, in which a web application reflects and runs JavaScript from unvalidated user inputs.

Cross-site scripting (or XSS) occurs when an application gets data in an HTTP request and incorporates that data unsafely within the immediate response.

Reflected XSS commonly targets search results and error message sites. They frequently send unaltered user input as part of the response without appropriately escaping the data so that it can be safely shown in the browser.

Assume a web site's search feature accepts a user-supplied search phrase as a URL parameter:

https://nonsecure---site.com/search?term=computer

In the answer to this URL, the application echoes the specified search term:

<p>You searched for: computer</p>

An attacker can design an attack like this if the program doesn't perform any further data processing:

https://nonsecure---site.com/search?term=<script>/*You+have+been+hacked+by.....*/</script>

This URL results in the following response:

<p>You searched for: <script>/* You+have+been+hacked+by..... */</script></p>

If some other application user visits the attacker's URL, the script given by the attacker will run in the target user's browser, in the context of their session with the program.

3. DOM-Based XSS

The Document Object Model is a programming interface that allows developers to access and edit documents (web pages) by executing operations. As a result, this interface specifies the structure of documents by linking the scripting language to the real webpage.

DOM-based XSS, also known as Type-0 XSS, is an XSS attack that executes the payload via modifying the DOM in the victim's browser. Without the user's knowledge or consent, the client executes code.

4. Mutated XSS (mXSS)

Mario Heiderich (Cybersecurity Researcher) identified a new kind of XSS vector, the mutation-based XSS (mXSS) vector. This mXSS might be found in innerHTML. This issue affects popular browsers such as Internet Explorer, Firefox, and Chrome.

The mXSS is an XSS vector that has been modified from a safe to a dangerous unfiltered condition. The assumption shared by both server-side and client-side XSS filters is that their HTML output and the browser-rendered HTML content are almost similar. The most prevalent type of mXSS is caused by erroneous innerHTML reading. The browser alters the user-supplied content such that a seemingly innocent string passes virtually all XSS filters and is eventually turned into an active XSS attack vector.

5. Self-XSS

Self-cross-site scripting (XSS) is a vulnerability in web applications that allows the same user to execute JS but not other users. Self-XSS is a type of social engineering attack. In the Self-XSS attack method, the attacked user executes the malicious code himself, thinking that it serves another purpose. Web accounts can be compromised with the Self-XSS attack method. Facebook accounts come first.

How Does Cross-Site Scripting Work?

Cross-Site Scripting is a dynamic web page security issue in which an attacker may build a malicious link to inject undesired executable JavaScript into a Web site. The most common instance of this vulnerability arises when GET variables are written or echoed without being filtered or checked for content.

When a victim opens the link, the malicious code may transfer the victim's cookie to another server, or it may change the affected site by inserting forms, stealing usernames and passwords, and employing other phishing methods.

How to Find and Test for XSS Vulnerabilities?

Cross-site scripting (XSS) is one of the most frequent online application vulnerabilities. XSS, if left unpatched, can expose your application to a variety of security vulnerabilities. We explain how to detect XSS in web apps and what you can do to avoid it.

Manually Code Auditing and Run Tests

The goal of code review is to detect security problems in programs as well as the fundamental causes. It entails evaluating an application's source code to guarantee that it is self-defending in its specific context. "If code has not been reviewed for security holes, the likelihood that the application has problems is virtually 100%," according to OWASP.

The manual procedures listed below can be used to discover typical XSS vulnerabilities:

  • Find the code that produces user input.
  • Verify that the output is encoded.
  • Determine the code that handles URLs.
  • Your codes should be unit tested.
  • Perform basic checks on your application.

Automated Application Testing

To test and detect XSS vulnerabilities in online applications, standard security testing methodologies and tools may be used. Some of the most common testing methodologies are as follows:

  1. Static Application Security Testing (SAST):

When an application is not operating, SAST is used to protect it by evaluating the source code to find vulnerabilities or evidence of known unsafe practices.

  1. DAST (Dynamic Application Security Testing):

DAST tools interact with apps to uncover possible security flaws via the front-end. DAST tools do not have access to source code; instead, they conduct attacks to find vulnerabilities using the black-box technique.

  1. IAST (Interactive Application Security Testing):

IAST combines the greatest features of SAST and DAST. It examines code for XSS and other security flaws when the app is being used by any activity that interacts with the application functionality.

You may easily test and identify XSS vulnerabilities in your web apps using the approaches mentioned above. Web vulnerability scanners like Netsparker, Acunetix, Veracode, Checkmarx, and others are sophisticated tools that can crawl your whole website or application and check for XSS and other security issues automatically.

What can XSS be Used For?

The attackers can take advantage of a cross-site scripting vulnerability to be able to accomplish the below-shared activities:

  • Hijacking user's session: Most online applications keep track of user sessions so that the user can be identified across many HTTP requests. Session cookies are used to identify sessions. The Set-Cookie header is used by the server to send you a session cookie once you successfully log in to an application. Now, whenever you view a page in the application or submit a form, the cookie (which is now kept in the browser) is included in all requests made to the server. This way, the server will recognize you. Attackers can employ XSS to hijack a user's session by impersonating the genuine user and gaining access to his/her current web session.
  • Perform unauthorized activities: If the HTTPOnly cookie property is set, an attacker will be unable to steal cookies using JavaScript. However, the attacker can still take illegal operations inside the program on behalf of the user via the XSS attack.
  • Phishing to steal user credentials: XSS may also be used to inject a form onto the vulnerable website and gather user credentials using this form. This is referred to as phishing.
  • Capture the keystrokes by injecting a keylogger: Attackers can inject a JavaScript keylogger into the vulnerable web page and capture all of the user's keystrokes on the current page. This sort of attack can be done by using XSS
  • Stealing sensitive information: Stealing sensitive information from the user's current session is another dangerous behavior that an XSS attack may accomplish. Assume an online banking application is vulnerable to XSS, and the attacker has access to the current balance, transaction details, personal data, and so on.

How to Prevent XSS Attacks?

In this part, we will present a basic affirmative model for avoiding XSS by appropriately encoding output. While there are several XSS attack routes, adhering to a few basic guidelines will entirely protect against this dangerous attack.

  • RULE #0: Only insert Untrusted Data in Allowed Locations.

  • RULE #1: Encode Untrusted Data Before Inserting It Into HTML Element Content

  • RULE #2: Encode Untrusted Data Before Inserting It Into HTML Common Attributes

  • RULE #3: Before inserting untrusted data into JavaScript data values, use JavaScript Encode.

  • RULE #4: Before inserting untrusted data into HTML Style Property Values, CSS Encode and Strictly Validate.

  • RULE #5: Before Inserting Untrusted Data into HTML URL Parameter Values, Encode the URL.

  • RULE #6: Sanitize HTML Markup using a Job-Specific Library

  • RULE #7: Avoid using JavaScript URLs.

  • RULE #8: Prevent DOM-based XSS.

How do I Prevent XSS in Java?

JSPs (Java Server Pages ) are loaded with danger. HTML escaping in JSP templates necessitates escaping all data rendered on the page. Worse, scriptlets may be used to incorporate business logic into JSPs. This is easy to overlook or abuse, and it can lead to XSS vulnerabilities. The safest choice should be the default:

  • Consider utilizing an escape-by-default view or template engines, such as JSF or Velocity. If you are unable to transition to another framework, utilize a custom EL resolver that applies to escape by default in JSPs, such as Oracle ELresolver otherwise, all data MUST be escaped.
  • Scriptlets should not be used.
  • Check your project for these conditions:
semgrep --config p/minusworld.java-httpservlet-jsp-xss

What is the Difference Between XSS and CSRF?

Cross-site scripting (also known as XSS) allows an attacker to run arbitrary JavaScript in a victim's browser.

An attacker can employ cross-site request forgery (or CSRF) to get a vulnerable user to do something they didn't want to do.

  • CSRF usually only affects a portion of the actions that a user can complete. Many apps deploy CSRF safeguards in general, but one or two actions remain vulnerable. A successful XSS attack, on the other hand, may generally persuade a user to execute any action that the user is capable of, independent of the feature where the vulnerability exists.
  • CSRF normally only impacts a small percentage of a user's actions. Many apps have CSRF protections in place, but one or two actions are still susceptible. In contrast, a successful XSS attack can persuade a user to perform any action that the user is capable of, regardless of the feature where the vulnerability occurs.

What is the Difference Between XSS and SQL Injection?

SQL Injection is another technique used by hackers, in which a hacker inserts malicious code into SQL queries via a web page input. This injection allows the hacker to interrupt the user's system and, in general, allows the attacker to access data that they would not otherwise be able to get. Hackers can get access to information that the user does not have, and by modifying these programs, the hacker can eventually change the program's content. Hackers can conduct this sort of hacking in a variety of methods, all of which can be quite successful in gaining access to user information.

The XSS and SQL injection methods are both common among hackers, and they are both used to achieve their aims; nevertheless, the crucial thing to note is that these two methods have distinctions, among which we can highlight the language used to write malicious code and the way these scripts function.

  • The primary distinction between a SQL injection attack and an XSS injection attack is that SQL injection attacks are used to take data from databases, whereas XSS attacks are used to send users to websites where attackers may steal data from them.
  • SQL injection is designed to target databases, whereas XSS is designed to attack end-users.
  • Cross-site scripting is more popular and employed in JavaScript, whereas SQL Injection covers Structured Query Language.
  • SQL injection is a server-side vulnerability that targets the program's database, whereas XSS is a client-side vulnerability that targets other application users.
  • XSS is often written in JavaScript, whereas SQL injection uses Structured Query Language (SQL). As a result, this is another distinction between XSS and SQL injection.

How common is XSS?

Cross-site scripting is by far the most prevalent form of online application vulnerability, appearing in every edition of the OWASP Top 10 list since its inception. At the same time, it is thought to be less dangerous than SQL injection or command execution. Even if the malicious JavaScript code is run on the client-side and does not directly affect the server, XSS vulnerabilities are nonetheless harmful.

It is estimated that more than 60% of online applications are vulnerable to XSS attacks, which account for more than 30% of all web application attacks.

So far in 2021, 16378 security vulnerabilities (CVEs) have been revealed. There will be 17039 in 2020.

The average severity is 7.1 out of 10, which is similar to what it was in 2020.

2020 Web of Number Vulnerabilities according to weakness

Figure 1. 2020 Web of Number Vulnerabilities according to weakness