Cross-Site Scripting: XSS Injection

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:

Cross-Site Scripting: XSS Injection

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:

Cross-Site Scripting: XSS Injection

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:

Cross-Site Scripting: XSS Injection

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:

Cross-Site Scripting: 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:

Cross-Site Scripting: XSS Injection

– 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:

Cross-Site Scripting: XSS Injection

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.

Cross-Site Scripting: XSS Injection

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.

Finally, we can find an encoder called JSFuck that converts the javascript code we want into esoteric javascript code:

Cross-Site Scripting: XSS Injection

In next posts I will show some cases of advanced XSS like Blind XSS or Dom Based XSS.

Lethani.

 

4.3/5 - (212 votes)

1 thought on “Cross-Site Scripting: XSS Injection”

Leave a comment