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

[TossPig]

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

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

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

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

[Evilk]

https + post + json
走天下

[leeg810312]

@lesismal PUT DELETE 就一个 HTTP 方式，居然还上升到工程架构这么高的级别了，明显就是说服力不够，非把一个实际上不存在的小问题渲染得及其严重。前面说了，现在很多 API 就是有 PUT DELETE ，所以必须开放，没有能不能可以不可以的所谓选择，也从没听说现在的这些软件和服务哪个是因为 PUT DELETE 产生的安全问题，让人黑了。大概只有你这种抱残守缺的才会找莫须有的安全问题作为借口，我做 500 强的几个项目都没有遇到这种莫名其妙的安全策略，看来 500 强的安全部门都没有你厉害。和你共勉就免了，有的是与时俱进的大牛让我向他们学习。

[datafeng]

这种简单认为 put 方法就不安全的垃圾防火墙买来干啥，讲讲是哪个厂家的产品。。
印象中在哪里看到过等保只能过 POST 和 GET ，这都安全行业定制的吗？

[lesismal]

@leeg810312
所以我 #111 楼里说你都没理解我前面楼说的内容，你可能都没怎么仔细看吧
#116 你也不回答一下：再请教一次："能给你开" 和 "本来就可以不用开"，你觉得前者更好吗？
#90 楼也可以看下

你要辩的内容，我在前面好几个楼里都已经提过了，我不想再重复了，如果看不懂或者根本没看，就麻烦你不要再 at 我了。几位提到某些云厂的接口，我也有回复过，场景不一样，你但凡没兴趣看或者在这只说别人家有这么用而不是讨论用和不用到底哪个好就别辩了。
不提论据只说别人怎么搞或者你给别人怎么搞所以就是好的，这种辩论法，跟泼妇撕逼骂街没什么本质区别。事情和事情不一样，别断章取义、望文生义

另外，给 500 强做的项目有那么值得自豪吗你张口闭口的，感觉其他几位提到云厂也没像你这么自豪啊，某 500 强我十几年前呆过，有很多牛逼的地方，不完善的地方更多，有一些老同事还在里，说现在不像以前那么盲目 996 不盲目拉横幅搞敏捷了，而是更注重科学管理、效能提升以及员工身心健康各种了，所以现在应该是更好了。但是任何一家公司都不是十全十美的，每个公司也都有初级中级水平的人员，如果你还年轻，等你冷静的时候可以考虑下跳出多数人只顾眼下 curd 逻辑程序员的思维，让你自己站在更高的层面看待整个项目的技术与管理与跨部门协作各方面问题。甚至等你年纪再大点、处理过的大项目大业务再多些再回头来挖这个帖子的坟来 at 我都可以，但是这次，我建议你还是冷静冷静吧，回复的内容为喷而喷没什么论据，我认输

[karloku]

笑了, 单纯 WebDAV 的黑历史歪楼歪到 RESTful 的优劣也是没想到.

更搞笑的是 RESTful 话题里的人几乎都没表现出对 REST 的了解. 不理解 RESTful 执着于 URI +动词的目的, 只是跟风套了一些惯例就觉得自己站在时代大道上的, 估计是没法把所谓 RESTful API 写得比 GET+POST 的 JSON API 更好用的.

[lesismal]

我不是安全领域专业户，但是各位可以搜下 "HTTP PUT 攻击 渗透" 或者 "HTTP PUT ATTACK" 之类的，老外的、国内的都有很多相关的帖子或者演示

一些漏洞扫描软件自带功能也包括对 web 服务的 PUT 方法进行扫描

#116 楼的问题我也想统一再问一次那些说安全的各位：
"能给你开" 和 "本来就可以不用开"，前者更好吗？

类似 "这只能说明你们运维菜，不足以说明 PUT 方法不安全" 这种观点，同样的问题：
"运维能搞" 和 "本来运维可以不用额外搞这个"，前者更好吗？

参考我前面几楼说过的工程逻辑、跨工种跨部门甚至跨公司的观点

[lesismal]

现在的年轻人都这么喜欢无论据方式的阴阳怪气吗？

很看好你们最新鲜的一代，但也经常感到失望。希望你们 30 、40 岁的时候不会继续这个样子吧。

