Web Hacking: Become a Pentester - Lecture 34: Reflected Cross-Site Scripting

In this video we will check out how reflected xss attacks work.

This is a preview lecture from my online web hacking training called Web Hacking: Become a Pentester.

Trainings:

Transcript:
Hi,

In this section we are going to discover various attacks that target the client and the user. This means that these attack will be executed in the user's browser and although the malicious data will cross the server but they won't have any effect on the server-side only on the client side. But these are still pretty serious attacks. Their worst-case scenario is that the attacker get full control on the user's account, which in case of an administrator might mean full control on the application. Of course the attacker can still keep going further and attack the server, and we will see that in the next section.

[draw]
This lecture is about reflected cross-site scripting (XSS). XSS is a vulnerability, where the attacker's input can be used to manipulate the application in the browser.

The theory is that you submit some kind of value for instance your name on a form, and the application uses the submitted value to generate HTML. However if you submit HTML instead of your name it will be embedded in the rest of the HTML code and when it gets to the user the browser will have no way to distinguish the original HTML and HTML which was supposed to be your name, thus it will render everything as HTML. This way it is possible to alter the page using the name parameter.

We call a XSS reflected, if the malicious input is not stored on the server, but rather reflected back to the target user in the resulting page. In this case the the attack involves some social engineering, because the victim will have to load the malicious URL of the attacker or open a malicious site.

Let's see this in practice. As I told you, the whoisyourdaddy application is vulnerable to reflected XSS. If we open the file you can see again that the name parameter is copied directly into the HTML. So what happens if I input the following as a name:
xxxxx

Pause and think about it a little.

Ok let's try. 'I' stands for italic. So as you can see Geri became italic. Because the php code turned the input uppercase and then placed it into the HTML. But it contained HTML as well. Let's see it in the browser. Apart from being capital there is no distinction between the input text and the original HTML, so for the browser it all just html. So what happens if we put Javascript as a name:
xxxxxxxx

It doesn't work, but why not? If you look into the HTML code you will see that of course the php code turned the whole thing to capital letters, and it turns out javascript is case sensitive. This happens very often that the application alters your input and you have to figure out a way to engineer an attack vector which could be used even after the alteration. So let's try to find a workaround. As you might know javascript code can be downloaded from any website. The SCRIPT tag has an attribute called src where we can use a URL where the javascript is stored. The code will be downloaded from the URL and handled as if it was inside the Javascript tag. The src attribute is not even subject to the same origin policy so external URLs can be used as well. So just to test, let's create an ATTACK.JS on the server and write some js code in it. This file could be hosted on the attackers server.
xxxxxxx

YESS, the attack was successful, we get our POC popup window with the number 42. Let's quickly look into the HTML code. You will see that it was turned capital case as well, however HTML and hostnames are case insensitive, so as long as the file is upper case it works.

This is a good example, that when you think that there is a problem, but it does not work. Don't give up, spend some time to try to make a workaround. You might fail many times, but keep your goal in mind.

Let's talk about protection against javascript. The protection is two sided. First validation. Second output escaping. Validation means that your application makes sure that it only accepts input which is expected from a given input field. If it is a name then only letters and some special characters allowed such as apostrophe, but not greater than symbol. If it is a telephone number then only digits and plus sign, and maximum 20 characters. Validation has to be done on every input.

Validation is however not enough, so you have to escape the output. This means that text which is not HTML code should be marked that it is just simple text. From this the browser will know not to render it. You can use the HTML encoding.
....

[dinargali]

Hi there! So for deep understanding XSS i need to learn well JS? or...

[aaravsoni]

Hi sir, i am watching your web hacking videos and doing practice.In Lesson 36 -HTTP Header Injection you give a exercise to change the content of test page.i tried everything but didn't get give any hint or any suggestion