What is an XSS vulnerability and how can a tester not miss it
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.
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.
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?
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?
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 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
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: https://playground.learnqa.ru/demo/xss
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.
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:
& lt; script > alert (123) & lt;/script >
If the page is vulnerable, after entering this code, the following window will appear on the page:
So, 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 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: playground.learnqa.ru/demo/xss?q=Ray+ 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.
By clicking on this URL we see that a window with a value of 123 appears on the page. But why?
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.
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.