How is HTTP PUT and DELETE methods insecure, if they really are?

Question

If I really need to use these methods, how do i make sure they are secure?

Edit: Is there a link or source where I can see how to make sure that 'PUT' and 'DELETE' methods are not able to delete or update resource, but services and servlets are still able to use PUT and DELETE.

Following services are using PUT and DELETE HTTP methods

https://developers.google.com/drive/v2/reference/files/delete

http://developers.facebook.com/docs/reference/api/Comment/

http://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectDELETE.html

http://www.salesforce.com/us/developer/docs/api_rest/index.htm

http://developer.tradeshift.com/rest-api/#tsapi.conventions

http://developer.linkedin.com/documents/groups-api#create

https://developer.paypal.com/webapps/developer/docs/api/#delete-a-stored-credit-card

So, clearly there has to be a way of making sure that PUT and DELETE can be used without putting resource files to harm like HTML, CSS, JS, or images.

I have already edited the question to explain why this is an original question, so why is this still marked as 'Duplicate'? — gurvinder372, Jul 10 '13 at 08:28

score 12 · Accepted Answer · edited Oct 09 '15 at 18:32

PUT and DELETE are not intrinsically insecure, they are used without problems at many REST services for example.

In my practice the main problem related to these HTTP verbs (apart from the common authentication and authorization problems) was that the server operators weren't aware of their existence introducing the possibility of HTTP Verb Tampering. In summary this means that access control was implemented based on a HTTP verb blacklist but some lesser known verbs were missing from this list allowing access control bypass.

I'd like to note that many web servers implement their own custom (sometimes undocumented) HTTP verbs, so this kind of "Verb-Based Access Control" doesn't seem like a very good idea anyway.

Stephen Touset · Answer 2 · 2013-07-09T14:55:16.373

10

