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.
XSS will take advantage of outdated and/or obsolete VBScript, ActiveX, and Flash scripts and also JavaScript as this is the basis of most browsing experiences.
XSS Attack
One of the most dangerous attacks for web applications is an XSS attack, as it can have serious consequences.
The attacker has the payload inserted into a vulnerable web page. When the victim visits the website-mostly as a result of the attacker’s social engineering tactics-the malicious JavaScript code runs in the browser of the user. Below is the pseudo-code on the server side usually used to display a web page ‘s current message.
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.
script tag
The script tag may use external JavaScript code or insert the code into the script tag and is considered the simplest XSS payload.
body tag
Using the onload attribute, the XSS payload can be set inside the body tag.
img tag
Some browsers will execute JavaScript found in the tag of the img.
iframe tag
The iframe tag helps embed another HTML page into the parent page. The iFrames offer an effective way to disable phishing attacks.
link tag
The link tag may be infected with scripts, as it is often used to link to sheets of external styles.
table tag
The table and cell (td) tag frame trait can be used to connect to a script, rather than an image.
div tag
The div tag may embed a script, too.
object tag
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.
Stored XSS
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.
Reflected XSS
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.
XSS Prevention
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.