Jump to content

exploit XSS reflected through POST method


pierre

Recommended Posts

Hello,

 

I was wondering how can an attacker exploit an XSS reflected vulnerability detected via POST method.

Indeed, a malicious link can't be crafted and sent to the victim..

Can you shed light on this to me if it possible ?

 

tks :)

Link to comment
Share on other sites

Use an auto submitting form in a hidden iframe on a site you host. Something like this:

<form method="post" action="vulnerable site">
<input stuff>
</form>

<script>
document.form[0].submit
</script>

 

Link to comment
Share on other sites

I'll take a stab as I think maybe there is some confusion or language barrier here. Hopefully helps clear things up, or can ask the question a different way afterwards.

Few things here to understand. Reflected XSS by nature, is from a foreign URL, ie: malicious link, or modified site URL that can run XSS from it's URL itself that you get a victim to click or load somehow. If your're looking for XSS that is NOT a foreign link, then on the server itself, stored XSS would be needed.

If the site is vulnerable to XSS via it's own URL manipulation, passing to a user the URL with the appended XSS is in a way, reflected XSS, but still requires you to get the user to click or visit the crafted URL somehow. Form submissions can be done via JS, so if it's vulnerable to XSS, you can auto submit a form for the user with info filled in, like, changing a users password, which would fall more under request forgery if the user executed the URL for you while logged in and posts the data where it needs to go.

In any event, getting the victim to execute the intended url, foreign or local to the site they are a user of, is required for the most part, as where stored XSS would load for everyone who visit the page with the embedded XSS.

Link to comment
Share on other sites

On 7/12/2017 at 2:39 PM, digip said:

I'll take a stab as I think maybe there is some confusion or language barrier here. Hopefully helps clear things up, or can ask the question a different way afterwards.

Few things here to understand. Reflected XSS by nature, is from a foreign URL, ie: malicious link, or modified site URL that can run XSS from it's URL itself that you get a victim to click or load somehow. If your're looking for XSS that is NOT a foreign link, then on the server itself, stored XSS would be needed.

If the site is vulnerable to XSS via it's own URL manipulation, passing to a user the URL with the appended XSS is in a way, reflected XSS, but still requires you to get the user to click or visit the crafted URL somehow. Form submissions can be done via JS, so if it's vulnerable to XSS, you can auto submit a form for the user with info filled in, like, changing a users password, which would fall more under request forgery if the user executed the URL for you while logged in and posts the data where it needs to go.

In any event, getting the victim to execute the intended url, foreign or local to the site they are a user of, is required for the most part, as where stored XSS would load for everyone who visit the page with the embedded XSS.

I think what Pierre is saying is that reflected XSS is typically successful because you (the attacker) inherit the trust of the company's official (and often well known) URL. When a malicious email is sent, most people are often fooled by the quick hover to make sure the link points to where it says it points; therefore clicking through to execute the payload. I think he's wondering how to find that same trust in a POST XSS vulnerability, without having to create a website of his own, with little or no trust.

Edited by Decoy
Link to comment
Share on other sites

39 minutes ago, Decoy said:

I think what Pierre is saying is that reflected XSS is typically successful because you (the attacker) inherit the trust of the company's official (and often well known) URL. When a malicious email is sent, most people are often fooled by the quick hover to make sure the link points to where it says it points; therefore clicking through to execute the payload. I think he's wondering how to find that same trust in a POST XSS vulnerability, without having to create a website of his own, with little or no trust.

A POST is generally going to be a form submission of some kind. It's something that requires user interaction normally, but does't have to be. Any site or web app can post data at continued intervals if needed with various requests methods in the background, depending on what info they are gathering, such as analytics data. 

Doesn't matter where the code is stored so much as it's getting the victim to execute it in the context needed, ie: user on a specific site that has privileges you want to leverage for your own purposes such as delete a user, add a user, change a password or site setting in something like WordPress, CMS, Social network site like Twitter, FB, etc. This is the "reflected" part.

