Hey Folks, In this tutorial we are going to continue our web application penetration testing series and will talk about Cross Site Scripting (XSS) which is also known as the OWASP A7 vulnerability. In this tutorial we will give you complete guide about the (XSS) vulnerability such as.

  • What is it
  • Types
  • Exploiting
  • Mitigations

and much more. The (XSS) vulnerability comes at number seventh in OWASP TOP 10 vulnerabilities and if you want to know about the previous vulnerabilities then you can read by using below the given links.

Lets take a Look 🙂 !!

What is Cross Site Scripting (XSS) ?

Cross-site scripting is a type of vulnerability usually found in web applications. Cross Site Scripting vulnerability occurs when a malicious script is injected directly into a vulnerable web application cause of input validation. If the attackers successfully get the XSS vulnerability then they can bypass access controls such as the same-origin policy even they can lead these kind of attacks.

  • Remote Code Execution (RCE)
  • Phishing Attack
  • Cookie Stealing
  • Change Website Content
  • Inject Malicious Script Tag

But as we know most of the time we use script or html tag to exploit XSS vulnerability. But the question is why JavaScript is important during the XSS vulnerability explosion ? JavaScript is a programming language used both on the client and server side that allows you to make web pages interactive even JavaScript has full control over cookies so attackers use JavaScript malicious tags to exploit this vulnerability. Through the image below you can see the whole scenario of how attackers inject malicious tags or scripts into web applications.

After understanding the introduction of cross-site scripting (XSS) and JavaScript we will go ahead and discuss the types, exploitation and mitigation of XSS vulnerabilities. There are three major types of XSS vulnerabilities.

  • Reflected ( Non-Persistence )
  • Stored ( Persistence )
  • DOM Based

Reflected ( Non-Persistence )

Reflected XSS attack are also known as non-persistent attacks. Reflect vulnerability allows an attacker to execute arbitrary JavaScript in the vulnerable web application but malicious code is not visible to everyone. For example: if the attacker injects the tag into the web application via input but the tag is visible only to the attacker and not visible to anyone that means the web application is vulnerable to Reflected Cross Site Scripting vulnerability.

Exploiting Reflected Vulnerability

Now we are going to learn about it that once this vulnerability is found, how can we take advantage of it. For this purposes we’ll use the DVWA vulnerable web application whose setup tutorial you can see here. Below you can see that there is an input available and where after entering plain text we get the normal response which should also be.

After analyzing the source code of the web application, we did not get any filler on the input which means that we can execute arbitrary commands.

We know that this input is vulnerable, so we will try to read and write cookies by injecting a script tag in the input.

BOOM 🙂 As you see that the cookies of the current session pop up successfully on the browser.

Add Filters (Reflected)

After setting high security the previous payloads are not working as you can see below.

As we analyze the source code of the web application again, we see that the script tag has been restricted.

We have to break the security and now we will use other malicious code to exploit this vulnerability.

Done 🙂 Again we got success and finally we have break the medium level security without much efforts.

If the tag is restricted, you can use an tag like the one below.

You have to use different -2 payloads to exploit the vulnerability and similarly you can take help of such html or script tag to detect vulnerability in web application.

Reflected (GET)

If the site is vulnerable to a reflected XSS vulnerability and the web application uses the GET method to transfer sensitive information between the client and the server then the attacker can lead a phishing attack by injecting the required parameters through the URL. How its possible lets see . First you can see that whenever we enter credentials the web application behaves same as others.

Due to improper input validation, we can inject any malicious code so we will inject the IFRAME tag through the URL to which we have our own phishing page link. As we know that the IFRMAE tag is used to redirect the user to another web page.

As soon as the victim opens the original link, they will redirect to the phishing page, as you can see below.

Great 🙂 !! As soon as the victim entered the username and password they came to us as you can see below.

Reflected (POST)

An attacker cannot do much if the web application is vulnerable to a reflected XSS vulnerability, but the web application uses the POST method to send sensitive data. As you can see, only the results will be visible to me, even we cannot do anything to the other person because sensitive information is not traveling in the URL.

Nice 🙂 But if you are a bug hunter, you can report the vulnerability that they will definitely award you. As you can see the the application is vulnerable to reflected cross site scripting vulnerability.

Reflected ( JSON )

There are many location where we can find XSS vulnerabilities, Similarly JSON based XSS is sometimes found. As you can first analyze, after entering plain text we got an error from the server.

Now we will show you the back end code of the web application, where you will get an idea about how we can exploit this vulnerability. Got it 🙂 After analysis we came to know that we can execute the payload after entering the given movie name.

Here you can see that we are going to execute our payload after enter the require parameter in input.

Done 🙂 We have successfully found the JOSN based cross site scripting vulnerability.

Reflected (XML)

