Security Implications of GET/POST InterchangeabilityDate: 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.While this desired behavior of the HTTP methods is well-defined in RFCs, some applications choose to treat GET and POST requests interchangeably. This is not only a violation of standards, but can have several security implications which are discussed below.
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.
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.
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.
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.
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.