1

In some applications, the HTTP methods GET and POST can be used interchangeably.

For example, the application may expect a POST request, and the frontend will also send the data in a POST request, but if the request is tampered with, the data will also be accepted in a GET request.

An example for this behavior would be Javas getParameter or PHPs $_REQUEST, which both deliver GET as well as POST parameters.

  • Is this generally considered a security issue? Is it documented somewhere, for example as a CWE or by OWASP?
  • Does this issue have a name?
  • What are the dangers of POST to GET downgrade? One example I could think of would be the possibility to exploit CSRF issues via img tags, which means an attacker can place CSRF payloads on websites where they cannot post scripts, making it considerably easier to exploit the issue. Are there other benefits for attackers?
  • What - if any - are the dangers of GET to POST change?
1
  • 1
    The content of $_REQUEST is configurable, but also includes cookie values in addition to post and get by default
    – wireghoul
    Commented Jul 30, 2016 at 22:48

2 Answers 2

3

It is a bad practice as it makes the development more confusing in order to ensure that there is no overlay between the possible GET and POST parameters which are normally processed separately.

It also makes it a tiny bit easier for a hacker to benefit from a vulnerability in your site but it doesn't create breaches on its own.

In a well organized web application, the GET parameters are used for routing (page or module selection and relevant options) while POST parameters actually represent data submitted by the user. Following this simple guideline makes the development much more organized, so safer from errors on your end.

1

The OWASP ASVS does make mention of this vulnerability, see rule 11.1. While it does not make mention of this vulnerability at the method level, it does allude that the application should only accept defined sets of HTTP request methods.

I generally take this a bit further, and tie the guidance into the OWASP AppSensor project where you can utilize these changes in expected HTTP verbs as a potential detection point.

I do not believe there is any real danges of a POST to GET downgrade from a server perspective. As long as you are protecting against parameter pollution, and are monitoring traffic from an appsensor perspective, there is no damage. Obviously GET is passed on the query string and is logged by other devices in the chain. This is a client side problem IMHO and could only happen if your code (forms, html, javascript) was being changed (either via MITM or via bad javascript after render).

You must log in to answer this question.

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