Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

This question already has an answer here:

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.

share|improve this question
    
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 8:28
add comment

marked as duplicate by AviD Jul 9 '13 at 7:56

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

4 Answers

up vote 4 down vote accepted

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.

share|improve this answer
add comment

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.

share|improve this answer
    
better still, an SFTP account. –  Deer Hunter Jul 9 '13 at 6:03
1  
FTP is the protocol, the S is just the encapsulation –  Lucas Kauffman Jul 9 '13 at 6:10
3  
@LucasKauffman -1; SFTP is a part of SSHv2. –  curiousguy Jul 9 '13 at 6: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 "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 9 '13 at 6:38
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 9 '13 at 7:20
show 6 more comments

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.

share|improve this answer
    
"or even GET /users/1/delete." be careful with GET which is supposed to not have side effects. –  curiousguy Jul 9 '13 at 6: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 9 '13 at 6:39
    
@curiousguy I'll clarify that. –  Stephen Touset Jul 9 '13 at 14:54
add comment

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

share|improve this answer
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.