HTTP methods have little to do with security in and of themselves. A method like DELETE /users/1 could easily also be implemented as POST /users/1/delete or even GET /users/1/delete (GETs should never have side effects, but that doesn't stop some developers from doing so anyway).

You should therefore treat them similarly to any other HTTP method. GETs should not change server state, so typically you would only need to verify that the client has read access to the requested resource. PUTs should be used to update a resource wholly in-place (although they are often also used similarly to the PATCH verb), and so you should ensure that the client has the privileges to do this. Likewise, DELETE should be sent in order to request that a resource be deleted. So you would want to ensure a user has permission to do so.

In short: treat the verbs as descriptors of the type of action the user wishes to perform. Authenticate and authorize them to perform these actions as is required by the security parameters of your particular application.

edited Jul 09 '13 at 14:55

answered Jul 09 '13 at 05:57

Stephen Touset

5,736
1
23
38

1

"_or even `GET /users/1/delete`._" be careful with GET which is supposed to not have side effects. – curiousguy Jul 09 '13 at 06:23
@Stephen thanks for your comment. Do you have a link where someone has used PUT and DELETE for their services or servlets but still protected the resources – gurvinder372 Jul 09 '13 at 06:39
@curiousguy I'll clarify that. – Stephen Touset Jul 09 '13 at 14:54
@curiousguy That's not correct. It can have side effects. It must be idemopotent, which is not the same thing. If you configure your web server to accept a GET request to delete something that's fine as long as that delete can be called many times without doing anything the first request didn't do. – Jazzepi Nov 15 '17 at 20:48
@Jazzepi What kinds of side effects are allowed for GET? – curiousguy Nov 17 '17 at 02:16
@curiousguy Any. It's just a matter that calling the get endpoint again and again shouldn't be problematic. For example you can only embed GET requests in emails to people. Suppose you want to email someone a 'join game' link. It's going to have to be a GET request. That's okay! It just means your endpoint has to function properly to only join the person to the game once, and ignore the extra requests beyond the first. – Jazzepi Nov 17 '17 at 22:15
@Jazzepi Then be careful. If there is a well known URL that cause email being sent, it can be triggered with no more than an IMG element on any website, and many website will allow anyone to post a link to an URL to other site. Making a POST request requires (a little) more effort. – curiousguy Nov 17 '17 at 22:29

Lucas Kauffman · Answer 3 · 2013-07-09T06:12:11.057

8

From the OWASP testing guide:

Some of these methods can potentially pose a security risk for a web application, as they allow an attacker to modify the files stored on the web server and, in some scenarios, steal the credentials of legitimate users. More specifically, the methods that should be disabled are the following:

PUT: This method allows a client to upload new files on the web server. An attacker can exploit it by uploading malicious files
(e.g.: an asp file that executes commands by invoking cmd.exe), or by simply using the victim's server as a file repository

That said there are actually two things you need to take care of.

If you want to allow these users to make new content make sure that you only allow it for authenticated users you trust. These users should be trusted to the extent that you would allow them to have an FTP account.
If you would allow them to alter existing content, make sure you restrict it in such a way that they indeed can only overwrite certain existing resources and nothing else.

Also make sure that you are using SSL/TLS.

edited Jul 09 '13 at 06:12

answered Jul 09 '13 at 05:55

Lucas Kauffman

54,169
17
112
196

better still, an **SFTP** account. – Deer Hunter Jul 09 '13 at 06:03
1

FTP is the protocol, the S is just the encapsulation – Lucas Kauffman Jul 09 '13 at 06:10
3

@LucasKauffman -1; SFTP is a part of SSHv2. – curiousguy Jul 09 '13 at 06:25
2

@curiousguy - yup. FTPS is FTP over SSL. SFTP is not FTP over SSH (which is another protocol), but a new file transfer protocol that's part of SSH. To quote [wikipedia](http://en.wikipedia.org/wiki/SSH_File_Transfer_Protocol) "SFTP [SSH File Transfer Protocol also Secure File Transfer Protocol] is not FTP run over SSH, but rather a new protocol designed from the ground up by the IETF SECSH working group." – dr jimbob Jul 09 '13 at 06:38
@LucasKauffman Thanks for your reply. I don't want to allow any user to DELETE or PUT any resource, but use these methods for services and servlets only. If there a way to make sure that resources can't be accessed without GET method? – gurvinder372 Jul 09 '13 at 06:41
Can you elaborate on this? – Lucas Kauffman Jul 09 '13 at 07:19
2

Let's all agree that we need to a security layer. I did not intend to promote plain FTP or HTTP. Please don't kill me :( – Lucas Kauffman Jul 09 '13 at 07:20
@curiousguy Really? -1 (meaning the answer is useless) because he got one small and easily correctable detail wrong in a comment? – Adi Jul 09 '13 at 08:01
@Adnan "_Really?_" No, not really. – curiousguy Jul 09 '13 at 08:30
@curiousguy Good. – Adi Jul 09 '13 at 08:43
@LucasKauffman I have edited the question, please have a look – gurvinder372 Jul 09 '13 at 08:51

score 2 · Answer 4 · edited Jul 09 '13 at 08:01

for the records: RFC 2616 Hypertext Transfer Protocol HTTP/1.1 / Method-Section

a REQUEST is a request from a client to the server and dont say much about what the server will be doing with that request; possible methods dont have to be implemented on server-level.

so if you go to myserver.com and ask for "DELETE /blah" myserver.com might simply say: "thanx, sir, and have a nice day".

9.6 PUT

The PUT method requests that the enclosed entity be stored under the supplied Request-URI.

9.7 DELETE

The DELETE method requests that the origin server delete the resource identified by the Request-URI. This method MAY be overridden by human intervention (or other means) on the origin server. The client cannot be guaranteed that the operation has been carried out, even if the status code returned from the origin server indicates that the action has been completed successfully

How is HTTP PUT and DELETE methods insecure, if they really are?

4 Answers4

Related