If you are a security testing guru and once or twice participate in bounty programs of large IT companies, and the number of XSS you have found is in the tens or even hundreds, you can safely ignore this article. If you are new to the topic and are just starting to be interested in finding vulnerabilities - welcome under cat.
Definition
XSS (Cross-Site Scripting) is a fairly common vulnerability that can be found in many web applications. Its essence is quite simple; an attacker manages to inject JavaScript code into the page that was not provided by the developers. This code will be executed every time victims (regular users) visit the application page where this code was added. And then there are several development scenarios.
First, an attacker will be able to obtain the user's credentials and log into his account.
Second, an attacker can unnoticed by the victim redirect him to another clone page. This page may look completely identical to the one the user expected to be on. But it will belong to the intruder. If the user does not notice the substitution and enters some sensitive data on this page, that is, personal data, the attacker will have it.
The third ... yes, in general, a lot more you can think of. Almost anything JavaScript can do is made available to an attacker. Below we will take a closer look at one of these examples. For now, let's try to discuss in a little more detail how the vulnerability works. And why does an attacker manage to inject his code into someone else's application without access to its source.
A little warning. All information below is presented for informational purposes only. The tester must be able to test his web application for vulnerabilities. However, it is illegal to exploit XSS vulnerabilities on other people's resources.
If we talk about the current Russian legislation, when a researcher tests someone else's product for vulnerabilities or enters someone else's network without the knowledge and consent of the owner, his actions can be regarded as illegal.
But back to XSS.
How does the vulnerability work?
First of all, how exactly do you manage to inject JavaScript code into a page that was not there before? And how do you distribute this code to other users?
For example, you can add JavaScript code to an input field, the text from which is saved and later displayed on the page for all users. This can be a field for entering information about yourself on a social network profile page or comments on a forum.
The attacker enters text (and for one malicious code), which is saved on the page. When other users visit the same page, they will also download the attacker's JavaScript along with the text. At the moment of loading, this code will work. Of course, the vulnerability will only work if the text is not secure when saved. We'll talk a little later about how to do this, and why developers sometimes forget about it.
This is just the simplest and most obvious example of where a vulnerability can be hidden. Below we will consider a more interesting example on a specially prepared demo page.
Until then, let's move on.
Why are these errors often found on web projects?
The bottom line is that the browser cannot independently distinguish plain text from text that is CSS, HTML, or JavaScript code. It will try to treat anything between the <script> tags as JavaScript code. Anything between <style> tags is considered CSS. And everything that looks like a tag is considered HTML code.
If the developer wants some text to only look like code, but it is not (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 processing is called “shielding”.
In the process of escaping the text in this text, all specials. the characters are replaced by their "counterparts", and the browser already knows for sure that it is just text. The most important thing is to process the text that comes from the user, since any user can turn out to be an attacker and send some code along with the text. Alas, sometimes developers forget about escaping in certain places in a 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 specified by the user appears 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. Nevertheless, writing an application completely from scratch, without using any libraries at all, is long and expensive nowadays. Not every company can afford to develop this level.
In this case, all hope is for testers.
Why is an XSS vulnerability dangerous?
Let's once again, in more detail, talk about the dangers of an XSS vulnerability. The vulnerability itself is not dangerous. It becomes dangerous when an intruder finds it and begins to use it for his own purposes. Exploiting a vulnerability is called an “attack vector”. In the case of XSS, there are quite a few attack vectors.
The simplest example is stealing authorization cookies from users of a web application. Most often, the site on which there is authorization distinguishes the authorized user by the so-called session cookie. If it is not there, 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 user's computer. If I log in as my user, I will see my cookie value. And I just can't find out the meaning of a stranger.
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 that one.
Now let's assume that an attacker succeeds in injecting JavaScript code into a web application page. Any user who now visits this page will have JavaScript code executed in the browser. It will read the cookie value of this user (now the victim). It remains only to pass this value to the attacker - and the job is done. But how to pass the value, since the malicious code is executed in the victim's browser?
It's pretty simple. The same JavaScript code can create an AJAX request to the remote server. For example, to the following URL: www.zloy-site.ru/stolen= { victim_cookie_value }
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 learns the victim's cookie values and can use them to get into their accounts.
As we discussed above, this is not the only thing that makes an XSS vulnerability dangerous. So for the sake of security and to protect your users, you need to be able to find and fix such vulnerabilities in your projects.
Where can I find XSS? How to deal with it? Demo page with example
First of all, it is worth checking for XSS vulnerabilities those places on the site in which an ordinary user has the opportunity to influence the content. If he can add some text somewhere, he can try to add JavaScript code as well.
Let's look at this with a specific example. I prepared a very simple sandbox where the XSS vulnerability was hidden. I suggest trying to find it together.
Opening the sandbox: https://playground.learnqa.ru/demo/xss
First, let's see how the page works. It is essentially a very simple book catalog that can be searched. If we enter “Ray Bradbury” in the query, we will see all the books that are in this directory of this author.
An attentive user has already noticed that the text that we entered in the search field immediately ended up in the URL. This moment is still useful to us.
For now, let's try inserting some nonsense into the search box: “fwefewf”.
We will see that in this case nothing was found on the page. And the request text was repeated in the error text:
So, you and I found the place where the text entered by us appears. Therefore, this is a potential site for an XSS vulnerability. Let's try to insert the most popular JavaScript code to check if there is a vulnerability.
<script> alert (123) </script>
If the page is vulnerable, after entering this code, the following window will appear on the page:
It will mean that our JavaScript code has been executed and we have found an XSS vulnerability.
So, we enter the code and see the following warning:
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 everything into account and protected the page from XSS, but this is not entirely true.
Remember, just above, 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 string and next time open the page with the right authors right away.
For example, this URL will open a page with only Ray Bradbury's books at once: playground.learnqa.ru/demo/xss?q=Ray+Bradbury
Unlike the form, the developer could not do URL validation - any user in his browser can enter any URL whatever it wants, including with any value of the GET parameter. The developer's task in this case is not to forget to take into account 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: https://playground.learnqa.ru/demo/xss?q= <script> alert (123) </script>
After clicking on this URL, we see that a window appeared on the page with the value 123. But why?
It's pretty simple. Remember, when a site cannot find the books it needs for a given search query, it displays the text of this search query in the text of an error? Like, did not find anything for the query "blah blah." Instead of this "blah blah" we now have a JavaScript code with an alert. The developer wrote a validation for the input field and decided that this was how he protected the site from JavaScript being included in the search query. And he did not escaped the error text. We were able to bypass the validation through the URL by changing the search query value there.
For the sake of interest, now we can display the value of our session cookie, for this, instead of <script> alert () </script>, you need to substitute another code in the URL: <script> alert (document.cookie) </script>
I'll let you play with this yourself. :)
Having found a bug, you should contact the developers - they will fix it.
There are many ways to close the error. Escaping text isn't the only one. You can also prevent JavaScript itself from seeing some cookies. For 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 has been set at all and will not be able to read it and transfer it to an attacker even if he can find XSS on your project.
All this is just a small, far from complete list of manipulations that prevent XSS vulnerabilities. As stated above, if XSS is detected during testing, it is best to talk to programmers.
If you are interested in knowing more about security testing, you want to better understand the structure of the client-server architecture, understand and hone the most effective ways to find vulnerabilities in a real web application, come to my course “Security testing”. All the information you need 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 variety 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.