In my observation, quite a lot of testers have ever heard such a thing as an XSS vulnerability. But few people can simply and fingerlessly tell at an interview about her. Or effectively check the website for this vulnerability. Let’s take a closer look at all this together and try to find the simple XSS vulnerability on the demo page, which I specially prepared for this article.

If you are a security testing guru and once or twice participate in the bounty programs of large IT companies, and the number of XSS that you found is in the tens or even hundreds, you can safely skip this article. If you are new to the topic and are just starting to be interested in finding vulnerabilities, welcome to cat.

ITKarma picture


XSS (Cross-Site Scripting - “cross-site scripting”) is a fairly common vulnerability that can be found on many web applications. Its essence is quite simple, an attacker manages to embed JavaScript code on the page that was not provided by the developers. This code will be executed every time the victims (regular users) go to the application page where this code was added. And then there are several development scenarios.

First: an attacker will be able to get the user's authorization data and log into his account.

Second: an attacker can quietly redirect a victim to another clone page. This page may look completely identical to the one on which the user intended to be. But here it will belong to the attacker. If the user does not notice the spoofing and enters some sensitive data, that is, personal data, on the page, the attacker will find it.

The third... yes, in general, there’s a lot more that you can think of. Almost everything JavaScript can do is become accessible to an attacker. Below we will examine in more detail one of such examples. In the meantime, let's try to discuss in more detail exactly how the vulnerability works. And why does the attacker manage to embed his code in a foreign application without access to its sources.

A little warning. All information below is provided for informational purposes only. The tester should be able to check his web application for vulnerabilities. However, using XSS vulnerabilities on foreign resources is illegal.

If we talk about the current Russian legislation, when a researcher tests someone else’s product for vulnerabilities or penetrates someone’s network without the knowledge and consent of the owner, his actions can be regarded as illegal.

But back to XSS.

How is the vulnerability arranged?

First of all, how exactly is it possible to embed JavaScript code on the page that was not there before? And how do you distribute this code to other users?

For example, you can add JavaScript code to the input field, the text from which is saved and subsequently displayed on the page for all users. This can be a field for entering information about yourself on the social network profile page or comments on the forum.

An attacker enters text (and for one malicious code), which is stored on the page. When other users access the same page, they will also download the attacker's JavaScript code along with the text. It is at the time of loading that code will work. Of course, the vulnerability will only work if the text is not safe when saved. We’ll talk about how to do it and why developers sometimes forget about it later.

This is just the simplest and most obvious example of where a vulnerability could be hidden. We will look at a more interesting example below on a specially prepared demo page.

In the meantime, let's move on.

Why are such errors often found on web projects?

The bottom line is that the browser cannot independently distinguish between plain text and text, which is CSS, HTML, or JavaScript code. It will try to process everything between the & lt; script > tags as JavaScript code. Anything between the & lt; style > tags, consider CSS. And everything that looks like a tag is considered HTML code.

If the developer wants some text to only look like code, but not to be that (that is, it was not processed by the browser, but displayed as is), this text must be specially processed before giving it to the browser. This is called “shielding.”

In the process of escaping text in this text, everything is special. characters are replaced by their “counterparts”, and the browser already knows for sure that this is just text. The most important thing is to process the text that comes from the user, since any user can be an attacker and send some code along with the text. Alas, sometimes developers forget about escaping in certain places of the web application, and the text is displayed without any processing. There may be several reasons for this.

For example, the programmer does not always keep in mind all the places where the text set by the user gets on the page. Moreover, sometimes different parts of the site can be created at different times and/or by different people. In this case, the probability of error increases.

Another reason may be that the vulnerability is not in the code of the developer himself, but in the code of the library that he uses. Usually these are some ready-made frameworks for creating web services. In this case, the developer, of course, may not even suspect that by connecting this framework to the project, he automatically connects a ready-made vulnerability to it.

There is always such a risk. Still, writing an application completely from scratch without using any libraries at all is long and expensive these days. Not every company can afford the development of this level.

In this case, all hope is for testers.

What is the danger of XSS vulnerability?

Let's talk in more detail about the dangers of XSS vulnerability. The vulnerability itself is not dangerous. It becomes dangerous when an attacker finds it and begins to use it for its own purposes. The exploitation of the vulnerability is called the “attack vector”. In the case of XSS, there are quite a few attack vectors.

The simplest example is the theft of authorization cookies for users of a web application. Most often, the site on which authorization is present distinguishes the authorized user by the so-called session cookie. If it is not, then the user is not authorized. And if it is, then by the value of this cookie the server can distinguish one user from another.

All cookies are stored on the users computer. If I log in as my user, I will see my cookie value. And I simply can’t find out the value of someone else’s.
The same goes for JavaScript code that runs in the user's browser. This JavaScript code will see the cookie value of the user in whose browser it is executed and only it.

