In this article, we are going to look at XSS attack types and how these attacks harm us. Also, we are going to learn how we can protect against these attacks.
What are XSS Attacks?
Cross-site scripting (XSS) is a type of attack in which malicious scripts are injected into web applications in order to run them on the user’s device.
It can be a confusing definition, let’s simplify it a bit, the main purpose of this attack is to manipulate the output via the input data.
These attacks happen when an attacker takes advantage of a benign website to spread malicious scripts that the attacker has created.
How Works These Attacks?
If a website allows the user to run JS/HTML/CSS codes, the attacker exploits this and injects their malicious code into these sites.
While there are several types of XSS vulnerabilities, the scenarios are generally similar find the vulnerability, write the script, embed the site, wait for users.
XSS attacks are one of the most common web attacks today, they are easily detected and can cause great harm to users.
Detection XSS Vulnerability
You can discover XSS vulnerabilities by injecting payloads that cause your browser to execute some arbitrary Javascript.
Often sites are injected with the alert() function, it’s harmless and makes it easy to spot the vulnerability.
In versions of Google Chrome after July 20th, 2021, cross-origin iframes are prevented from calling alert(). print() can be used instead of alert().
XSS Attack Types
Currently, there are 3 types of XSS attacks: Reflected XSS attacks, Stored XSS attacks, and finally DOM XSS attacks.
In this section, we are going to examine theories of these types, and we are going to solve examples in real-life problems.
Defination of Reflected XSS
This type of XSS does not leave a lasting effect. In other words, the website runs the code you want but does not save it on the site and the codes have no lasting effect.
Since the script you write is not permanent after it affects the web application, the danger rate is lower than other XSS types.
Since the XSS vulnerability on the site is not permanent in these attacks, you will have to look for a victim to click on the link with your code.
Practice of Reflected XSS
We are going to use this website as making practice. This site is a playground that measures your xss skills with 6 different levels.
In our mix is a website that looks like a search engine. As we know, search engines do not save the entries we enter in the database.
There is a high probability that there is a Reflected XSS vulnerability here, so let’s first examine the site structure with the inspector and start looking for the vulnerability.
The structure of the level 1 is quite simple, this level consist of logo image, one form to enter your queries and a button to continue.
When you enter any query, the site writes it between the tags. So when you add code to the query, it will most likely run.
<h1>Test</h1>The code above makes the entered query look like a header. Now, let’s search by adding this code to the query section.
In Inspector, a new code block, namely the h1 tag, is now placed inside the br tags, which means that there is no XSS barrier.
If every query you enter can be written easily (no problems with scanning or etc.), you can transfer your script codes here.
To pass the level, we can print something with the alert function, so let’s adding alert function in search bar.
<script>alert("Something")</script>If you restart the site, you will notice that the site is working normally, that is, only the link you prepared runs the commands you want.
In addition, you can add your commands without going back to the query section, for this you can write your codes next to ?query= next to the link in the top bar.
Defination of Stored XSS
This type of XSS attack can create bigger problems than reflected XSS. Here, the codes added to the site are saved directly to the database.
This means that it is possible to create permanent damage to the site. Since the script is automatically loaded every time the site is opened, you will be in danger.
Such vulnerabilities usually occur on pages that communicate directly with the database. For example, messaging sites, the contact section on a blog site.
Practice of Stored XSS
On the second level of the Playground, there is a board where you can share your Reddit-like ideas.
It allows us to use HTML tags and if the site is restarted, the content remains on the site.
However, we cannot use the <script> tag as in the other example. Therefore, we should make use of the onerror event.
<img src="image.jpg" onerror="alert('Attacked')">The onerror event is triggered if an error occurs while loading an external file (e.g. a document or an image).
Since this image file cannot be found, an error will occur and our command will run. Now let’s try to pull the cookies.
<img src="x.jpg" onerror="alert('document.cookie')">With this script, you can get your cokkie. This script write your cookie in alert message box.
Since script will saved on database, the cookies of the person will be printed on the screen at each login.
It can be prepared in different types of attacks, the rest is up to the attacker. Usually, the cookie is written to the access.log of another site for after use.
Definition of DOM XSS Attacks
DOM-based XSS is an advanced XSS attack. It is possible if the web application’s client-side scripts write data provided by the user to the Document Object Model.
The data is subsequently read from the DOM by the web application and outputted to the browser.
If the data is incorrectly handled, an attacker can inject a payload, which will be stored as part of the DOM and executed when the data is read back from the DOM.
DOM XSS Attacks Implementation
First of all, let’s start by examining the main source codes of the site, this site is not very similar to the old levels, it pulls data from a different server.
While the query we entered was printed in Level 1, the queries we entered in Level 2 were in the database, now the images are in the cloud.
The code is parsed as follows: extract an integer from the br tag, then put this integer (extracted) on the cloud link to get the desired picture.
This means that if we change integer in the URL to a different value, we can send a different request to the cloud.
Let’s test it, we see that we have at most 3 images, so what kind of output will we get if we call 4?
https://xss-game.appspot.com/level3/frame#4When I change the URL in the same way, the website shows me an output like this. I can also see my request in the network section.
Our request is successfully sent to the cloud server, but we get an error because there is no 4th image.
If you remember the onerror we saw in the previous section, we will use it now. We will provide an image input that is not found and trigger onerorr event.
frame#4' onerror = "alert('Attacked')"Did you see the comment character next to 4, thanks to it, we separated the error from the text section.
As you can see, we injected our code into the site with the help of Javascript, without using any HTML tags.
How to Prevent XSS Attacks
It is easy to protect your site from XSS attacks, although the attacker may seem in a better position than the defender.
However, preventing XSS attacks can be much more difficult, depending on the complexity of the application and the way it handles user-controllable data.
- Filter inlet on arrival. Filtering the input the user can give very strictly at the point where the user input is taken will solve many problems.
- Use appropriate response headers. You can use the Content-Type and X-Content-Type-Options headers to ensure that browsers interpret the responses in the way you intend.
- Content Security Policy. As a last line of defense, you can use the Content Security Policy (CSP) to reduce the severity of XSS vulnerabilities that still occur.
XSS vulnerabilities can be prevented with these, since the effect of Stored and DOM attacks is greater, more precautions should be taken against these attacks.