Cross-site scripting (XSS) is a client-side computer attack conducted when malicious scripts are inserted into a legitimate website or web application. The malicious scripts introduced are usually called a malicious payload. Currently, XSS is the most common form of vulnerability in Web applications. This happens when a particular web application uses input of unencoded or unvalidated users in the data this produces.
XSS lets an attacker indirectly target a victim. In other words, the attacker exploits a loophole which the victim may access inside a website or web application, using it as a tool to deliver the malicious script to the victim’s browser.
One of the most dangerous attacks for web applications is an XSS attack, as it can have serious consequences.
As seen above, the script is a print from the most recent comment from a collection of comments. If the page is vulnerable a message that contains a malicious payload such as XSS may be sent by an attacker:(<script>dosomethingEvil();</script>)
The next HTML on the website is then served to the web page user
The malicious script will run as soon as the page loads into the victim’s browser. For most cases the victim is unaware of the attack, and therefore unable to avoid it.
Example XSS Attack
Below is an comprehensive list of XSS attack vectors that attackers use to jeopardize the security of a website or web application.
Using the onload attribute, the XSS payload can be set inside the body tag.
The iframe tag helps embed another HTML page into the parent page. The iFrames offer an effective way to disable phishing attacks.
The link tag may be infected with scripts, as it is often used to link to sheets of external styles.
The table and cell (td) tag frame trait can be used to connect to a script, rather than an image.
The div tag may embed a script, too.
An external site may include a script with the object tag.
Types of Cross-Site Scripting Vulnerabilities
Three types of XSS vulnerabilities exist: XSS Stored, XSS Mirrored, and XSS DOM Based.
Vulnerabilities of Stored XSS occur when malicious payload is saved. Stored cross-site scripting is quite scary for a few reasons: The payload is invisible to the XSS filter of browsers, and when users visit the page they inadvertently cause the payload.
The vulnerability of the Reflected XSS is created when the user input from a URL or POST data is shown on the page without saving. Typically, this kind of payload is detected by built-in XSS filters in Chrome, Internet Explorer or Edge browsers.
DOM Based XSS
In the DOM (document object model) the bug exists, rather than the HTML.
The effect of XSS vulnerabilities varies, which can include CSRF attacks, hijacking session, tokens, and more. An attacker can trick the user by using an XSS vulnerability to taking control of their account. If the user has administrative rights, an attack can also lead to code execution on the server, depending on the program and the privileges of that account.
To steer clear of vulnerabilities in cross-site scripting, implementation of context-dependent output encoding is important. For a few instances, special characters such as opening and closing tags are necessary to encode the HTML. In other cases the encoding of URLs is necessary.
Web browsers today come with an integrated XSS filter but they can’t monitor all kinds of cross-site scripting attacks. To mitigate the effect of known vulnerabilities, a browser’s XSS filter should be considered one line of protection only.
Web developers should stop using blacklists, since they can be bypassed. We should also avoid deleting hazardous functions and characters as XSS filters of browsers are unable to detect the dangerous payloads when the output is manipulated, allowing for potential bypass.