Now suppose that an attacker manages to embed JavaScript code on a web application page. Any user who now visits this page will have JavaScript code executed in the browser. He will read the cookie value of this user (now the victim). It remains only to convey this value to the attacker - and the job is done. But how to convey the meaning, because the malicious code is executed in the victim’s browser?

Everything is pretty simple. The same JavaScript code can create an AJAX request to a remote server. For example, at such a URL: {cookie_value of the victim}

The zloy-site domain belongs to the attacker from our example. All requests that come to this domain are recorded in the database. By looking at the URL parameters, the attacker will recognize the cookie values ​​of the victims and will be able to use them to get into their accounts.

As we discussed above, this is not the only dangerous XSS vulnerability. So for the sake of security and to protect your users, you must be able to search and close such vulnerabilities on your projects.

Where to look for XSS? How to deal with it? Demo Page with Example

First of all, it is worth checking for XSS vulnerabilities in those places on the site in which the average user has the opportunity to influence the content. If he can add certain text to some place, he can try to add some JavaScript code.

Let's look at a specific example. I prepared a very simple sandbox where the XSS vulnerability was hidden. I suggest trying to find her together.

Open the sandbox:

First, let's see how the page works. This is essentially a very simple catalog of books in which there is a search. If you enter “Ray Bradbury” in the query, we will see all the books that are in this catalog of this author.

ITKarma picture

An attentive user has already noticed that the text that we entered in the search field immediately appeared in the URL. This moment is still useful to us.

In the meantime, let's try to insert some nonsense in the search field: “fwefewf”.

We will see that in this case nothing was found on the page. And the request text was repeated in the error text:

ITKarma picture

So, we have found a place where the text that we enter appears. Therefore, this is a potential place for an XSS vulnerability. Let's try to insert the most popular JavaScript code to check if there is a vulnerability there.

& lt; script > alert (123) & lt;/script >

If the page is vulnerable, after entering this code, the following window will appear on the page:

ITKarma picture

It will mean that our JavaScript code has executed and we have found an XSS vulnerability.

So, enter the code and see the following warning:

ITKarma picture

The form does not allow us to search by this value, since the form is validated and wants to work only with letters and numbers. At first glance it seems that the developer took into account everything and protected the page from XSS, but this is not entirely true.

Remember, a little higher, we noticed that the text that we enter in the search field is displayed in the URL in the so-called GET parameter? The name of this parameter is “q”, and the value is what we enter in the search field. This is done so that you can copy the URL along with this very search bar and next time open the page immediately with the necessary authors.

For example, here such a URL will open a page immediately only with the books of Ray Bradbury: Bradbury

Unlike the form, the developer could not validate the URL - any user in his browser can enter any URL he wants, including with any value of the GET parameter. The developer’s task in this case is to remember to consider all the options and write the correct handler for the value of this GET parameter.

Let's check if our developer forgot to take everything into account here. Let's try to substitute the same JavaScript code into the “q” GET parameter:<script>alert (123) & lt;/script >

By clicking on this URL we see that a window with a value of 123 appears on the page. But why?

Everything is pretty simple. Remember, when a site cannot find the necessary books for a given search query, it displays the text of this search query in the text of the error? Like, they didn't find anything for “blah blah.” Instead of this “blah blah”, we now have a JavaScript code with an alert. The developer wrote a validation of the input field and decided that this is how he protected the site so that JavaScript could appear in the search query. And he did not screen the error text. We managed to bypass validation through the URL by changing the value of the search query there.

For the sake of interest, we can now print the value of our session cookie, for this instead of & lt; script > alert () & lt;/script > in the URL you need to substitute another code: & lt; script > alert (document.cookie) & lt;/script >

With this, I will already leave it to you to play with yourself. :)

If you find a mistake, you should contact the developers - they will fix it.

There are quite a few ways to close the error. Escaping text is not the only one. You can also prevent JavaScript from seeing some cookies.To do this, the cookie has a special parameter “http only”. If it is set to TRUE, JavaScript will not be able to find out that such a cookie is set at all and will not be able to read it and pass it to the attacker even if he manages to find XSS on your project.

All this is just a small, far from complete list of manipulations that prevents XSS vulnerabilities. As stated above, when XSS is detected during testing, it is best to communicate with programmers.

If you are interested in knowing more about security testing, you would like to better understand the client-server architecture, understand and hone the most effective ways to search for vulnerabilities on a real web application, come to my course "Security Testing". All the necessary information is in my profile.

You will find only a useful and necessary theory without water and a large number of practical examples and tasks. You will explore many web pages crammed with a wide range of vulnerabilities. The final work will be a large study of either your working project, or one of the web applications of such giants as Google, Facebook, Twitter and so on.