[leeg810312]

@lesismal 我做 10 几年开发，现在做架构设计也做开发方面的工作，当前客户基本都是 500 强，不以当前的工作举例还能怎么举例？和我以前的工作接触到的客户比，当然是他们的安全政策最繁复安全管理最严格，你看到几个很菜的能说明什么问题？

我在客户内网工作必须使用客户的电脑，操作服务器必须用跳板机，所有开 IP 和端口白名单必须申请并说明理由，除了 web 和邮件等少量服务器其他服务器不能有外网连接，代码发布前做安全检查，服务器定期安全扫描等等，按你说的这样的安全是不是够工程思维了，但检查到需要整改的安全问题从来没有与 HTTP 方式有关，客户网络安全环境可是跑着跨地区几百上千个大大小小系统的网络。

现在的软件和服务生态已经包含了那么多 API 使用 PUT DELETE ，网络环境复杂，但你反正永远强辩别人做得安全就是场景不同，我也看不出你说的所谓场景有什么特殊的地方。再次强调 HTTP 不是只有 CURD 才用，所以很羡慕你能在你的公司有权无理由拒绝需要调用 PUT DELETE 的一切应用。不过现在生态变了是趋势，建议您还是要跟上时代呢

[TossPig]

我去，，，下班回来直接麻了，这破事儿居然吵热了

给各位汇报一下这个事儿的进展
最后的方案，是甲方也不想再花钱，我们写一个承诺书，我写了一句话，其他甩给商务去扩展了
------------------------------------
因为我司产品遵循 restful 设计原则导致的网络安全问题，由我方承担全部相关责任
------------------------------------
下午还有个小故事

最开始电话和网络中心主任沟通的，表示我们能说明是安全的就行，问题不大，
十分钟后又打电话来，说他问了他们专门管安全的专员，说这个就是风险！！！最后怎么变成修承诺说的就不知道商务怎么周旋的了


我前面已经说过了，这事儿其实也不是个什么事儿，

但是，我明明没有错，为什么要为别人的无知买单？要去“委曲求全”的“绕过”？

[chenyu0532]

加钱

[xfriday]

@lesismal 我把你所有回答都看了，GET 就不能改 /删东西了？啥玩意儿，看到底你就是个外行，还喜欢扮 “高层面”。找你这么说，用 POST 替代 PUT ，然后一个傻帽把数据库全清空了，然后你又说 POST 不安全？

[lesismal]

@leeg810312
我好像没说过强制你们也别用吧？我各个楼是在对比 PUT/DELETE 相对于不用它俩的优劣以及不用它俩的成本，关联到工程、协作等相关的层面，都是在讨论更好的方式。而你们的点就是你们再用并且能用，但是这种方案就是最正确的最好的吗？
自己项目正在用和能用，跟对比其他方式是否存在缺点孰优孰劣，是两码事
流行不代表就是主流，即使主流也不等价于最优
这些我前面楼都有讲过，你们跟我辩来辩去有人认真看我说的点了吗？:joy:

所以这些楼层下来，相当于我在说 A 不如 B ，并且我解释为什么 A 不如 B ；然后你们就说你们在用 A ，你们给大厂的方案也是在用 A ，云厂也在用 A ，驴唇不对马嘴地怼我呢，多数都没怼到我聊的点上，也不提一些论据，比如说为什么 A 就是比 B 好并且好在哪些地方，或者说 A 相对于 B 没有带来更多缺点或者额外的成本（比如安全策略的设置、更新、维护，比如楼主 @TossPig 刚才回复的需要走流程写保证书，本来如果你们不用 PUT/DELETE ，就不需要这些额外的成本，当然，楼主项目历史积累的方案、不改我也理解、支持，只是如果有新项目的时候，建议改成不依赖 PUT/DELETE 的，只是建议，各位自己决定就好）