POST of a form using the XSS as Digninja explained, can be auto submitted with JS to do what you want. Whether hosted on your own site, or on the target site itself as Stored XSS, it's still reflected in that it's meant for a specific user in the context the attacker needs. Sure, others can trigger this if viewing, but if they aren't a person of interest with something specific to the target person or site or have the "trust" of the user and site in question, its not going to be as useful. Other methods of XSS for POST, could be something like a malicious ad/iframe injected into the victims viewed pages, private message on social network, text message, or from the same LAN and injected with MITM attacks. Attacking an ad network would also allow you to blanket a wider audience, so security to block CSRF is required on the sites themselves, and something a site like say Facebook, would have to guard against and test for regularly.

If this isn't executed by the user in the context of the site the attacker is targeting and at a level of user privilege the attacker needs, doesn't matter if it's a POST, GET, XMLHTTP request, etc. Code needs to be viewed in some way to trigger and run in the context of the target site and victim combination. Trust is required in this context for it to be of any use.

------

2 things in the ops questions.

1) how can an attacker exploit an XSS reflected vulnerability detected via POST method

Digininja explained, but I'm somewhat confused by his stating "a malicious link can't be crafted and sent to the victim".

2) I see but the site is supposed to be malicious by default (or has been modified by a hacker)

Which site here? Either site doesn't have to be malicious necessarily. The attacker site can host the XSS, but the target site doesn't have to be modified to carry out the attack. The victim merely needs to view the attackers code, whether on the attackers site, or stored XSS on the target site itself, ie: guesbook or blog comments, etc. What you make the victim do, is the "malicious" part, such as what happens when the form or data is "posted" to the target site. Doesn't have to harm the users PC, or even their account, although changing passwords or deleting their account I guess would be malicious, getting something to execute as the logged in user doesn't have to be malicious in intent. Could be as simple as a pentester posting a message to the user them self, from them self or gathering info from their account, or posting to the attackers account for intent to educate the victim, like phishing emails used in a pentest against companies for education purposes, training or audits.

Link to comment
Share on other sites

A lot of good points. I guess there's a fine line between XSS and CSRF. A large portion of sites (smaller) don't implement CSRF tokens, so code (site functions) can be executed from anywhere on behalf of the authenticated user as you stated above. The XSS via Post is different in that it happens when the response comes back and executes the additional code (malicious payload) as a result. Either way - the attacker would have to do this using those methods as it's not possible to send someone a link for an XSS POST vulnerability like you can with a GET request.

Link to comment
Share on other sites

10 hours ago, Decoy said:

Either way - the attacker would have to do this using those methods as it's not possible to send someone a link for an XSS POST vulnerability like you can with a GET request.

It all comes down to the scenario in place.

What is the target site using/expecting : GET, POST, REQUEST? What happens when form data is submitted: is it nonced/tokenized, is it echoed back on screen exactly as submitted - ie: search form allowing in page XSS injection, is it posting to an admin panel and using the trust of a users logged in context.

These things need to be stated beforehand, and then you can work our what attack method to try, obfuscation and fuzzing to bypass weak filtering, etc.

In the example here, they are using a GET method which contains in the URL the script to run:

https://www.incapsula.com/web-application-security/reflected-xss-attacks.html

However, in case of a site that only accepts POST but echoes back code you can inject, you would add one more hop in this scenario, where when they click the link, they visit your site first, which then triggers the automatic POST and redirects the user right away to the target site. In this respect, its still reflected, just using a POST and an extra step for injection, but also possibly CSRF at the same time depending on what your POST does on the target system. If it hits a vulnerable form that echoes back the data only via a POST and not a GET with URL params, then a POST from your site would be needed. Same if the back end required a POST to change something in user context. If the site allowed a GET with URL params, and the target site has no filtering, nonce/tokens, then you can embed the script directly in a single URL you send to the victim(might require URL encoding). It depends on what the target site requires and accepts, which in the OP's original post(s), we don't know 100% the scenario in place.

 

 

Link to comment
Share on other sites

Ohh, I wanna stab at this too.  :-)

