HTTP Verbs and Their Security Risks

Ask us about your FREE AppCheck Trial

In this article we’ll look into what HTTP “verbs” or methods are, how each varies and works, and what the potential security risks are that should be considered with each. We’ll also see how vulnerability scanners such as AppCheck can automatically check for many of the potential vulnerabilities presented by webservers making use of these methods.

HTTP Primer

At its root, HTTP is a protocol that allows a typically remote network client to perform actions on web documents and other resources that are located on remote servers. We’re all most familiar with the retrieval of documents – we request the contents of the BBC news homepage, and it is returned to us – but HTTP supports a full range of CRUD (Create, Read, Update & Delete) to be performed across the network. Simple examples might include the creation of a remote resource via file upload to an image host, or the creation of a new page on a web forum containing the contents of your new “post”.

The request structure for HTTP requests is fairly simple. Let’s look at a very basic example:

GET /hello.htm HTTP/1.1

Host: www.example.com

In the example above, the first line is the one that indicates the type of the request to be made in the form:

[verb / method] [resource] [http version]

So, what are HTTP verbs?

HTTP Verbs

A verb within the context of language and syntax can convey several different things, but most typically is associated with actions (for example – bring, read, walk, run, learn, hit). This is the meaning that applies to HTTP verbs or methods – functions that instruct a web server what type of action to perform on the target resource specified by the client.

According to RFC 2616, which defines HTTP modes of operation, there are eight defined HTTP methods for HTTP version 1.1, specifically: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, and CONNECT. There are also extended HTTP methods such as web-based distribution authoring and versioning (WEBDAV). WEBDAV can be used by clients to publish web contents and involves several other HTTP methods such as PROPFIND, MOVE, COPY, LOCK, UNLOCK, and MKCOL. A webserver is free to “pick and choose” which of these operations it permits, it is not obligated to support all these methods in order to comply with the RFCs.

We’ll look at each of these methods below, some of which you are likely familiar with but some perhaps less so. We’ll also outline the potential risks and pitfalls with each that need considering. When HTTP methods are not understood, are offered inadvertently, or are not explicitly included in testing and defined behaviour, or, when they are configured improperly, any of them can potentially be used for malicious activity.

1. “GET”

Description

The “GET” method is used to retrieve the contents of a document such as a web page, or other resource such as images, CSS, and JavaScript from a web server. GET requests are the most common HTTP verb – when you click on a link in your browser, or type in a URL in the address bar, your browser will normally convert that into a GET request. Requests using GET are intended only to retrieve data, although they are widely used in other CRUD operations in many web applications.

Potential Vulnerabilities

One of the main vulnerabilities inherent in GET requests is that any user-provided input is submitted as key-value pairs submitted within the query string within the request URL, as in the example below:

GET /documents/113.asp?startPage=7&endPage=9 HTTP/1.1

Host: www.example.com

The issue with this is that URLs are often stored (including query strings) within various caches, from the user’s browser history to web proxy and CDN caches, web server logs, and several other sources. If the query string containing the user-submitted information includes sensitive data, then it may be readable by attackers and used in further attacks.

The second vulnerability type that GET requests enable relates to the fact that GET requests can be made simply by clicking on a single link. Whilst not unique to GET requests, vulnerabilities including the below are most associated with GET requests:

Cross-Site Request Forgery (CSRF) in which an attacker can force an end user to execute unwanted actions on a web application in which they’re currently authenticated. For example, if an online banking app supports GET requests for account transfer an attacker could trick you into clicking on a link such as https://www.onlinebankexample.com/transfer?amount=10000&fromAccount=12345678&toAccount=87654321 in order to empty your account
Cross-Site Scripting (XSS) in which an attacker is able to trick a user into clicking a link that is structured with content that when processed by a vulnerable server, injects malicious scripts into the server responses to the victim, which can be used to bypass access controls such as the same-origin policy – for example https://example.com/search?q=<script%20type=’application/javascript’>alert(‘xss’);</script>

2. “PUT”

Description

The PUT method is intended to be used to replace the current contents of the resource at a target path with the payload provided by the user. For example:

PUT /new.html HTTP/1.1

Host: www.example.com

Content-type: text/html

Content-length: 16

<p>New File</p>

Potential Vulnerabilities

The most obvious potential vulnerability with the PUT method is if there is insufficient access control such that the server failed to provide sufficient checks as to whether the request is appropriately authorized. If an attacker can find a PUT method unprotected by appropriate access control, or else bypass access control that has been put in place, he may be able to upload a resource to the server.

If the attacker can upload static files only, he could upload a static HTML page containing hyperlinks that redirect victims to a malicious website or a malicious login form. In a scenario where the attacker is able to upload dynamic files such as PHP or ASP files that permit server-side processing, then this may permit the attacker to upload and run arbitrary code on this web server that may lead to compromise of other users or the server.

Additionally, an attacker may be able to corrupt or replace the contents of a legitimate PUT request using a Man In the Middle (MITM) attack if the server is not protected by SSL/TLS transport layer encryption.

