Security Implications of GET/POST Interchangeability

Date: 2016-11-03 18:40:29

This article will provide a short overview of the security implications of treating POST and GET requests interchangeably, thus allowing a POST to GET downgrade. It will conclude with possible solutions.

1. Problem Description

The HTTP protocol allows the usage of different HTTP methods. The most relevant ones for web applications are POST and GET. While GET should only be responsible for retrieving data from the server, POST can be used to send data to the server and thus change the server state.

2. Security Implications

Downgrading a regular POST request to a GET request makes it easier for attackers to exploit other vulnerabilities that may exist in the application such as XSS, CSRF, Reflected File Download, Open Redirect, or Session Fixation. Basically any time the attack targets the user, an attacker would prefer to deliver the payload in a link via GET instead of using a form via POST.

To successfully exploit the previously named issues via POST, an attacker would need to be able to create form tags. If they do not want to resort to getting the victim to submit the form themselves via social engineering, they would also need to be able to create JavaScript tags to submit the form automatically. It is unlikely that the affected application itself allows this, thus the attacker has to use third party websites and lure their victim there. The success rate for this increases with the reputation of the third party website, but most reputable sites will not allow the creation of JavaScript tags either. Thus an attacker would need to create their own website, which would reduce the rate of success of their attack, as the victim would be less likely to trust it.

Payload Delivery via POST

To deliver a payload via POST, an attacker would have to place the following payload on a website that accepts the given tags:

<form enctype="multipart/form-data" id="myform" method="post" action="http://application.com/vulnerable_script.php" > <input type="hidden" name="argument" value="payload"> </form> <script>document.myform.submit();</script>

If the vulnerable application can be loaded in an iframe, the form could also be submitted into that frame to avoid a suspicious redirect when submitting it, but as described above, this delivery method is not ideal for an attacker.

Payload Delivery via IMG Tag

If the application accepts input via GET, the payloads for Session Fixation as well as CSRF can be delivered via IMG Tags:

<img src="http://application.com/session_fixation/index.php?sid=123"> <img src="http://application.com/csrf/new_user.php?username=admin&password=admin">

This is a rather large advantage for an attacker as it may be possible to place image tags into the vulnerable application itself. In that case, a victim would only need to interact with the application as they normally do, and the payload would be triggered automatically, without the need for them to perform any specific action.

Even if the application itself does not allow image tags, many reputable websites do. An attacker may even be able to figure out which websites a victim is most likely to visit and place their payload there.

Payload Delivery via Link

XSS, Reflected File Download, and Open Redirect payloads would not be executed in an image tag, but they may be included in a link:

<a href="http://application.com/xss/index.php?x=<script>alert(1)</script>">click me</a> <a href="http://application.com/rfd/index.php/setup.bat?x=||calc||">click me</a> <a href="http://application.com/open_redirect/index.php?x=http://evil.com/">click me</a>

In contrast to using an image tag, this does require specific actions by the victim, but the POST to GET downgrade still provides benefits to an attacker, as the link that they would distribute to a victim would link to a reputable website or the target application itself instead of an untrusted website controlled by the attacker.

Additionally, without a POST to GET downgrade present, an open redirect vulnerability in a POST parameter would not be exploitable by an attacker, and in the case of Reflected File Download another advantage is that no unexpected download popup is created, thus making it easier to get the victim to download the file via social engineering.

Interaction with Open Redirect: Bypassing of CSRF protection

If the CSRF protection of the application is based on referer checks, and if an open redirect vulnerability exists in the application, a POST to GET downgrade would enable an attacker to bypass the CSRF protection:

<a href="http://application.com/open_redirect/index.php?x=/csrf/new_user.php?username=admin&password=admin">click me</a>

Inadequat Code Design

In addition to the direct impact on the security of the application described above, an interchangeability of GET and POST also points to poor coding practices. The GET and POST methods should have very specific tasks, and should not be seen as interchangeable. If they are treated like this in the backend, it may be easier for a frontend developer to use the wrong method, thus likely exposing sensitive data in the URL, which in turn would have a measurable security impact.

3. Discovery & Verification

To discover or verify a POST to GET downgrade, one simply has to intercept the original POST request - for example with Burp or the Tamper Data Firefox plugin - and copy the POST variables into the URL. If the submitted URL is processed in the same way as the POST request by the application, then it is affected.

4. Causes & Solutions

GET/POST interchangeability exists because the application treats GET and POST data the same way, and does not check the HTTP method when processing requests.

PHP

In PHP, the problem exists when accessing data via $_REQUEST instead of the more specific $_POST and $_GET variables.

The solution is to simply use the specific $_GET and $_POST variables to access the data.

If the used framework only supplies one generic method to access POST as well as GET, the $_SERVER['REQUEST_METHOD'] should be checked for each request manually. Alternatively, the framework may supply a routing functionality, which may make it possible to define exactly which requests are allowed and which are not.

Java

In Java EE, the problem is generally more prevalent than in PHP, as Java does not provide separate functions to access GET and POST data. The only function providing this data is getParameter of ServletRequest.

Thus, a developer has to explicitly check the HTTP method via the getMethod function. The used framework may also provide specific methods to retrieve only GET or POST, or may provide a routing functionality regulating which requests are allowed and which are not.

5. Conclusion

While GET/POST interchangeability does not directly enable an attacker to harm the application, it does make it easier - sometimes considerably so - for an attacker to exploit other vulnerabilities. The solution is to treat GET and POST as separate data sources, and to correctly restrict which will be used for what requests.