然后，既然兄弟你都也十多年经验了，跟我杠的时候就不能认真看看我在说什么吗。。。非要像个 95 后一样盲怼我，你们各位怼我的大侠扪心自问一下这样够讲武德吗 :joy:
别说什么我跟上时代潮流，除了你们的团队，还有很多团队都在用 GET/POST + 结构化 body ，甚至像我一样连 GET 都不用的，不要以为自己的圈子就是最大的最流行的圈子就是最潮流的，我上面和其他楼都说过了，流行和主流和最优都不是等价的，否则就不会有革新了。
另外，牛逼的人把复杂的事情简单化，一般的人把简单的问题复杂化，less is more ，上点年纪的多做过一些各种项目的应该要懂的。

PS: 很多交流如果允许带上图，气氛可以不那么激烈，真希望 v 站能畅快的发点 emoj ，:joy: 是我觉得比较能不互相刺激的表情，但是发不出来，各位脑补好了

[lesismal]

@xfriday
> 我把你所有回答都看了，GET 就不能改 /删东西了

我什么时候说过这话了？我说 PUT 能删文件 == 我说 GET 不能删文件？你逻辑及格了吗小兄弟？

另外，GET 能删跟 PUT 的删法一样吗？你每层楼都看了没看懂我说 PUT 文件服务跟 api 的区别？自己不会搜一下？哪里来这么多自信上来就喷，真看了吗？真看懂了吗？

[lesismal]

好多断章取义，望文生义上来就怼的，服了你们了

[lesismal]

> 找你这么说，用 POST 替代 PUT ，然后一个傻帽把数据库全清空了，然后你又说 POST 不安全
文件服务的 PUT ，跟你的 api POST 接口相比，参数校验方式一样吗？ webshell 那些，黑客漏洞扫描工具那些，了解吗？

> 看到底你就是个外行，还喜欢扮 “高层面”。
我扮没扮高层面我自己清楚，但咱俩谁外行你未必清楚

[TossPig]

@lesismal 额，，，不会的，新项目我依然会坚持做这样的设计

考虑的点是基于这样几个考虑

1. 产品设计应该尽量统一，采用流行的模式，方便交付，以及和其他厂商同行对接，流行的规范，大多数人更容易接受，读到你是 delete 请求，自然知道这里是要删除一个什么东西，读到 post 的时候，知道这里是新增了一个什么东西，不是 and,create,built 一堆动词的滥用

2. 哪怕我改成全 POST 封装，实际还是会在 POST 的不管是 body 或者 url 中描述这个操作是 query ，还是 edit 或者 delete ，和写 header 里面的 method 头没区别，只是小聪明的重复造轮子了

3.不是每个客户都这么恼火，也有甲方，默认给关了，但是你提出需求，就直接放行了，不是每个客户都这么固执

4.这次坚持了，下一次同一个甲方再遇到这个问题，哪怕是其他同行就不存在沟通成本了

嗯，暂时想到这么多，突然想起两句话，其他地方不一定对，在这里我觉得可以参考“用户是需要被教育的”，“用户不会提前告知你什么是更好的”

[lesismal]

@TossPig
> 流行的规范，大多数人更容易接受，读到你是 delete 请求，自然知道这里是要删除一个什么东西，读到 post 的时候，知道这里是新增了一个什么东西，不是 and,create,built 一堆动词的滥用

抛开 RESTFul 不谈，我前面提到的三元 /三个维度的问题，其实 post delete 的方法在路由上就搞定了比如 /aaa/bbb/delete ，但是路由上做可以省去 Method 的不统一和比如这次聊到的 PUT 的问题

> “用户是需要被教育的”

这个不太同一，如果我们做得更简约，比如 POST 替代 PUT ，则连教育用户都可以省掉了

——————————————————————————————————————

但公司产品统一，这个没毛病，适合你们自己当前实际情况的就是好的。good luck~ :smile:

[xfriday]

@lesismal
> 文件服务的 PUT ，跟你的 api POST 接口相比，参数校验方式一样吗？ webshell 那些，黑客漏洞扫描工具那些，了解吗？
文件服务难道不是读取请求，执行操作？和 api 有区别吗？难道不是人写的？难道你手里有 bug 文件服务才叫文件服务，别人写的没问题的文件服务就成 api 了？

[lesismal]

@xfriday 兄弟，出门左转百度，右转谷歌，请自己查一下，我就喜欢你们年轻人这种活泼劲儿 :joy:

[xfriday]

@lesismal 自己阴阳怪气还装老