使用PUT或DELETE方法可以实现CSRF吗？
使用PUT或DELETE方法可以实现CSRF吗？ 或者使用Put / Delete来防止CSRF？
好问题！
在一个完美的世界里，我想不出一种方法来执行CSRF攻击。
- 您不能使用HTML表单进行PUT或DELETE请求。
- 图像，脚本标签，CSS链接等都发送GET请求到服务器。
- XmlHttpRequest和浏览器插件（如Flash / Silverlight / Applets）将阻止跨域请求。
因此，一般来说，不可能对支持PUT / DELETE动词的资源进行CSRF攻击。
这就是说，世界并不完美。 可能有几种方式可以使这种攻击成为可能：
-
Web框架（如Rails）支持“伪方法”。 如果你把一个名为
_method的隐藏字段设置为PUT或DELETE，然后提交GET或POST请求，它将覆盖HTTP动词。 这是一种从浏览器表单中支持PUT或DELETE的方法。 如果你正在使用这样的框架，你将不得不使用标准技术来保护CSRF -
您可能会意外地在您的服务器上设置了CORS的松散响应标头。 这将允许任意网站做PUT和DELETE请求。
-
在某些时候，HTML5已经计划在HTML表单中包含对PUT和DELETE的支持。 但后来，他们取消了这种支持。 不能保证以后不会添加。 有些浏览器可能实际上支持这些动词，这可能会对你有用。
-
某些浏览器插件中可能只是存在一个漏洞，可能允许攻击者发出PUT / DELETE请求。
总之，我build议保护你的资源，即使他们只支持PUT和DELETE方法。
不。依赖HTTP动词不是防止CSRF攻击的一种方法。 这一切都是如何创build您的网站。 您可以使用PUT作为POST和DELETE作为GET – 这并不重要。
为了防止CSRF，采取一些在这里概述的步骤：
网站提供了各种CSRF对策：
- 在所有表单提交和副作用URL中需要一个秘密的，用户特定的令牌来防止CSRF; 攻击者的网站不能把这个
在其提交的权利令牌1- 要求客户端在相同的HTTP请求中提供authentication数据，用于执行任何带有安全隐含的操作（汇款等）
- 限制会话cookie的生存期检查HTTP Referer头或（和）
- 检查HTTP Origin头[16]
- 确保没有clientaccesspolicy.xml文件授予对Silverlight控件的无意访问[17]
- 确保没有允许意外访问Flash电影的crossdomain.xml文件[18]
- validation请求的标头是否包含X-Requested-With。 Ruby on Rails（v2.0之前）和Django（v1.2.5之前）使用。 这种保护在浏览器插件和redirect的组合下已经被certificate是不安全的[19]，这可以允许攻击者在对任何网站的请求上提供自定义的HTTP报头，从而允许伪造的请求。
从理论上讲，这是不可能的，因为没有办法启动一个跨域的PUT或DELETE请求（CORS除外，但需要预检请求，因此需要目标站点的合作）。 在实践中，我不会依赖于此 – 许多系统已经被例如假设CSRFfile upload攻击是不可能的（应该不是，但某些浏览器错误使它成为可能）而被咬伤。
是的，使用PUT和DELETE方法可以实现CSRF，但是只有在启用CORS的情况下才能使用非限制性策略。
我不同意Sripathi Krishnan的回答 ：
XmlHttpRequest和浏览器插件（如Flash / Silverlight / Applets）将阻止跨域请求
没有什么能阻止浏览器发出跨域请求。 同源 策略并不阻止请求的产生，只是阻止请求被浏览器读取。
如果服务器没有selectCORS ，这将导致预检请求。 这是防止PUT或DELETE被使用的机制，因为它不是一个简单的请求（方法需要是HEAD，GET或POST）。 假设一个正确的lockingCORS策略（当然没有任何默认情况下是安全的）。
根据服务器的configuration，CSRF确实可以使用PUT和DELETE。
考虑CSRF最简单的方法是考虑在浏览器中打开两个选项卡，一个打开您的应用程序，用户通过身份validation，另一个选项卡打开到恶意网站。
如果恶意网站向您的应用程序发出javascript请求，则浏览器将发送标准cookie与请求，从而允许恶意网站使用已经过身份validation的会话“伪造”请求。 该网站可以做任何types的请求，包括GET，PUT，POST，DELETE等。
防范CSFR的标准方式是随着恶意网站无法知道的请求一起发送。 这可以像其中一个cookie的内容一样简单。 虽然来自恶意网站的请求将随同cookies一起发送，但它实际上不能访问Cookie，因为它由不同的域提供服务，并且浏览器安全性阻止它访问另一个域的cookie。
将cookie内容称为“令牌”。 您可以将令牌与请求一起发送，并在服务器上确保“令牌”已正确提供，然后再继续请求。
接下来的问题是，如何将这个值发送给所有不同的请求，DELETE特别困难，因为它没有被devise成具有任何有效负载。 在我看来，最简洁的方法是用令牌指定一个请求头。 像这样的x-security-token = token。 这样，您可以查看传入请求的标头，并拒绝任何缺less标记的标头。
过去，标准的ajax安全限制了通过恶意服务器上的ajax所能做的事情，然而现在这个漏洞取决于你的服务器如何设置encryption控制configuration。 有些人打开他们的服务器，使跨域调用或用户自己创buildRESTful客户端更容易，但这也使恶意网站更容易利用，除非上述CSRF预防方法是到位。
