使用PUT或DELETE方法可以实现CSRF吗?

4es*_*n0k 49 security csrf

使用PUT或DELETE方法可以实现CSRF吗?或者PUT或DELETE的使用是否会阻止CSRF?

Sri*_*nan 56

好问题!

在一个完美的世界里,我想不出一种执行CSRF攻击的方法.

  • 您无法使用HTML表单发出PUT或DELETE请求.
  • 图像,脚本标签,CSS链接等都向服务器发送GET请求.
  • XmlHttpRequest和浏览器插件(如Flash/Silverlight/Applet)将阻止跨域请求.

因此,通常,不应该对支持PUT/DELETE谓词的资源进行CSRF攻击.

也就是说,世界并不完美.可能有几种方法可以使这种攻击成为可能:

  1. Rails等Web框架支持"伪方法".如果你把一个隐藏字段调用_method,将其值设置为PUT或DELETE,然后提交GET或POST请求,它将覆盖HTTP谓词.这是一种从浏览器表单支持PUT或DELETE的方法.如果您使用这样的框架,则必须使用标准技术保护自己免受CSRF的影响

  2. 您可能会在服务器上意外地为CORS设置松散的响应标头.这将允许任意网站发出PUT和DELETE请求.

  3. 在某些时候,HTML5计划在HTML表单中包含对PUT和DELETE的支持.但后来,他们取消了这种支持.无法保证以后不会添加.有些浏览器可能实际上对这些动词的支持,并能对你的工作.

  4. 某些浏览器插件中可能存在一个错误,可能允许攻击者发出PUT/DELETE请求.

简而言之,我建议保护您的资源,即使它们只支持PUT和DELETE方法.

  • 说到非完美世界,当前版本的Internet Explorer 11允许将方法DELETE的XMLHttpRequests发送到其他来源. (2认同)

Dav*_*ter 11

否.依靠HTTP动词不是防止CSRF攻击的方法.这就是您的网站创建方式.您可以将PUT用作POST和DELETE作为GET - 它并不重要.

要防止CSRF,请执行此处概述的一些步骤:

网站提供各种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标头,从而允许伪造请求.


Tgr*_*Tgr 7

理论上它不应该是可能的,因为没有办法发起跨域PUT或DELETE请求(CORS除外,但需要预检请求,因此需要目标站点的合作).在实践中,我不会依赖于此 - 许多系统已被咬过,例如假设无法进行CSRF文件上载攻击(它不应该,但某些浏览器错误使其成为可能).


Sil*_*Fox 7

是的,CSRF 可能与PUT和DELETE方法,但只用一个非限制的策略启用CORS.

我不同意Sripathi Krishnan的回答:

XmlHttpRequest和浏览器插件(如Flash/Silverlight/Applet)将阻止跨域请求

没有什么能阻止浏览器发出跨域请求.在同样的原产地政策没有阻止的请求被做-它是所有防止通过浏览器读取请求.

如果服务器没有选择加入CORS,这将导致进行预检请求.这是阻止使用PUT或DELETE的机制,因为它不是一个简单的请求(该方法需要是HEAD,GET或POST).假设当然正确锁定CORS策略(或者根本没有,默认情况下是安全的).