XSS – Cross-site Scripting: A Comprehensive Guide.

XSS – What Is Cross-Site Scripting?

XSS or Cross-Site Scripting is a type of vulnerability in web applications or websites. This is as well known as a client-side attack in which the attacker injects and runs a maliciously made javaScript or payload into a legitimate web page. In an easier term, it is a code injection attack that allows an attacker to execute malicious JavaScript in a victim’s browser.

XSS - Cross-site Scripting: A Comprehensive Guide.
XSS – Cross-site Scripting: A Comprehensive Guide.

Unlike, other exploits, the XSS, an attacker or a hacker does not directly target his victim. What is does is, he finds the vulnerability in a web application or a website and injects the malicious script. When the victim visits the webpage, his browser runs the malicious JavaScript. From the victim’s perspective, the XSS appears to be a legitimate part of the website. When his browser runs the script, the malware is delivered to the victim’s computer without his knowledge.

Sometime XSS is also being used to deface the website. The attacker can use injected malicious scripts to replace the content of the website, or he can redirect the browser to another web page or place an iframe to completely hide the original website and show his fraudulent website to the visitor to sell his fake products instead of legitimate products from the legitimate website.

The XSS also being used to reproduce or distribute viruses and malware. The famous example is what happened when Twitter was infected with the StalkDaily worm in 2009.

How Does The XSS Vulnerability Triggers In A Web Application?

Normally XSS vulnerability triggers when a web application or a website takes data (as a parameter) from users and dynamically processes it in the web pages or a backend database without first properly validating the data. When a developer develops a web application that uses unsanitized user input (Unsanitize inputs means storing the user input without checking or validating before storing it in a database.) in the output that sends to users. As you may already know, JavaScript is dangerous. JavaScript can be dangerous if the proper precautions are not taken.

Once the attacker finds the vulnerability in his target web application, he needs to find a way to install/ inject malicious JavaScript into that webpage. Normally the whole web application will not be vulnerable, but one or two pages or a single input-form like the in-app search bar or messaging-board in an entire application could be vulnerable.

After the successful injection, the attacker expects his victims to visit the page so that the malicious code installs into his browser or execute it. Also, sometimes attacker uses “Social Engineering” methods or phishing attacks to target a particular set of targets.

How Does The XSS Vulnerability Triggers In A Web Application?
Image credit: aqusagtechnologies.com
How Does The XSS Vulnerability Triggers In A Web Application?
Image credit: aqusagtechnologies.com

What Are The Different Types of XSS Attacks?

XSS attacks are categorized into there main types.

Reflected XSS

Reflected XSS triggers when the data sent from the victim’s browser is used by the Server-side script to generate the result or output for that user. If the data is invalidated by the Server, which will include in the page without HTML encoding; thus this will result in client-side code to be injected into the page. In simple words, the maliciously injected script triggers from the current HTTP request from the client-side.

Reflected XSS - Image credit: excess-xss.com
Reflected XSS – Image credit: excess-xss.com
Stored XSS (A.k.a Persistent XSS)

Stored XSS is also known as Persistent XSS where the malicious script comes from the website’s database. This vulnerability triggers when the user input is stored on the database server. The input can be such as a comment field in a blog and then the victim retrieves the stored malicious data from the web application and the code executes on the victim’s browser.

DOM-based XSS:

The Dom Based XSS is a form of XSS and it is a variant of both Persistence and Reflected XSS. The Dom based XSS triggers when a compromised data flows from the Web application’s legitimate JavaScript. This XSS attack does not trigger until the malicious piece of script from the Webserver is executed in the end-users browser.

How The DOM-XSS Works - Image credit: medium.com

Impacts Of Cross-Site Scripting

If the attacker succeeds in exploiting and trigger XXS on a webpage or on a web application, he can successfully obtain credentials from the end-user. The attacker can as well use XSS vulnerability to distribute viruses or malware, host his malicious code, host a bot in a victim’s browser to run DDOS attacks, host bitcoin miners, etc.

If the vulnerability is too broad, the attacker can control users’ browsers remotely and eventually gain access to the victim’s system or in a corporate network a whole infrastructure could be in danger. The maliciously injected website or web application could potentially bring the owner organization millions in damage, SEO rank drop, the user may stop using the web application, sales may drop, etc.

In simple terms, by exploiting XSS vulnerabilities an attacker can perform following malicious actions,

  • Hijack an account and use it for illegitimate purposes.
  • Spread webworms, viruses, ransomware and malware
  • Access browser history and clipboard contents to get access to the saved passwords, bank transactions, credit card info etc.
  • Access corporate accounts, systems, and infrastructure.
  • Scan and exploit corporate appliances and applications, modify data, etc.

Cross-site Scripting Attack Vectors

These are a few commonly used XSS attack vectors.

The < Script > Tag

The script tag in XSS is a very commonly used XSS payload. XSS payload. The script tag can have reference to an externally hosted JavaScript an attacker can embed to the webpage and tag so that the externally hosted malicious script runs as internal.

JavaScript Alerts

JavaScript event alerts are also being used as attack vectors. An alert can distract the normal visitor and attract him to visit a malicious website. The alert as well being used within the body tag.

<img> tag
< iframe > tag

I believe the iFrame tag is the most dangerous of all the XSS attack vectors. This will let the attacker embed another webpage inside the legitimate webpage. However, iFrames are runs separately without having access to DoM, but this type of attack still runs in the wild to pulling phishing attacks.

< link > tag

The <link> tag normally contains a link to external style sheets, may also contain a JavaScript link.

< object > tag

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

How To Prevent XSS Vulnerability

As XXS vulnerability is triggered by intercepting users’ input into malicious code, this can be prevented by validating all inputs and encoding them. If the proper encoding in place, the encoder escapes the user input data, not the whole code. When the validation is in place, that filters the user input and the browser interprets it as code filtering malicious commands.

Content Security Policy (CSP): The recent web standard called Content Security Policy (CSP) is being used to prevent XSS attacks. Major browser developers including Mozilla, Google and Microsoft have already developed with this newly added security layer to their browsers according to this new standard.

The CSP is being used to mitigate XSS attacks in the following ways.

No untrusted sources: If the web application requires an external resource to be loaded, this can only be delivered from the set of pre-defined sources.

No inline resources: If an attacker uses inline JavaScript to carry-on the XSS attack, the browser will not evaluate the request and the script is not processed.

No eval: The JavaScript eval function is not supported anymore. If the Eval() function is required to run, the browser will drop a few functions that are considered dangerous in CSPolicy.


Hey there, I'm Navin, a passionate Info-Sec enthusiast from Bahrain. I started this blog to share my knowledge. I usually write on HackTheBox machines and challenges, cybersecurity-related articles and bug-bounty. If you are an HTB user and like my articles, please respect here: Profile: https://www.hackthebox.eu/nav1n

View all posts by Navin →
Notify of
Inline Feedbacks
View all comments
Sorry, that action is blocked.