URL vulnerabilities can be avoided if the post method is used?

Question

If I have a form that accepts inputs through the GET method, and can be generated vulnerabilities as XSS.

Using the POST method is possible to prevent vulnerabilities that can be generated through URL's?

For example, the following code is vulnerable to XSS, if the url is:

example.com/?nickname=<script>alert("XSS")</script>.

<form method="get" action="">
    <input type="text" name="nickname"/>
    <input type="submit" value="Send">
</form>

<?php
  if(isset($_GET['nickname'])){
    $nickname= $_GET['nickname'];
    echo "<div>Your nickname is $nickname</div>\n";
  }
?>

Using the post method can completely avoid this vulnerability, or you can continue exploiting?

Answer 1

No, using POST is no defense against XSS at all.

Sure, an attacker cannot simply send you a link that contains the payload, but they can send you a link to a webpage which contains HTML/JavaScript that submits the payload.

Example:

<form method="post" action="http://yourserver.com/yourscript.php" id="myform">
    <input type="hidden" name="[XSS payload]"/>
    <input type="hidden" value="Send">
</form>
<script>
document.getElementById('myform').submit();
</script>

The attacker could also submit the form in a hidden iframe or otherwise hide the attack so that a victim doesn't notice it.

If on the other hand you have CSRF protection for your POST requests - which you should have - exploiting reflected XSS attacks via POST will get more difficult or impossible.

There are very few vulnerability classes which do get less beneficial for attacks if done via POST, Open Redirect would be an example (phishing isn't possible anymore, but CSRF protection that relies on a referer check may still be exploited in some situations).

Answer 2

Using POST offers the following advantages over GET:

Avoid the browser's URL history. Any sensitive data in the form is not passed in the URL, which means that data in the form are not visible in the browser history and cannot be shoulder surfed once submitted. (Note: the form body is sometimes stored, depending on browser and settings, but is usually not visible).

Ability to pass hidden tokens. Using POST gives your application the flexibility to include more fields (there is a hard limit on the length of a GET request), including such important things as CSRF tokens, ViewState MAC checksums, etc. You would not want to show these fields in the address bar.

Less Logging. Data in the URL itself is held in an HTTP header, which is more likely to be logged by intermediate network appliances (e.g. if using SSL offloading or deep packet inspection), or by web server logs. IIS, for example, logs the entire URL and querystring with each and every request, by default, and this gets stored in a flat file which sits on your web server forever. Data in the form body, on the other hand, is not logged by default.

Avoid sending PII to analytics. If there is sensitive information in the URL, you risk that data ending up being sent to any analytics solutions or third parties you are using. Generally speaking, data in the form body isn't going to end up getting sent unless you went out of your way to code for it.

Does using POST automatically mitigate the risk of CSRF? NO!! But typically a CSRF mitigation will involve using HTTP POST + an anti-CSRF token, so I could see why you'd think these go together. Without the token, the POST verb does nothing in and of itself to mitigate CSRF via reflected or stored XSS.

Answer 3

No, input sanitisation is the more effective control to mitigate XSS in this case: https://www.owasp.org/index.php/Input_Validation_Cheat_Sheet