Cross-Site Scripting: XSS Injection

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:

But if instead of “Lethani” we were to write in the registry a user name containing a malicious javascript code, this would be executed when the html page was rendered. For example:

This code would cause the javascript alert() function to be executed which makes the browser display a pop-up.

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:

In order to test this type of vulnerabilities usually the javascript alert() function is used. If introducing somewhere on the web the function skips a pop-up, then the page is vulnerable to XSS.

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.

– Cookie Stealing XSS: It is possible to steal a user’s session cookie. This can be done by running the javascript document.cookie function. Let’s suppose that we can make an XSS injection in an amazon url. By phising I could make a user open the link in which I have injected the next payload:

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

On many occasions I have found web pages where I suspected they were vulnerable to XSS but had the text “<script>” filtered so that nothing happened when injecting the payload. Here are some ways to execute javascript code without using script tags.