3. “DELETE”

Description

The DELETE method simply instructs the browser to delete the specified resource:

DELETE /file.html HTTP/1.1

Host: www.example.com

Potential Vulnerabilities

If the DELETE method is exposed to an untrusted audience, this might allow an attacker to delete files on this web server. The most obvious impact would be to server content, effectively performing a Denial of Service attack if content is deleted – if content is not backed up in then it may be permanently lost.

A more subtle variant of this attack would be if the attacker were able to remove server-side configuration files, such as “.htaccess” in an Apache server, to gain unauthorized access in such a way that the organisation may not immediately notice the compromise.

4. “HEAD”

Description

The HEAD method asks for a response identical to that of a GET request, but without the response body. It was originally intended to provide the ability to allow a requesting user preview the download of a large resource via the metadata in its headers before making the main GET request in order to save bandwidth, for example:

HEAD /index.html HTTP/1.1

Host: www.example.com

Potential Vulnerabilities

HEAD requests can be used to perform a subtle form of access control bypass. For example, imagine a scenario in which an attacker is presented with a secure resource that is protected by access control when a GET request is made. It is probable that the access control applies universally to all requests made to the given path/resource, but in some situations the access control may have been mis-configured to apply specifically to requests made via GET method only – making a HEAD request may permit the attacker to bypass the access control and gain access.

5. “POST”

Description

The HTTP POST method sends data to the server, often causing a change in state on the server. The type of the body of the request (the format of the data payload included) is indicated by the Content-Type header. A POST request is typically sent via an HTML form and looks like:

POST /test HTTP/1.1

Host: www.example.com

Content-Type: application/x-www-form-urlencoded

Content-Length: 27

field1=value1&field2=value2

Potential Vulnerabilities

The POST method is described as not safe. This has a very specific meaning that POST operations change the data requested, i.e., it is not a read-only method. Unlike PUT requests, however, POST requests are not idempotent in that the result will not be the same no matter how many times you request it. It therefore matters how many times a POST request is made. For example, consider the example in which a bank transfer is authorised via a URL such as:

https://www.example.com/transfer?amount=10000&fromAccount=12345678&toAccount=87654321

Some endpoints can therefore be vulnerable to exploits including timing attacks, in which an attacker can potentially make several of the same request in quick sequence, allowing in the above example for multiple bank transfers to be actioned before the transfer to be marked as complete.

6. “CONNECT”

Description

The HTTP CONNECT method starts two-way communications with the requested resource. It can be used to open a tunnel. The client asks an HTTP Proxy server to tunnel the TCP connection to the desired destination. The server then proceeds to make the connection on behalf of the client. Once the connection has been established by the server, the Proxy server continues to proxy the TCP stream to and from the client:

CONNECT www.example.com:443 HTTP/1.1

Potential Vulnerabilities

If the CONNECT method is exposed inadvertently, it could allow an attacker to use the web server as an unintended proxy or intermediary (often called a ‘Confused Deputy’). If an attacker cannot directly contact a target, but the web server itself has access to the target, then the attacker can send a request to the web server and have it be forwarded from the target web server. The request would appear to be coming from the web server itself, not the attacker’s system. As a result, the attacker can bypass access controls (such as firewalls) or hide the source of malicious requests.

7. “OPTIONS”

Description

The OPTIONS method is used to request a list of available HTTP verbs or methods for the target resource. It is intended as a diagnostic method to be used for debugging purposes, but is also used within REST APIs and other systems. A client can either specify a URL for the OPTIONS method, or an asterisk (*) to refer to the entire server. For example:

OPTIONS /index.html HTTP/1.1

HTTP/1.1 204 No Content

Allow: OPTIONS, GET, HEAD, POST

Potential Vulnerabilities

OPTIONS is a relatively safe method, in that it is safe (doesn’t make any changes to resources on the server). The only potential vulnerability that exists relating to the OPTIONS method is that it can be considered a shortcut to find which methods the target server supports. If the server presents only the eight standard methods listed in the original HTTP 1.1 specification, this is of little direct value to an attacker, since it is trivial for an attacker to simply check each in turn directly even without the OPTIONS method. However, in the event that the server provides custom methods, then the OPTIONS method may help a malicious user to prepare more advanced attacks by providing insight into non-standard methods that the endpoint supports.

8. “TRACE” / “TRACK”

Description

The TRACE method performs a message loop-back test on a target webserver – the client makes a request to a webserver and the webserver reflects the message received back to the client in the body of a 200 (OK) response. The TRACK method works in the same way but is specific to Microsoft’s IIS web server:

TRACE / HTTP/1.1

Host: foo

HTTP/1.1 200 OK

Content-Type: message/http

TRACE / HTTP/1.1

Host: foo

Potential Vulnerabilities

