使用PUT或DELETE方法可以实现CSRF吗？或者PUT或DELETE的使用是否阻止了CSRF？
答案 0 :(得分：55)
很棒的问题！
在一个完美的世界里，我无法想到一种执行CSRF攻击的方法。
因此，一般情况下，不应该对支持PUT / DELETE动词的资源进行CSRF攻击。
那就是说，世界并不完美。可能有几种方法可以使这种攻击成为可能：
Rails等Web框架支持“伪方法”。如果您放置一个名为_method的隐藏字段，将其值设置为PUT或DELETE，然后提交GET或POST请求，它将覆盖HTTP谓词。这是一种从浏览器表单支持PUT或DELETE的方法。如果您使用这样的框架，则必须使用标准技术保护自己免受CSRF的侵害
您可能会在服务器上意外地为CORS设置松散的响应标头。这将允许任意网站发出PUT和DELETE请求。
在某些时候，HTML5计划在HTML表单中包含对PUT和DELETE的支持。但后来，他们取消了这种支持。无法保证以后不会添加。某些浏览器可能实际上支持这些动词，这可能会对您不利。
某些浏览器插件中可能存在一个错误，可能允许攻击者发出PUT / DELETE请求。
简而言之，我建议保护您的资源，即使它们只支持PUT和DELETE方法。
答案 1 :(得分：11)
没有。依赖HTTP动词不是防止CSRF攻击的方法。这就是您的网站创建方式。你可以使用PUT作为POST和DELETE作为GET - 它并不重要。
为了防止CSRF，请采取一些概述here：
的步骤网站提供各种CSRF对策：
- 在所有表单提交和副作用URL中要求使用特定于用户的秘密令牌，以防止CSRF;攻击者的网站无法放入 提交中的权利令牌1
- 要求客户端在用于执行任何安全操作的同一HTTP请求中提供身份验证数据 影响（汇款等）
- 限制会话cookie的生命周期检查HTTP Referer标头或（和）
- 检查HTTP Origin标题[16]
- 确保没有clientaccesspolicy.xml文件授予对Silverlight控件的无意访问权[17]
- 确保没有crossdomain.xml文件授予对Flash电影的无意访问权限[18]
- 验证请求的标头是否包含X-Requested-With。由Ruby on Rails（在v2.0之前）和Django（在v1.2.5之前）使用。 这种保护已被证明是不安全的[19] 浏览器插件和重定向，可以允许攻击者 因此，在对任何网站的请求上提供自定义HTTP标头 允许伪造的请求。
答案 2 :(得分：7)
理论上它不应该是可能的，因为没有办法发起跨域PUT或DELETE请求（CORS除外，但需要预检请求，因此需要目标站点的合作）。在实践中，我不会依赖于此 - 许多系统都被例如假设无法进行CSRF文件上传攻击（不应该，但某些浏览器错误使其成为可能）。
答案 3 :(得分：5)
是的，使用PUT和DELETE方法可以实现CSRF ，但只能使用启用了不受限制的策略的CORS。
我不同意Sripathi Krishnan's answer：
XmlHttpRequest和浏览器插件，如Flash / Silverlight / Applets 将阻止跨域请求
没有什么能阻止浏览器发出跨域请求。 Same来源Policy确实not阻止了a request - 它所做的就是阻止浏览器读取请求。
如果服务器未选择CORS，则会导致预检请求。这是阻止使用PUT或DELETE的机制，因为它不是一个简单的请求（该方法需要是HEAD，GET或POST）。假设当然正确锁定CORS策略（或者根本没有，默认情况下是安全的）。
答案 4 :(得分：1)
根据服务器的配置，使用PUT和DELETE确实可以实现CSRF。
考虑CSRF的最简单方法是考虑在浏览器中打开两个选项卡，一个用户通过身份验证打开，另一个选项卡打开恶意网站。
如果恶意网站向您的应用程序发出javascript请求，浏览器将发送带有请求的标准cookie，从而允许恶意网站伪造＆＃39;使用已经过身份验证的会话的请求。该网站可以执行任何类型的请求，包括GET，PUT，POST，DELETE等。
防御CSFR的标准方法是发送与恶意网站无法知道的请求一起发送的内容。这可以像其中一个cookie的内容一样简单。虽然来自恶意网站的请求将随之发送cookie，但它实际上无法访问cookie，因为它由不同的域提供服务，浏览器安全性使其无法访问其他域的cookie。
将Cookie内容称为“令牌”＃39;您可以将令牌与请求一起发送，并在服务器上确保“令牌”＃39;在继续请求之前已正确提供。
接下来的问题是如何使用所有不同的请求发送该值，DELETE特别困难，因为它没有设计为具有任何类型的有效负载。在我看来，最干净的方法是使用令牌指定请求标头。像这样的x-security-token = token。这样，您可以查看传入请求的标头，并拒绝任何遗漏该标记的文件。
过去，标准的ajax安全性限制了可以通过恶意服务器上的ajax进行的操作，但是，现在，这个漏洞取决于您在加入控制配置方面设置服务器的方式。有些人打开他们的服务器以便更容易进行跨域调用或者让用户创建他们自己的RESTful客户端等，但这也使得恶意站点更容易利用，除非上面提到的CSRF预防方法是到位。