Is CSRF possible with PUT or DELETE methods?

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.

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.