Foreign is from the attacker site.  It is used to post data to a site using the victims identity.  Case in point, the user never signs off a bank site and is persistent.  A malicious site can post data to that site by your just visiting their page if they know how the data is posted.  Since you have an open session with them it will post.  Only positive is they cannot receive back data and do two way communication through you, just sending so it is blind so to speak.  CSRF tokens were made to prevent this where you need to acquire before submission and submit with your post to validate the post is from you.

Local CSRF or XSRF (same thing) I even think XSS is cross site scripting.  If it is local to the vulnerable site then that means an attacker can post html/jscript code as a submission and it will show up in any read back forms as code instead of htmlencoding.  This means it will run the jscript or html.  So anyone who views the attacker's post will run that code which can be code to post to the attacker's site your session cookie.

See Sammy and MySpace worm.  That is just CSRF where MySpace was vulnerable at display unfiltered user input and no csrf tokens to prevent posts.  Don't know if csrf tokens would have worked since the attack was on the same domain so automated input/output might have been possible to get the token and submit.

Link to comment
Share on other sites

9 hours ago, PoSHMagiC0de said:

Ohh, I wanna stab at this too.  :-)

Foreign is from the attacker site.  It is used to post data to a site using the victims identity.  Case in point, the user never signs off a bank site and is persistent.  A malicious site can post data to that site by your just visiting their page if they know how the data is posted.  Since you have an open session with them it will post.  Only positive is they cannot receive back data and do two way communication through you, just sending so it is blind so to speak.  CSRF tokens were made to prevent this where you need to acquire before submission and submit with your post to validate the post is from you.

Local CSRF or XSRF (same thing) I even think XSS is cross site scripting.  If it is local to the vulnerable site then that means an attacker can post html/jscript code as a submission and it will show up in any read back forms as code instead of htmlencoding.  This means it will run the jscript or html.  So anyone who views the attacker's post will run that code which can be code to post to the attacker's site your session cookie.

See Sammy and MySpace worm.  That is just CSRF where MySpace was vulnerable at display unfiltered user input and no csrf tokens to prevent posts.  Don't know if csrf tokens would have worked since the attack was on the same domain so automated input/output might have been possible to get the token and submit.

nonces/tokens generally thwart the CSRF attacks in that they add another layer of authentication that is only visible during session, which if they do use them, and a POST redirects the user to the target site, the attacker isn't going to know what value needs to be in there for the token short of a MITM and proxy before it goes back to the real site. They could in theory MITM and hijack the session and post as them, but that is a different attack than XSS, since side channel/session hijacking is in itself giving the attacker access to the users logged in session negating the need for XSS attack.

SSL blocks most of MITM sidejacking of sessions these days though, and HSTS makes it that much harder. There is SSL Strip V2, but I've never gotten it to work properly on my lab setup, nor SSL strip in general, but I haven't really dug into it since it's not something I see myself needing. I've no intent of ever using it other than if it comes in handy for a CTF, and just for the shear learning how it works. Ettercap used to work for me way back in the day, but even that doesn't seem to work properly any more and I've not played with Bettercap too much.

Link to comment
Share on other sites

11 hours ago, digip said:

nonces/tokens generally thwart the CSRF attacks in that they add another layer of authentication that is only visible during session, which if they do use them, and a POST redirects the user to the target site, the attacker isn't going to know what value needs to be in there for the token short of a MITM and proxy before it goes back to the real site. They could in theory MITM and hijack the session and post as them, but that is a different attack than XSS, since side channel/session hijacking is in itself giving the attacker access to the users logged in session negating the need for XSS attack.

SSL blocks most of MITM sidejacking of sessions these days though, and HSTS makes it that much harder. There is SSL Strip V2, but I've never gotten it to work properly on my lab setup, nor SSL strip in general, but I haven't really dug into it since it's not something I see myself needing. I've no intent of ever using it other than if it comes in handy for a CTF, and just for the shear learning how it works. Ettercap used to work for me way back in the day, but even that doesn't seem to work properly any more and I've not played with Bettercap too much.

