4

I have been trying to learn about XSS, more specifically, POST based XSS. But I am unsure if I actually understand how POST based XSS works.

With a GET, you can do XSS with the URL parameters, but to exploit a POST based XSS, you need to use an HTML form(it can be disguised as link tag or whatever, but, ultimately, it is an HTML form), either on your own website, or on some other website that allows HTML forms to be created, then, inside of the HTML form inputs, you hard-code the exploitable parameters.

You can auto submit the form when someone lands on your website, or the user himself can click some button, maybe there are million different ways.

All in all, is the HTML form part, the main(only?) way to do it?

Thank you!

UPDATE: There is the javascript fetch method that can do POST requests too

UPDATE 2: If I get a user on my website that auto submits an HTML form, why would I need to do the XSS in the first place? I can already execute JS on my own website

Improve this question
1
  • I think you are talking about persistent (or stored) cross site scripting. Check OWASP for more details regarding this type of XSS. Additionally, to get a better understanding I suggest you'd use an intercepting proxy such as Burp Suite or Fiddler. With an intercepting proxy, you can see all requests and responses. In case you want to sent an HTTP POST request, you can easily modify its parameter values in order to send a malicious payload (XSS).
    – Jeroen
    Commented Aug 13, 2019 at 16:59

2 Answers 2

Reset to default
2

You seem to have a decent grasp of it. Anything that can redirect the user via a POST request can be used to exploit - this is often done via an HTML form but is by no means the only way it can be done. As you mentioned various javascript functions can also redirect the user.

The most significant difference between POST XSS and GET XSS is how you phish the user - it's unlikely that the webapp you're attacking will allow you to redirect users via a POST request, so they have to be phished to visit another page with that functionality. Both POST and GETS can exploit both reflected and stored XSS.

To answer the edit: it is significantly more valuable to achieve JS execution in the context of someone else's domain (website) than your own. If you can execute JS in my browser while I'm logged in to my banking app, you'll be able to make more requests to my banking app using my session and read the responses to those requests*. If the website is badly configured, you can also retrieve my session token. If there is CSRF protection, you'll be able to execute POST requests to the banking app if you have XSS, but not via the JS on your website (bypassing CSRF protections).

*Most of the time, assuming a typical SOP that isn't broken down into subdomains

Improve this answer
2

That's correct: if you want to exploit a POST-based XSS, you need the user to do a POST request with malicious to the exploited page.

This is most often done by adding a auto-submitting form in a HTML page hosted by the attacker. There are other techniques, like clickjacking, but hosting a HTML page is the easiest way to go.

Using the Fetch API isn't useful, since you would need to be able to run JS on the target site from the victim browser... so you wouldn't need to exploit a XSS at first place.

Improve this answer
3
  • Thank you for your answer, but I have a question for the last part of your answer, the Fetch part. If a user is already on my website, why would I need to do an XSS post attack? I can execute my own JS there and attack the user.
    – bobjohn43
    Commented Aug 13, 2019 at 16:49
  • 1
    @bobjohn43: you would do a XSS attack since you most likely want to run JS on the target site, not on yours. Same-origin policy prevents you to read / post data on another website.
    – Benoit Esnard
    Commented Aug 13, 2019 at 16:52
  • 1
    To clarify, SOP prevents you from reading responses from another website. POST requests get through fine, with some caveats. HTML forms don't have access to the response, and therefore get through fine. My JS knowledge isn't great, so I'm not sure what fetch uses behind the scenes, but something like xmlhttprequest won't work because that library has access to the response which triggers standard SOP checks. In other words, a simple redirect bypasses SOP, but any function that tries to retrieve the response will have to deal with SOP validation.
    – Buffalo5ix
    Commented Aug 13, 2019 at 17:04

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .