Cross Site Scripting (XSS)

Lecture Notes

This lecture will present an overview over OS specific injections.

Download here

Practical tasks

This guide will explore the XSS exercises in bWAPP. The guide explores the attacker perspective. For a compreensive review of defense techniques, check the OWASP XSS Prevention Cheat Sheet link

Relevant aspects specifically to these exercises are:

• Sanitize everything!

• Set the Content-Type to application/json, and set X-Content-Type-Options: nosniff so that it will instruct the browsers to disable the MIME sniffing and stop trying to guess the content (for JSON attacks)

As with other guides, write your approach to each exercise, the solutions and the reason of why it happened.

The source code can be found here

Cross-site-scripting - Reflected (GET)

Choose Cross-Site-Scripting — Reflected (GET ) from the drop-down menu and click Hack.

Now on below webpage, you can able to see there are two input fields are there Firstname & Lastname and let’s enter the first name as Maria and last name as Mendes and let’s see what’s happening.

You can able to see the value of the first name & last name both are reflecting in the address bar. So if the variable’s value will reflect in the address bar then there is a possibility that an attacker can tamper that variable’s value and inject some Javascript code.

So to test, try to add <b> tags to the first name in the URL. If the name appears in bold, the input field is vulnerable.

Task: Determine if it is possible to inject a script

How to prevent:

• Avoid reflecting text
• Encode unsafe characters in the response!

Cross-site-scripting - Reflected (GET)

Choose Cross-site-Scripting — Reflected (POST ) from the drop-down menu and click Hack.

Now on below webpage, you can able to see there are two input fields are there Firstname & Lastname and let’s enter the first name as Maria and last name as Mendes and let’s see what’s happening.

This time the names will not be reflecting the URL, as POST is being used. The immediate impact is that reflected XSS are not direct.

Task: Either directly or with ZAP assess both fields

Cross-site-Scripting — Reflected (JSON )

Please choose Cross-site-Scripting — Reflected (JSON ) from the drop-down menu and click Hack.

As you can see here on this web page one input box is there and it’s asking the user to enter movie name. So enter a movie name, for example, X-Men or Interstellar and click Search.

Now you can see here Movie name is reflecting in both address bar and on the webpage and if the output got reflected on the address bar or on the web page then we can inject our payload. Try <script>alert('victory');</script>.

This aims to test a situation where JSON is used. Therefore something else may be needed. As you can see our payload didn’t work so one thing you always remember that whenever the output reflected on the webpage first thing try to check the view page source of that web page in that way you can able to understand the DOM structure of that particular HTML element. And then only you can able to inject your payload.

The result will be this:

        var JSONResponseString = '{"movies":[{"response":"Interstellar??? Sorry, we don't have that movie :("}]}';

        // var JSONResponse = eval ("(" + JSONResponseString + ")");
        var JSONResponse = JSON.parse(JSONResponseString);

        document.getElementById("result").innerHTML=JSONResponse.movies[0].response;

The trick here is to terminate the previous statements by using }, ] and other characters.

Task: Create a valid payload for this example.

Cross-site-Scripting — Reflected (AJAX/JSON )

As you can see here it’s asking the user to enter the movie name but you can see here there is no search button because as it’s an AJAX web page it will update the web page without reloading the page and the client-server interaction will happen in the background.

Enter some movie names and see what happens. You should be able to find a movie that reflects back to the webpage.

If you try some payloads, they won’t work as the response is coming in JSON and the input is inside double quotes, before being processed by eval link

It means that the attack is avoided at this level, but may be possible later as the content is injected into the web page. Something that can be done is triggering Javascript on a element event, in the form <tag onEVENT=alert(1)>. Of particular relevance is the onerror which can be triggered by an image that fails to load.

Task: Develop a payload that triggers Javascript using events

Cross-site-Scripting — Reflected (AJAX/XML)

Choose Cross-site-Scripting — Reflected (AJAX/XML) from the drop-down menu and click Hack. You will get the same user interface again and it’s asking the user to enter the movie name. Proceed as in the last scenario, as it is very similar.

The difference here is that the result arrives in XML. Sending a < will be forbidden as it will break the XML and create an error in the application.

As an alternative it is possible to encode those characters to HTML Elements. Check this webpage which can encode characters to HTML elements

Task:_ Create a payload to this exercise

Cross-site-Scripting - Reflected (Back Button)

Choose Cross-site-Scripting - Reflected (Back Button) from the drop-down menu and click Hack.

In this situation, when the user clicks on the back button, the JavaScript code will use the referrer header to go back to the previous page. So in this situation if you can modify the referrer header, you can inject code to execute.

These show that headers may pose risks. A header can is an input to the application and can lead to the exploitation of several vulnerabilities, just like any other input.

Task: Use ZAP and inject a payload to the Referer header.

Task: Execute the exercise Custom Header with the same approach.

Cross-site-Scripting - Reflected (Eval)

Choose Cross-site-Scripting - Reflected (Eval) from the drop-down menu and click Hack.

The page will show the current date, as determined by the Date() object. The object is do demonstrate the incorrect use of the eval function. In this case, the eval is used to evaluate the argument date, presenting a vulnerability.

Task: Exploit the date argument to execute a reflected XSS

Cross-site-Scripting - Reflected (HREF)

Choose Cross-site-Scripting - Reflected (HREF) from the drop-down menu and click Hack.

The objective of this page is to demonstrate that the inclusion of unsanitized text, even if not visible to the user, can still be dangerous. The situation demonstrated in common in pages with processes that take multiple steps, and where the browser is used to pass information between steps or systems.

Insert your name and proceed. At this page the provided data will be printed on the next page but the it is parsed with html parser. But as the link to vote is not parsed or filtered it can execute a payload.

Task: Inject a payload using the name field. You may have to take in consideration the HTML in place and the tags that need to be closed.

XSS - Reflected (PHP_SELF)

Choose XSS - Reflected (PHP_SELF) from the drop-down menu and click Hack.

The PHP_SELF term in this exercise refers to the use of $_SERVER["PHP_SELF"] in HTML forms. It is used to that the form refers to the script from where it was called, and may be required with forms that are shared between components in a website The issue is that after the form is submitted, whatever is present after the URL is used to fill the form, Javascript included.

You can check the result of the $_SERVER["PHP_SELF"] variable by checking the HTML code, which has: action="/xss_php_self.php". If this form was called in another page, it would have a reference to that PHP script. The source code in the PHP script can be checked here

Task: Inject a payload to any of the fields.

XSS - Stored

Choose XSS - Stored (Blog) from the dropdown menu and click Hack.

This page presents a simple form where users can leave messages. It mostly differs from the previous as the attack is not reflected: it is stored. It means that the payload is stored to a server that fails to properly sanitize it.

Tasks:

• Because the attack will be present to other users, and is simple to experiment, try to use it for malicious purposes, like cookie stealing. For this purpose you will require a server in you computer (e.g., using netcat). Can you steal your colleagues cookies and also demonstrate a broken authentication process?

• Can you use this attack to change your colleagues secrets? Check the form and what is sent when the secret is modified.

The remaining exercises in this section will explore this concepts with small variations. Give it a try.