Is CSRF possible with PUT or DELETE methods?

Is CSRF possible with PUT or DELETE methods? Or does the use of PUT or DELETE prevent CSRF?

Great question!

In a perfect world, I can't think of a way to perform a CSRF attack.

• You cannot make PUT or DELETE requests using HTML forms.
• Images, Script tags, CSS Links etc all send GET requests to the server.
• XmlHttpRequest and browser plugins such as Flash/Silverlight/Applets will block cross-domain requests.

So, in general, it shouldn't be possible to make a CSRF attack to a resource that supports PUT/DELETE verbs.

That said, the world isn't perfect. There may be several ways in which such an attack can be made possible :

1. Web Frameworks such as Rails have support for "pseudo method". If you put a hidden field called _method, set its value to PUT or DELETE, and then submit a GET or POST request, it will override the HTTP Verb. This is a way to support PUT or DELETE from browser forms. If you are using such a framework, you will have to protect yourself from CSRF using standard techniques

2. You may accidentally setup a lax response headers for CORS on your server. This would allow arbitrary websites to make PUT and DELETE requests.

3. At some point, HTML5 had planned to include support for PUT and DELETE in HTML Forms. But later, they removed that support. There is no guarantee that it won't be added later. Some browsers may actually have support for these verbs, and that can work against you.

4. There may just be a bug in some browser plugin that could allow the attacker to make PUT/DELETE requests.

In short, I would recommend protecting your resources even if they only support PUT and DELETE methods.

Yes, CSRF is possible with the PUT and DELETE methods, but only with CORS enabled with an unrestrictive policy.

I disagree with Sripathi Krishnan's answer:

> XmlHttpRequest and browser plugins such as Flash/Silverlight/Applets > will block cross-domain requests

Nothing stops the browser from making a cross-domain request. The Same Origin Policy does not prevent a request from being made - all it does is prevent the request from being read by the browser.

If the server is not opting into CORS, this will cause a preflight request to be made. This is the mechanism that will prevent a PUT or DELETE from being used, because it is not a simple request (the method needs to be HEAD, GET or POST). Assuming a properly locked down CORS policy of course (or none at all which is secure by default).

No. Relying on an HTTP verb is not a way to prevent a CSRF attack. It's all in how your site is created. You can use PUTs as POSTs and DELETEs as GETs - it doesn't really matter.

To prevent CSRF, take some of the steps outlined here:

> Web sites have various CSRF countermeasures available: > > - Requiring a secret, user-specific token in all form submissions and side-effect URLs prevents CSRF; the attacker's site cannot put the
> right token in its submissions1 > - Requiring the client to provide authentication data in the same HTTP Request used to perform any operation with security > implications (money transfer, etc.) > - Limiting the lifetime of session cookies Checking the HTTP Referer header or(and) > - Checking the HTTP Origin header[16] > - Ensuring that there is no clientaccesspolicy.xml file granting unintended access to Silverlight controls[17] > - Ensuring that there is no crossdomain.xml file granting unintended access to Flash movies[18] > - Verifying that the request's header contains a X-Requested-With. Used by Ruby on Rails (before v2.0) and Django (before v1.2.5). > This protection has been proven unsecure[19] under a combination of > browser plugins and redirects which can allow an attacker to > provide custom HTTP headers on a request to any website, hence > allow a forged request.

In theory it should not be possible as there is no way to initiate a cross-domain PUT or DELETE request (except for CORS, but that needs a preflight request and thus the target site's cooperation). In practice I would not rely on that - many systems have been bitten by e.g. assuming that a CSRF file upload attack was not possible (it should not be, but certain browser bugs made it possible).

CSRF is indeed possible with PUT and DELETE depending on the configuration of your server.

The easiest way to think about CSRF is to think of having two tabs open in your browser, one open to your application with your user authenticated, and the other tab open to a malicious website.

If the malicious website makes a javascript request to your application, the browser will send the standard cookies with the request, thus allowing the malicious website to 'forge' the request using the already authenticated session. That website can do any type of request that it wants to, including GET, PUT, POST, DELETE, etc.

The standard way to defend against CSFR is to send something along with the request that the malicious website cannot know. This can be as simple as the contents of one of the cookies. While the request from the malicious site will have the cookies sent with it, it cannot actually access the cookies because it is being served by a different domain and browser security prevents it from accessing the cookies for another domain.

Call the cookie content a 'token'. You can send the token along with requests, and on the server, make sure the 'token' has been correctly provided before proceeding with the request.

The next question is how do you send that value with all the different requests, with DELETE specifically difficult since it is not designed to have any kind of payload. In my opinion, the cleanest way is to specify a request header with the token. Something like this x-security-token = token. That way, you can look at the headers of incoming requests, and reject any that are missing the token.

In the past, standard ajax security restricted what could be done via ajax on the malicious server, however, now-a-days, the vulnerability depends on how you have your server set up with regards to accees-control configurations. Some people open up their server to make it easier to make cross domain calls or for users to make their own RESTful clients or the like, but that also makes it easier for a malicious site to take advantage unless CSRF prevention methods like the ones above are put in place.