The TRACE method, while apparently harmless, historically it could be successfully leveraged in some scenarios to steal legitimate users’ credentials in an attack known as Cross Site Tracing. Tagging a cookie as HttpOnly prevents JavaScript from accessing it, protecting it from being sent to a malicious third party. However, since the TRACE method reflects back Cookies as plaintext in the response, rather than as cookie objects within the DOM, the TRACE method can be used to bypass the protection measures. Note that browsers no longer allow the TRACK and TRACE methods to be used from JavaScript to prevent this attack, and with the depreciation of Flash, Active-X and Java Applets it is unlikely that this attack will be prevalent until a new means of an attacker issuing the TRACK or TRCE method cross site and reading the response is discovered.

However, the TRACK and TRACE methods may still be useful to an attacker in scenarios where the request passes through intermediary systems which add headers or other information to the request before passing it onto the server which constructs the response, thus disclosing the information that was added to the attacker.

9. “PATCH”

Description

Unlike the HTTP PUT method that we’ve already looked at and which only allows complete replacement of a document, the PATCH method is used to apply partial modifications provided by a client to an existing resource. PATCH is not idempotent, meaning successive identical patch requests may have different effects:

PATCH /file.txt HTTP/1.1

Host: www.example.com

Content-Type: application/example

If-Match: “e0023aa4e”

Content-Length: 100

[description of changes]

Potential Vulnerabilities

The security considerations for PATCH are nearly identical to the security considerations for PUT but there are two additional risks. The first is that the integrity of the target resource is more readily susceptible to attacks, because of PATCH’s non-idempotent nature – that is, if a document is patched with the same patch twice when only a single patch was intended, it might be corrupted. For example, if an attacker is able to trigger a replay attack in which the same (legitimate) request from a user to delete a single line of a file is submitted multiple times, then multiple lines of the target document could be deleted, causing undesired effects.

The second vulnerability specifically relating to PATCH relates to its ability to split or smuggle harmful payloads across multiple requests in order to bypass pattern-based detection techniques such as Web Application Firewalls (WAFs). For example, an intermediary HTTP security device such as a WAF may be configured to prevent writing of “<script>” tags to files using POST bodies. However, the PATCH method complicates such watch-keeping in that an attacker could build up the remote malicious tag by submitting one character at a time in successive PATCH requests:

PATCH /file.txt HTTP/1.1

10. “DEBUG”

Description

DEBUG is not a standard HTTP method but represents a proprietary extension of the HTTP method specification supported within Microsoft’s ASP.NET 2.0 applications. When the <compilation debug=”true”/> configuration setting is enabled, then a client making an HTTP request that contains the DEBUG verb can perform start/stop actions on remote debugging sessions:

DEBUG /foo.aspx HTTP/1.0

Accept: */*

Host: www.example.com

Command: stop-debug

Potential Vulnerabilities

The most common vulnerability that this presents to a server is that the performance overhead on the server is far greater once DEBUG mode is enabled – the compilation of ASP.NET pages takes longer, code can execute slower, and much more memory is used within the application at run-time. This means that an attacker able to enable remote debugging can effectively trigger legitimate clients to perform a Denial of Service attack just by making subsequent routine requests and bringing the server to its knees under what would otherwise be normal traffic levels.

There is the possibility that support for DEBUG mode may also cause the server to reveal information not intended to be provided. The actual debugging itself is done via an RPC protocol so direct access to debugging information is not possible – however, indirectly the errors and stack traces potentially thrown by a server under extreme load and DoS conditions may provide system configuration information that permits an attacker to focus/narrow further attacks to the system.

11. “CUMBERBUND-BANDERSNATCH”

Description

OK so this isn’t a real one – or at least, it’s not a standard method in the HTTP specification. However, arbitrary HTTP methods are permitted to be used as an extension of the specification. The exact method names may be proprietary or only discoverable through documentation or used of the OPTIONS method outlined above.

Potential Vulnerabilities

The most typical vulnerabilities seen in arbitrary methods used within several languages and frameworks is where the methods act essentially as extensions of the “GET” method but where access control checks are applied inconsistently on a per-method basis, allowing unauthorized submission of privileged requests.

Defences

In general servers should reject requests with a HTTP method that is not explicitly expected for a resource (i.e., return a HTTP 405 Method Not Allowed response), and non-standard HTTP methods should be avoided where possible.

Ensure the DEBUG method is disabled when not explicitly required for debugging, it is unlikely that this method should ever be used in production.

Ensure the server and application properly enforce access controls and other validation on all requests regardless of the HTTP method used in the request. Malformed requests (e.g., a GET request with a body) should be rejected to prevent issues due to parsing differences in different parts of the application.

How can AppCheck Help?

AppCheck help you with providing assurance in your entire organisation’s security footprint. AppCheck performs comprehensive checks for a massive range of web application vulnerabilities from first principle to detect vulnerabilities in in-house application code. AppCheck also draws on checks for known infrastructure vulnerabilities in vendor devices and code from a large database of known and published CVEs. The AppCheck Vulnerability Analysis Engine provides detailed rationale behind each finding including a custom narrative to explain the detection methodology, verbose technical detail, and proof of concept evidence through safe exploitation.

Ask us about your FREE AppCheck Trial