被客户告知 HTTP 的 PUT 请求不安全，甩锅给我们要求整改

[TossPig]

真的是要吐，这段时间好几个客户单位反馈业务系统无法使用，一直报错

上去一看，PUT 请求全部被拦截，也不知道家防火墙商干的好事，默认把 PUT 请求全部给禁了，还给客户培训说 PUT 请求就是不安全

给客户解释了半天，根本不听，就说防火墙这样设置肯定有他的道理，说是我们使用了不安全的请求方法，要我们负责安全整改

全站遵循 RESTful 设计的呀~简直要疯了~也不知道哪个 wbd 做的默认规则

[HDF]

其实没什么安全问题，只是存在上面所说的安全风险

[fengpan567]

客户逗比还是得按着他的意思来，不然防火墙的钱就白花了

[xz410236056]

“PUT 请求全部被拦截，也不知道家防火墙商干的好事，默认把 PUT 请求全部给禁了，还给客户培训说 PUT 请求就是不安全”


1 、PUT 本来就是幂等不安全啊，从这个角度来说确实是的。
2 、禁用也是能理解的，国内大量低素质程序员，统一成 post 会防止很多弱智错误。

[Bromine0x23]

@xz410236056 HTTP 协议中的 "safe" 不是信息安全上的 "safe"，POST 也是 unsafe 方法，那都用 GET 好了。

[xz410236056]

@Bromine0x23 #64
“全站遵循 RESTful 设计的呀”
楼主说的全站遵循 RESTful ，我说的是 RESTful 规则，post 是我记错了。

[leeg810312]

@xz410236056 PUT 不安全这个观点毫无依据，是应用垃圾才不安全，却怪到 PUT 方法本身，这观点一点都不正确。如果 PUT 修改数据就不安全，那么 POST 新增数据就安全了吗？我们公司做云平台项目和产品，云厂商的 Rest API 全都有 PUT DELETE ，还需要 OPTIONS 支持跨域，云厂商可都是安全合规的，所以现在还说 PUT DELETE 不安全的都是瞎扯。

[xz410236056]

@leeg810312 #66 https://sofish.github.io/restcookbook/http%20methods/idempotency/ 你说你连幂等性和安全性都不知道，你来对什么线？我说的安全指 “不修改资源的 HTTP 方法。”

[sprite82]

> 由于 PUT 方法自身不带验证机制
到底啥个验证机制啊，安不安全不是程序的问题吗，怎么还由 method 决定你安全性的？
照这么说 restful 就是个垃圾了

[xiaming123]

感觉没啥特殊要求的话还是直接 get post 就行了，别按 restful 接口规范，那个规范明显是有点问题，至少在 wen 开发的时候前后端联调有很多的不方便，比如浏览器 network 查看到是接口名称语义化不强，很难受，深受其害

[theprimone]

通篇读下来，我还是没懂

[我是废物.jpg]

[wangkun025]

@lesismal 这文章说的跟研发有一毛钱关系？

[dcsuibian]

@lesismal
既然你了解 http 就好说了。
1. 有人说 PUT 、DELETE 方法是不安全的，我第一个问题就是“为什么 post 是安全的，而 put 就不安全呢？（毕竟 http 的内容基本上是一样的）”
2. 你给出的文章根本就没有回答这个问题，只是说对于 nginx 来说 put 和 delete 是不安全的，不让用。我第二个问题就是“为什么对于 nginx 来说 put 和 delete 是不安全的呢？（毕竟 http 的内容基本上是一样的）”
3. 你所转载的文章说到“开启后，恶意攻击者就可以直接将病毒文件等传到 nginx 服务器上，所以 PUT 等方法对 nginx 来说是不安全的。”。但这时候我又有问题了：“PUT 能把病毒文件发上去，为什么 POST 就不会呢？（毕竟 http 的内容基本上是一样的）”
所以这篇文章根本就没有回答“为什么 put 是不安全的？”这个问题啊。
而且根据# 47 等楼的回答，“对于 nginx 来说 put 和 delete 是不安全的”这个观点根本就是站不住脚的，至少不是 nginx 的问题而是运维人员的问题啊。
找到问题才能对症下药啊！！！


文章中唯一有价值的就是“不同部门 /工种在整个工程实践的不同层上的安全考量角度”这点。
如果运维那边说用的软件有问题又不能升级，我觉得后端可以配合一下改。
如果客户说防火墙老旧有问题，后端也可以配合一下改。
如果运维自己水平不行配不来，还直接来句“PUT 和 DELETE 不安全”直接让后端改，这 tm 就是纯甩锅。

为整体考虑可以，但拒绝背锅

[CSM]

莫名想到了那个用 GET 方法删除，结果被 Google 的爬虫删了所有文章的帖子，GET 也不安全啊 ~

[lesismal]

@dcsuibian
首先，你知不知道 PUT 和 DELETE 主要是可以用来上传和删除资源的 :joy:

[lesismal]

#74 如果不知道这个，那我能理解为啥好几位说没看懂了。

[dcsuibian]

@lesismal 了解 RESTFUL 的人都知道吧

[dcsuibian]

@lesismal 有什么关系吗？说到底，只要能传递信息，你用 get 、post 、还是 put 都是能做增删改查的。
get 不安全还能理解，因为信息直接显示在 URL 里面，可能会被浏览器书签等功能保存下来被别人看到什么的，至少是有理由的。
而 post 和 put 的内容都是放在请求体里，你倒是告诉我请求头里一个单词变了下，为什么就是不安全的了？

[lesismal]

@dcsuibian
那 PUT 是不是多了一点被人上传恶意文件的可能？
转的帖子里有：
“恶意攻击者就可以直接将病毒文件等传到 nginx 服务器上，所以 PUT 等方法对 nginx 来说是不安全的。”

至于黑客怎么玩，我不懂、不瞎吹。

如果说运维、安全人员、以及开发人员都对开放 PUT 的路由做好控制就没事，但就像我上面说的整个工程、团队协作各种耦合成本甚至审批流程，都提高了许多，尤其楼主这种好像还是不同公司之间的。

[lesismal]

@dcsuibian #77
不要只当成 api 接口服务，还有可能同一套 nginx 有文件服务，系统还可能有其他的风险，能减少一个漏洞的点就减少一个，能减少一点工种上的耦合就减少一点耦合（最主要的是 PUT api 接口完全不是不可替代的）

[rust]

@dcsuibian #77 你不要对牛弹琴了,他根本没有论据支撑"PUT 方法不安全"这个论点.