I logged in to post on a post and accidentally posted it hear following the wrong and didn't know till I was done and now going to have to go to that thread and type the whole thing out again.  Doh!!

On the SSL thing...yeah, doing it against Chrome is difficult with some sites or impossible.  Example if Google sites used to be strippable back in the day but now it is next to impossible.  Banks should take note of Facebook too.  They too are not strippable.  Reddit is hard but is somewhat strippable.

Bank sites are very strippable but the trick to the whole strip thing is it works very well if they are sent to the site you want to strip via a link.  So in essence it works good on links.

Definitely try Bettercap, it seems to work really well.  I haven't used it in a couple of months but MiTMf seems to work too, a couple of months ago.  Would like to see some of the features MiTMf have translated over to Bettercap that it doesn't already have.

Link to comment
Share on other sites

Thanks for your answer.

What I will retain is that Reflected XSS vulnerability via POST method can't be exploited (or harder) throught "the malicious URL forged and sent to a victim" method.

(As opposite from the XSS reflected vulnerability via GET method exploited by sending a milicious URL to a victim.)

Regards,

Edited by pierre
Link to comment
Share on other sites

3 hours ago, pierre said:

Thanks for your answer.

What I will retain is that Reflected XSS vulnerability via POST method can't be exploited (or harder) throught "the malicious URL forged and sent to a victim" method.

(As opposite from the XSS reflected vulnerability via GET method exploited by sending a milicious URL to a victim.)

Regards,

Although for Pentesting POC purposes, you could use any of the methods above to still demonstrate the possible ramifications of leaving a vulnerability like that in place.

Link to comment
Share on other sites

Consider the following code:

<?php echo "This was successfully submitted with a POST. Query 'q' value: ".htmlspecialchars($_POST["q"],ENT_QUOTES | "ENT_HTML401","UTF-8"); ?>

Save this as test.php on your server.

And to send a POST to it via a link the following code(which only works on delivery via click in certain browsers that execute data URI)

<a href="data:text/html;base64,PHNjcmlwdD5kb2N1bWVudC53cml0ZSgnPGZvcm0gaWQ9ImR5bkZvcm0iIGFjdGlvbj0iaHR0cDovL3d3dy5hdHRhY2stc2Nhbm5lci5jb20vdGVzdC5waHAiIG1ldGhvZD0icG9zdCI+PGlucHV0IHR5cGU9ImhpZGRlbiIgbmFtZT0icSIgdmFsdWU9IlRoaXMgaXMgYSB0ZXN0Ij48L2Zvcm0+Jyk7DQpkb2N1bWVudC5nZXRFbGVtZW50QnlJZCgiZHluRm9ybSIpLnN1Ym1pdCgpOzwvc2NyaXB0Pg==">data in href url for reflected XSS via POST</a>

The base64 encoded URL, goes to a page on one of my domains which uses the same PHP snippet in the first code section above to grab the POST from the submitted form. Change the base64 string to point to your own server for testing or point at mine the way it is above if you want to try it from your desktop.

This merely submits a POST to a site, via a data URL. I'd be interested in seeing if anyone can figure out a way to make this work similarly for shortened URL's or other than via a data: URL to test with email clients, but this is more POC stuff really.  If you run your own URL shortener, it MIGHT be possible to put the above into a shortened URL for then passing to an email. This is theory, I haven't seen any that work any more. Used to be some back in the day but ones I tried recently barfed at putting in the data: url the way I have it above so you'd have to figure out the delivery method such as social engineering, or embedded in a malicious document that executes the URL in specific browsers that are vulnerable. Internet Explorer based browsers, as far as I know, are the only ones that ignore data URI's, but I don't have the latest versions or a Windows 10 box to test the Edge browser.

Emails generally don't let you embed a data: url that would work like an href link does, so probably won't work for email clients without contructing an email file manually to embed the href link and even then, you'd have to test what happens on click.

 

Edit:

I also totally forgot about king phisher. Could do something similar for email delivery using the POST from above like 

 

Edited by digip
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...