http中的put、delete等请求为什么不安全？

这两天因为公司运维部门把服务器的options请求干掉了，导致我们web前端不能使用cors跨域请求。他们的理由是不安全只允许get 和post请求。我表示不理解，网上搜了一把也没搜出什么。所以有大神出来解释一下么。。。

热心的小回应 · 2020-12-30 10:51:56

HTTP中那些method的真正区别只有那个单词拼写不一样。其他部分没有任何区别。

各种Method的区别是语义上的。是为了让你的应用程序能够清晰简化的进行通信。对于HTTP本身来讲没有任何区别。当然安全性也没有任何区别。

当然也有可能是一些其他的客观因素。比如公司斥巨资买了一个防火墙，发现只能拦截过滤POST和GET请求。。。。。

热心的小回应 · 2020-12-30 10:51:57

你们运维真逗…

热心的小回应 · 2020-12-30 10:51:58

因为put和delete你看，一个是放一个是删，看起来要写入文件，多不安全啊。
get和post呢，一个是取一个是贴，只需要读取文件，看起来多安全啊～
（逃

热心的小回应 · 2020-12-30 10:51:59

这个是历史问题。

开启了WebDAV 的 IIS 允许匿名访问者直接通过 PUT 往服务器上上传文件，曾经导致了很多严重的漏洞，具体可以搜下 IIS put 。

此外 apache 默认允许 trace，又导致了一批XSS。

这些历史问题给运维造成很不好的印象，所以干脆把除必须的http头外都禁掉了事。

热心的小回应 · 2020-12-30 10:52:00

并不能理解，尤其不能理解把定义为无副作用的Method之一的OPITONS给封了(既然这样为何不封POST)。。。。。可以让他们去看RFC2616关于method definions部分了。。。
最后个人觉得对于method真正产生的影响是人为决定的，真正安全问题是人为产生的和个method没啥关系吧(RFC定义了那些method应该遵循的原则。。至于实现者愿不愿意遵循是另外一回事情了)

热心的小回应 · 2020-12-30 10:52:01

这跟请求方式有毛关系不是看后面的实现嘛

热心的小回应 · 2020-12-30 10:52:02

最近在看《图解HTTP》里面有一句话，“PUT 方法自身不带验证机制,任何人都可以上传文件 , 存在安全性问题,因此一般的 Web 网站不使用该方法” 开始不能理解，以为是翻译错误

查了下日文版的，发现也是这么写的，这本书发行这么久了，而且销量这么高，应该不错在错误没有更正的情况

后面仔细了解了下文意，是 PUT 这个协议本身不存在验证机制，按照我们的开发经验，服务端在获取接口的时候是可以根据接口中的信息进行用户登录判断，返回 401 或则是其他状态，你们运维说的不安全，应该和这本书里说的是一种情况，协议层的底层验证。这个应该不影响我们日常开发，我们公司开发这些协议都会用到的，不知道你们是不是没有 web 服务器端的校验，如果不是的话，这个问题就得你们的运维来回答下了，我也很想知道原因，哈哈哈哈

热心的小回应 · 2020-12-30 10:52:03

应为put方法自身不带验证机制，任何人都可以上传文件，存在安全性问题。

http中的put、delete等请求为什么不安全？

8 个回复