As we know that XML is an extensible markup Language and it is used to structure data for storage and transport. But sometime attacker try to find XSS vulnerability in XML entities. For instance we’ll give the bWAAP vulnerable web application.

We used our favorite burpsuite tool to examine the response from the server side and we got a juicy information that the web application uses UTF-8 encoding for XML entities.

So we will inject our payload into UTF-8 encoding by encoding it.

Right 🙂 Below you can see that we got success after entering the encoded payload.

Reflected (Custom Header)

The header that is used to transfer sensitive information between client and server and often the attacker tries to inject malicious scripts by adding custom headers. We are going to do the same demonstration that will give you an idea about it. Below this gives us a hint related to the header.

First we add some plain text to the custom header and check the response.

Really 🙂 As you can see the web application prints the user’s input that the user added to the header themselves.

Which means that we can inject any malicious script or tag through the header? Let’s see if this is possible?

OMG 🙂 !! Again we got success and the payload has been successfully executed which was entered in the header.

Reflected (Referer)

By checking the referer, the new webpage can see where the request originated. We cannot change the referrer but the attacker can manipulate the referrer if the website is vulnerable to input validation. Below you can see that the referer URL is already shown on the web page.

Now we use the burpsuite tool and after capturing the response we change the referrer URL to its malicious script tag.

ALERT 🙂 We received a alert prompt after manipulating the referer which means that the web application is vulnerable to XSS vulnerability.

Reflected (User-Agent)

When we browser in order to connected with website, a User-Agent field is included in the HTTP header that represents the host details such as : OS, Version etc. The user-agent log is saved in the log file, which allows attackers to take advantage of it and execute their malicious queries through the user-agent.

Again we use burpsuite tool and first analysis the response from the server side and below you can see that the operating system and browsers details is described in the user-agent.

Look at the highlighted text that we have replace to malicious scripts tag.

Nice 🙂 !! We did not know about whether the payload would work and below you can see that the alert box has popped up as we gave in the header.

Stored XSS

Stored attacks are those where the injected script is permanently stored on the servers, such as in a database through the various input fields such as : message forum, visitor log, comment field, etc. For Instance : If the attacker injects the H2 tag via a comment and whenever the new visitor visits the website, those tags are also visible to everyone which means the web application is vulnerable to stored cross site scripting vulnerability.

We’ll use DVWA vulnerable web application from which we will show how the attacker does this. Before that identify from the image below that the web application is insecure because it prints the malicious user input on web application.

Phishing with XSS

Now we’ll demonstrate the phishing attack through stored cross site scripting vulnerability. But we have to use some phishing tool and we will use Advphishng tool to perform this attack. Lets create a phishing page through taking guidance from here.

Now here we take a strange idea and create a social media icon that will contain our phishing page. Now when anyone comes to the website, they will definitely visit the social media platform and they will fall into our trap.

Here you can see how the page will look like after opening by the victim.

OMG 🙂 We have successfully obtained someone else’s credentials and even when a new user visits that website we will receive credentials continuously.

Stored (User-Agent)

If you don’t know about the user-agent then you can scroll up, now Now let’s talk about how we can find the XSS vulnerability in the HTTP header. Cause of input validation the user agent is vulnerable to the stored cross site scripting vulnerability.

Likewise we will again replace the user-agent with our malicious code.

Done 🙂 Below you can see the the web application is vulnerable even the code will be visible to all new visitors.

DOM Based XSS

DOM-based XSS vulnerabilities are a type of Cross-site Scripting (XSS) vulnerabilities. DOM Based Cross Site Scripting vulnerability occurs by taking the data from an untrusted source and includes that data within the immediate response in an unsafe way.
Note : DOM based cross site scripting vulnerability can be noticed only during the execution.

But the question is that how we can detect this vulnerability? Often it is not easy to identifying this vulnerability because in many cases the payload never reaches the server therefore the best way to detect such vulnerabilities is by using automation professional web vulnerability scanner such as burpsuite. We are use DVWA web application which is vulnerable to the DOM bases XSS vulnerability and below as you can see that the attacker have successfully grabbed by the cookies by inject the payload.

Hmm 🙂 As we already mentioned above that it is difficult to detect DOM based XSS vulnerability because the payload does not reach the server-side, but we can prevent this vulnerability by following the mitigation steps that we will give in the end.

Mitigation Steps

Defending yourself against such attacks is not difficult. Therefore the developer should keep in mind the following points which we have mentioned below.

  • Must sanitize your inputs
  • Should never output data received directly
  • Filter input on arrival
  • Implement Content Security Policy (CSP)
About the Author
Shubham Goyal Certified Ethical Hacker, information security analyst, penetration tester and researcher. Can be Contact on Linkedin.

0

Leave a Reply