Last updated on October 3, 2020
After the posts about SQL Injection and NoSQL Injection, today I bring you the XSS Injection. This attack consists of injecting malicious code into benign web pages. The attacker injects code from the client side, so that for a bad configuration of the website, this code is shown to other users.
This type of attack usually occurs when the browser uses a user input field to generate an output field without previously validating it.
To try to get a Cross-Site Scripting injection, you have to try to find areas of a web page where a value you enter is reflected. An example would be to find a web page where you have to enter a user name in the register, for example “Lethani”, and when logging in a welcome message appears saying “Hello, Lethani”.
If we looked at the source code of that supposed page, we would see an html code like this:
To show you the proof of concept, I used the page xss-game.appspot.com, which I recommend so you can test this vulnerability yourself:
However, just because a page reflects a user input does not mean that it is vulnerable to XSS. To avoid this vulnerability, it is enough that the developer has validated all the entries, using functions created for it, so that regardless of what you enter that value is treated as a variable, and never as code that can vary the source code.
There are two versions of this type of injection: XSS Reflected and XSS Persistent. When the injection is reflected, the malicious code is not saved in the database, it is only reflected in the client. Therefore, in order for a user to be shown, he must have entered it himself. However, when a persistent XSS injection is involved, the payload entered is saved in the database, and any user accessing the injected value is shown. Therefore, an XSS Persistent vulnerability is much more serious than a Reflected one.
Alcance de ataques XSS
One might wonder what this attack might be of use to us. Beyond a user being surprised by a pop-up, there are many interesting things we can do if we’ve got an XSS injection.
This way, I would send my website your session cookie. I would get it, and I could make purchases on your behalf.
– Force to Download a File: It is possible to make a user download a malicious file by visiting a vulnerable link to XSS Injection. For example, we could do it with the following payload:
– Redirecting User: we can also use it to send the user to another web page. The user could be redirected to a page controlled by the attacker that is identical, so that he enters his credentials believing he is on the original page:
In addition to these, you can find many other scripts to activate keyloggers, take photos and videos through the webcam, etc. at this link.
XSS Ofuscated / Polyglot
In addition to these you can find other ways to obfuscate XSS injections to avoid filters on the OWASP page.
In this other web page you can find many demos of “XSS Polyglot”, in which the characters are encoded to avoid the filters.
In next posts I will show some cases of advanced XSS like Blind XSS or Dom Based XSS.
[…] This post is the continuation of another one I published a few months ago. If you haven’t read it yet, I recommend you take a look at it. […]