被客户告知 HTTP 的 PUT 请求不安全,甩锅给我们要求整改
source link: https://www.v2ex.com/t/816040
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
上去一看,PUT 请求全部被拦截,也不知道家防火墙商干的好事,默认把 PUT 请求全部给禁了,还给客户培训说 PUT 请求就是不安全
给客户解释了半天,根本不听,就说防火墙这样设置肯定有他的道理,说是我们使用了不安全的请求方法,要我们负责安全整改
全站遵循 RESTful 设计的呀~简直要疯了~也不知道哪个 wbd 做的默认规则
westoy 1 天前 15
TossPig 1 天前
@unco020511 真的要吐了
@westoy 我们的也可以再 post 里面套用一个_model 参数来用 post 包装所有请求方式,外行也就不说,真不知道做防火墙那帮子人怎么想的
@xmumiffy 这波反向有道理,哈哈哈
@westoy 整改肯定是有方案,但是为什么要用别人的错,来增加自己的成本
http 的几个请求方法,就 header 字段有区别,要不是浏览器限制,get 也能承载 body 体,真的是有些防火墙厂商运维还四处宣扬,PUT 不安全,工作群里问他们不安全的点在哪里又说不出来
wu67 1 天前
eason1874 1 天前 3
知其然而不知其所以然,迷信就是这么来的
ThirdFlame 1 天前 2
所以有些 waf/扫描工具 /扫描人员 直接报告说支持 put 就是不安全
passerbytiny 1 天前 via Android
TossPig 1 天前 1
不太认同那种因为甲方就要应承他的想法,什么都照甲方的想法改,最后出问题了还是会甩锅到自己头上。
就像十年前的项目,你不兼容 IE 就说你系统有问题,技术都顶着,技术栈全线更新全切 Chrome 了,现在客户也知道旧版 IE 不能正常显示不完全是系统的
就给了两个方案,要么双倍预算我们重做系统,要么防火墙放行
knives 1 天前
之前也遇到过一次同样的问题,结果没刚过甲方的运维。最后还是妥协了,在前端加了个拦截器,把所有 PUT 和 DELETE 请求换成了 POST ,同时附加一个 X-HTTP-Method-Override=PUT/DELETE ;后端再按 X-HTTP-Method-Override 给换回来……
倒也没废多少事,但是非常不爽。
hronro 1 天前 1
什么叫最原始的 HTTP ?
HTTP 0.9 ? HTTP 1.0 ? HTTP1.1 ?
HTTP 标准里面 PUT 的语义是修改 Entity ,对应到你说的文件的例子里面修改文件,上传文件应该是用 POST 。
所以你说的东西只能说是某个 HTTP 实现的问题,并不能怪到 HTTP 标准本身头上。
SimonOne 22 小时 46 分钟前 2
甘霖娘的,网上的资料翻来覆去就抄这句,也不说个所以然。
lesismal 22 小时 24 分钟前 2
随便就搜到个:blog.csdn.net/CHEndorid/article/details/111277629
而且和楼主公司的情况挺像的,不会就是同一个公司吧?
直接贴过来:
```text
一、背景
最近研发让我开一下服务器的 put 、delete 方法,被我以不安全的 http 方法给拒绝了。
研发表示我很无理,put 怎么就是不安全的了,在他看来,put 和 post 只是语义上的不同。如果 put 是不安全的方法,那么 post 也是不安全的方法了。
网上的说法也是分为两派,一派说这些都是不安全的方法,要关掉;另一派说它们只是语义上的区别,不存在安不安全。
二、一探究竟
经过我和研发各自编写测试用例来论证后,我明白了为什么会有这样的分歧:我是从 nginx 作为 web 服务器的角度来看问题的,研发是从 java 代码上来看问题的。
1 、为什么说 POST 和 PUT 只是语义上的区别?
在研发的代码里,终端(浏览器或客户端)过来的流量,最终通过 java 的注解,携带参数进入到了研发写了一个方法里来了。比如研发对某个自定义方法使用 PUT 的注解,那么终端通过 PUT 方法传递的参数就会进入到这个自定义方法中。有点编程经验的话,就会知道,到了你写的方法里,这些参数就随便你玩了。
对于 PUT 、POST ,研发都可以通过添加不同注解的方式,得到传递的参数,然后进行操作。所以研发会认为他们只是语义上的区别。
2 、为什么说 PUT 、DELETE 是不安全的方法?
对于 nginx ,可以使用 HttpDavModule 编译 nginx (./configure --with-http_dav_module ),开启 PUT 、DELETE 等方法。开启后,恶意攻击者就可以直接将病毒文件等传到 nginx 服务器上,所以 PUT 等方法对 nginx 来说是不安全的。
3 、上面两个问题是否矛盾?
并不矛盾。
假如研发人员打包一个 jar 包,这时客户端直接访问这个 jar 包起的服务,那么 put 传递过来的所有参数,是可以由研发人员编写的代码控制的。只要控制得没有猫病,那么就是安全的。假如开发的是一个 tomcat 容器部署的工程,参数也是一样可以由研发的代码控制的。
同时,用 nginx 也可以反向代理 put 方法(不用 HttpDavModule ),所以只要后端服务对 put 服务做好控制,nginx 不需要做任何更改,也就实现了对 put 方法的支持。
但 nginx 不能单独开启 put 等,因为研发的代码不能对 nginx 做控制。
三、结论
后端服务可开启 put 方法,只需要后端服务对 put 传递的参数做好控制,并实现 put 方法即可。
nginx 不可开启 put 方法,这是一种危险的方法。
```
另外:竟然真的有人认为 REST 挺好,是有多傻。
ryd994 20 小时 25 分钟前 via Android 4
其次,Nginx 的 dav 模块是需要 dav_methods 指令开启的。还可以根据不同路径使用不同的设置。
http://nginx.org/en/docs/http/ngx_http_dav_module.html
自己不会配置 Nginx 还要怪 restful 不行?
lesismal 15 小时 34 分钟前 2
> 用于 Web 服务的 Nginx 为什么要带 dav 模块编译?各大发行版的默认 Nginx-minimal 就是没有 dav 模块的。你为什么编译的时候不可以关掉
人家原文里说:
```2 、为什么说 PUT 、DELETE 是不安全的方法?
对于 nginx ,可以使用 HttpDavModule 编译 nginx (./configure --with-http_dav_module ),开启 PUT 、DELETE 等方法。开启后,恶意攻击者就可以直接将病毒文件等传到 nginx 服务器上,所以 PUT 等方法对 nginx 来说是不安全的。
```
这意思没说默认就有 dav 模块吧?也没说默认就开启吧?人家这意思说的就是默认不开启、如果需要开启单独编译吧?所以你要不要再自习看看 :joy:
> 其次,Nginx 的 dav 模块是需要 dav_methods 指令开启的。还可以根据不同路径使用不同的设置
你有没有想过今天给你开一个特殊的明天给他开一个特殊的,安全部门还得维护各种,开发与运维、安全人员耦合,而且毕竟留了口子,哪天不小心、或者包括人员离职交接、新功能上线导致纰漏留了漏洞等情况?而对于开发而言,统一协议规范、提高这点安全标准并不费多大事,为什么要为了开发自己的便利去与更多部门产生工程上的耦合?代码讲究高内聚低耦合,但代码是服务于整个工程的,工程思维要考虑整体,包括架构、运维、安全相关的部门协作等各种,只考虑自己方便不是一个好的努力方向
而且,我上楼转那个帖是为了说明 PUT 不安全相关的问题,所以,nginx 编译方案并不适合作为安全问题甩锅的理由
> 自己不会配置 Nginx 还要怪 restful 不行?
抛开 nginx 不谈,restful 就好用吗?
1. 真实项目里有多少人在用真正的 restful (只是用了各种 method 就以为是 restful 这种不算)?
2. 有多少人真正理解了 restful ?不怕各位笑话,我就没太懂,因为搞得太绕太复杂,要理解它所谓的精妙设计就要不少心智成本,就像有人讨论说的,它跟 OOP 一样存在过度抽象的问题,需要前期消耗很多顶层设计、预先设计的成本,我只是人云亦云、具体我是不了解了,因为好的东西讲究大道至简少即是多,这种搞一堆套路定义的东西、把本来可以简单的问题复杂化,看半小时还没入门、让人云里雾里的东西,我默认它是垃圾。
3. 虽然我不真的懂 restful ,但是可以简单对比下 restful 和 GET/POST+结构化 body 的方式,最简单的思考,restful 不仅多种 method 要仔细设计,仍然也需要 body 参数的结构化设计,而 GET/POST+结构化 body ,省去了 method 设计这块的心智成本,哪个更简单省力?另外,抛开 web 领域,其他服务器领域,命令号 /路由+结构化 body 到处再用,IM/游戏 /分布式系统内部 RPC 交互,也就 HTTP 这垃圾协议早期设计者内心戏太多搞得这么复杂,号称的文本协议可读性好都是扯淡,即使二进制协议,浏览器或者其他工具转换一道可视化出来也不是啥问题,但对于整个互联网流量、算力会带来巨大的节约,相应的也是巨大的性能提升。早期的用户量小,这点协议复杂带来的成本不高,现在都互联网爆发的时代了、大数据的时代了,HTTP 协议的复杂性带来的能源消耗都是不小的开销,只是历史包袱太重没法随便切换成更高效的协议,我目测相比于更高效的二进制协议,它浪费的能源甚至不比挖矿少。
所以,是大家 “怪” restful 不行还是它真的不行?
eason1874 13 小时 15 分钟前 8
@lesismal #39 网上抄来抄去的那篇文章就是启用 WebDAV 又不配置认证,发现可以匿名上传,然后得出结论:可以匿名上传是因为 WebDAV 依赖的 HTTP PUT 不安全
就是错误归因。类似于把 Redis 暴露到公网又不配置认证,被挂马了,说 Redis 认证方法不安全
PUT 方法和 Nginx + PUT 组合在云厂商的服务里多得是,配置类 API 大量使用 PUT ,对象存储上传文件也用 PUT ,CDN 既用 Nginx 也用 PUT 。自认能“快捷简单地入侵”的快去 SRC 提交漏洞,有这本事拿个几万美金奖励轻轻松松
HTTP Methods 本身就只负责操作,安全认证都不是人家的活。安全没做好,只 allow GET 也能被 SQL 注入
TossPig 13 小时 4 分钟前
-----------
这个看不先去了哈,那 http1.1 设计就太冗余了,按这个说法最安全的最好的浏览器发展方向,应该把包括 GET 在内的所有方法,都自动封装为一个 WANT 发送
各大厂商的开发 API 还搞什么 restful 呀,完全是莫名其妙的增加心智成本
dcsuibian 12 小时 50 分钟前 2
如果实实在在地打印过 http 请求中的内容,看过 http 的格式就知道 method 的最大区别就是第一行的格式。
( http 是基于 tcp 的,只要你把 http 请求收到的 tcp 内容打出来看看就知道了)
什么叫“从 Java 代码的角度考虑问题”?这跟什么语言都根本没关系,是 http 协议的内容。
“在研发的代码里,终端(浏览器或客户端)过来的流量,最终通过 java 的注解,携带参数进入到了研发写了一个方法里来了。”写这篇文章的人,明显就是直接上手 spring boot ,连基本的 http 协议都没了解过。
至于什么 nginx 会遇到问题,那就去配啊。
sutra 12 小时 45 分钟前
play78 12 小时 40 分钟前
最近新闻,国美监控员工上班上网流量行为。
很简单,你们客户网管那边的防火墙,还监控不了 put 和 delete ,只能监控统计 get 和 post 的请求。
所以你们就按要求改就是了。说再多也没用,本来就不是技术问题。
[狗头]
0o0o0o0 12 小时 37 分钟前
所以说如果你使用的是反向代理,是不需要编译 dva 模块的,如果不需要编译 dva 模块,那么也就不会因为 put 而产生漏洞,也不需要去禁止 put 函数。
lesismal 12 小时 36 分钟前 1
> 这篇明显是有问题的,网上转过来也得自己思考下。
> 如果实实在在地打印过 http 请求中的内容,看过 http 的格式就知道 method 的最大区别就是第一行的格式。
>( http 是基于 tcp 的,只要你把 http 请求收到的 tcp 内容打出来看看就知道了)
我还算了解一点 tcp 和 http ,我这有一份手撸的 golang poller tcp 框架,支持了 http 异步解析,其中包括一份完整的 http parser:
github.com/lesismal/nbio/blob/master/nbhttp/parser.go
> 什么叫“从 Java 代码的角度考虑问题”?这跟什么语言都根本没关系,是 http 协议的内容。
> “在研发的代码里,终端(浏览器或客户端)过来的流量,最终通过 java 的注解,携带参数进入到了研发写了一个
> 方法里来了。”写这篇文章的人,明显就是直接上手 spring boot ,连基本的 http 协议都没了解过。
不管是不是 spring boot ,我都没出来你说这篇文章明显有问题是指什么问题。那篇文章作者的意思是从运维、安全部门部署的网关 /代理软件的层面不能允许 PUT/DELETE 这些方法,而从开发的层面不管什么 Method 都能拿到相关参数进行验证。
“这跟什么语言都根本没关系” —— 这句是对的。
> 至于什么 nginx 会遇到问题,那就去配啊。
nginx 的问题,,
我转的帖子的作者的意思是不同部门 /工种在整个工程实践的不同层上的安全考量角度,这跟用什么语言或者 java 用什么框架没关系,甚至 nginx 怎么配置都不适合这么实践——这一点我在上一楼(#43 )回复前面小哥的内容里面也提到过了,层主也可以看下
蹭住也可以多思考下,然后再看看我是不是转帖时候没思考 :joy:
xz410236056 12 小时 24 分钟前
1 、PUT 本来就是幂等不安全啊,从这个角度来说确实是的。
2 、禁用也是能理解的,国内大量低素质程序员,统一成 post 会防止很多弱智错误。
Bromine0x23 12 小时 15 分钟前
xz410236056 12 小时 12 分钟前
leeg810312 11 小时 53 分钟前 1
sprite82 11 小时 47 分钟前
到底啥个验证机制啊,安不安全不是程序的问题吗,怎么还由 method 决定你安全性的?
照这么说 restful 就是个垃圾了
xiaming123 11 小时 34 分钟前
dcsuibian 11 小时 13 分钟前 3
既然你了解 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 就是纯甩锅。
为整体考虑可以,但拒绝背锅
dcsuibian 10 小时 49 分钟前
get 不安全还能理解,因为信息直接显示在 URL 里面,可能会被浏览器书签等功能保存下来被别人看到什么的,至少是有理由的。
而 post 和 put 的内容都是放在请求体里,你倒是告诉我请求头里一个单词变了下,为什么就是不安全的了?
lesismal 10 小时 48 分钟前
那 PUT 是不是多了一点被人上传恶意文件的可能?
转的帖子里有:
“恶意攻击者就可以直接将病毒文件等传到 nginx 服务器上,所以 PUT 等方法对 nginx 来说是不安全的。”
至于黑客怎么玩,我不懂、不瞎吹。
如果说运维、安全人员、以及开发人员都对开放 PUT 的路由做好控制就没事,但就像我上面说的整个工程、团队协作各种耦合成本甚至审批流程,都提高了许多,尤其楼主这种好像还是不同公司之间的。
lesismal 10 小时 45 分钟前
不要只当成 api 接口服务,还有可能同一套 nginx 有文件服务,系统还可能有其他的风险,能减少一个漏洞的点就减少一个,能减少一点工种上的耦合就减少一点耦合(最主要的是 PUT api 接口完全不是不可替代的)
lesismal 10 小时 20 分钟前
本来交互协议主要两点:
一是路由,RPC 里叫方法,有的游戏为了节省流量和性能会用数值类型、叫命令号之类的,各个领域自定义协议的项目叫法都类似
二是参数。
HTTP 协议本身算是互联网早期产品,设计者当年也都是摸着石头过河,但因为整个互联网不是自家项目,一旦协议定下来,要考虑全网兼容性,所以即使是缺点也不好及时匡正。包括不限于本帖里说的 METHOD 安全性,还有比如 keepalive 之前的短连接、请求不带 id 无法向多数 rpc 那样可以乱序响应所以即使支持 keepalive 和 server side pipeline 了仍然有线头阻塞的问题,甚至再往4层说,tcp 也渣,4层本身也存在线头阻塞的问题,所以各位可以看到,为啥 http2.0 还没普及,quic/http3.0 都出来了并且更被认可,而 quic/http3.0 是 udp 的,可以解决更多问题。
zjsxwc 10 小时 15 分钟前
RESTful 是 RESTful
两者不一样。
现代的 web 开发全是基于 REST“表现层状态转换”理念设计的,HTTP 的 URL/URI 就是 REST 的典型代表,而 RESTful api 只是 REST 风格的接口,比如基于 HTTP 的 SOAP 接口由于把请求内容、参数等都隐藏在请求 body 里面,无脑使用同一个个 HTTP URL 地址的就不是 RESTful 接口,而 RESTful 接口简单的说就是 URL 明确的指明了要操作的资源对象,这是区别接口是否 RESTful 的最大特点。
所以如果和 SOAP 那样,即使使用了 PUT 、DELETE 方法的 HTTP 接口也不是 RESTful 接口。
https://en.wikipedia.org/wiki/Representational_state_transfer#Applied_to_web_services
lesismal 10 小时 11 分钟前
> 达克效应:越无知的人越自信。
提出这句的时候也可以先送给自己,思考下自己是否听懂了别人在说什么。。。
> 总是有“高人”恨不得重新发明整个互联网。。。
第一,我没说过要重新发明,不是非要重复造轮子而是减少使用上的坑,少即是多
第二,我上一楼聊了点 http2.0 3.0 的,历史、社区兼容性占了很大因素,否则可能早就被优化了。考虑兼容,所以没法只能慢慢先从标准上推进、逐渐更迭,就像老龄社会一样只能等老旧项目自然死亡。
优化不意味着重新发明,而是软着陆,否则,如果不需要优化,你以为谷歌闲的蛋疼搞 quic 、社区闲的蛋疼接纳 quic 并且成为实际的 3.0 ?
拜托楼上某些位大神夸人或者讽刺之前先多了解下技术本身的点,比如 tcp http 协议的实现、历史时期的局限、有那些缺点、以后的优化方向,而不是只看眼下大家都这么用就跟着一块用,人云亦云不知所云也就算了,至少拿出点你们的观点、论据好吧,有论据 vs 无论据口嗨,我嫌累了
lesismal 9 小时 49 分钟前
一是路由,RPC 里叫方法,有的游戏为了节省流量和性能会用数值类型、叫命令号之类的,各个领域自定义协议的项目叫法都类似
二是参数。
之前楼写完上面的落了几句,补充上:
本来简单化一和二就搞定的事情,HTTP 协议非要搞成 Method + 路由 + 参数 三个层次,而且参数还可能有 header 里的 kv form ,还可能有 trailer 的 header 、body ,body 还可能 content-length 或者 trunked ,考虑到社区、历史、兼容因素,可以理解这样的做法。但是你说实际上这协议好不好,我是真没法说好。
饿殍遍野难民潮的时候,富人家施舍点粥米穷人都觉得香。
自己技术积累不够的阶段,社区、别人随便给个能用的轮子就觉得好用、牛逼。
美好的事物不能普遍占据主流——这才是主流的现实情况,劣币驱逐良币的历史故事和当下正在发生、未来也会不断发生的事情都多了去了,都是什么天时地利人和、顺应时代、场景者得天下罢了。
但美,仍然是美。
FakNoCNName 9 小时 44 分钟前
@lesismal 这个用法也能用,不过看起来就像说: http 、mqtt 、mysql 、redis 这么多种协议让人头疼,结构复杂、数据容易、还带来了设计的复杂度,我们就全部用的 TCP 流,内部定义一些字段区分不同含义。
复杂的工具( RESTRull )是为了解决复杂问题,一代代人总结整理出来的经验,你不能说自己目前这么干够用就认死了只这么干( post+body )。
我们就尽量按照 RESTFull 设计接口,用起来没觉得复杂,查接口、查日志也方便,开发功能、定位问题等等分类也比较合理,如果现在让我们全都用 post ,接口多起来以后简直要吐血。
如果把 post+body 比作 txt 文档,RESTFull 就跟带标签的 PDF 或者带目录的 word 一样,一两页资料看不出差别,几十上百页呢?
另外说的安全问题,这些早就没了,要说不安全也是使用的人没做好处理,跟什么方法没关系。
lesismal 9 小时 15 分钟前 1
> 这个用法也能用,不过看起来就像说: http 、mqtt 、mysql 、redis 这么多种协议让人头疼,结构复杂、数据容易、还带来了设计的复杂度,我们就全部用的 TCP 流,内部定义一些字段区分不同含义。
层主可以多了解一些类型的项目,这世界上不是只有 http/mqtt 之类的这几种协议,有太多自定义协议了,只是因为自定义协议多是自家项目、不会形成广大社区、行业的这种 RFC 级别的协议规范,mysql/redis 其实就应该归类于非广泛社区的协议,同样地,它俩也不需要 RFC
> 复杂的工具( RESTRull )是为了解决复杂问题,一代代人总结整理出来的经验,你不能说自己目前这么干够用就认死了只这么干( post+body )。
> 我们就尽量按照 RESTFull 设计接口,用起来没觉得复杂,查接口、查日志也方便,开发功能、定位问题等等分类也比较合理,如果现在让我们全都用 post ,接口多起来以后简直要吐血。
> 如果把 post+body 比作 txt 文档,RESTFull 就跟带标签的 PDF 或者带目录的 word 一样,一两页资料看不出差别,几十上百页呢?
确实需要复杂的基础设施的地方,我也会用,我并不是反对复杂的东西。
我是反对本来可以简单解决的、却把问题搞复杂了。
比如你说的查日志,并非必须 Method 才能搞定,路由分段一样可以解决,比如 /aaa/bbb/...
我上面一楼也有补充的,协议交互主要就两点,而 路由 /命令 这里,我也没限制只能一个层次比如只能 /aaa 不能 /aaa/bbb ,这至少比 HTTP method/路由 /headerbody 各种参数要少了一元设计成本
另外,你的这种观念形成过程可能是反的:是因为从学习到使用都是按社区或者自家项目这样经历下来的,因为用并且用习惯了并且有人说它好、所以自己也觉得它好,可能没有尝试过自己从底向上设计这些基础设施的思考。就像我上一楼补充里说的,别人给你个轮子,能用,就觉得好,所以你对它的好的判断欠缺真正参照物来对比。
可以尝试下了解多一些类型的项目,或者自己自底向上设计基础设施,然后你就会面对这些设计上的关于美的丑的性能优的劣的各种细节考量,然后才能得出更全面的结论。
> 另外说的安全问题,这些早就没了,要说不安全也是使用的人没做好处理,跟什么方法没关系。
这个我前面楼层说过,安全问题不只是代码逻辑,安全还有很多工程逻辑在里面。很多场景都可能因为人没使用好导致安全问题,但是 PUT/DELETE 的问题相对明显,并且这两个方法并非不可替代、禁用它俩用其他简单方案替代成本也不高
xuanbg 8 小时 21 分钟前
lesismal 7 小时 59 分钟前
> PUT 方法和 Nginx + PUT 组合在云厂商的服务里多得是,配置类 API 大量使用 PUT ,对象存储上传文件也用 PUT ,CDN 既用 Nginx 也用 PUT 。自认能“快捷简单地入侵”的快去 SRC 提交漏洞,有这本事拿个几万美金奖励轻轻松松
专用场景用来对比安全部门的通用场景合适吗? PUT/DELETE 跟 POST 存在上传、删除资源的区别,代理也有不同的 api 、文件服务,能都统一处理吗?而且,我之前楼提到过了,就算按路由配置放行策略,开发、运维、安全部门耦合,这样好吗?并且 POST 替代 PUT 成本很高吗
你举例子的,比如特定厂商的特定的服务或者业务,比如上传配置,接口做好了处理,比如对象存储基本是内部服务代码内网调用的不对外开放的所以也不怕,但是跟通用场景两码事,我好几个楼解释了很多,不只是 nginx 是否可配置、怎么配置,不只是接口代码可不可以处理,还有工程、跨工种协作上的,还有 HTTP 协议本身的
如果都考虑自己眼下这点代码逻辑,那倒是万事大吉。
@TossPig
"那 http1.1 设计就太冗余了" ——事实就是这样子的,不只是 http1.1, tcp 、http2.0 都有缺陷,互联网创世年代摸石头过河,都可以理解,但不好或者不够好就是不好或者不够好。
leeg810312 7 小时 48 分钟前 1
leeg810312 7 小时 46 分钟前 1
cxe2v 7 小时 7 分钟前
就像现在谁要是丢个市政|府的指导意见问题给我,我也是个只看得见自己眼把前东西的瞎子,因为我也没接触过市政|府政策制定到底会影响到哪些方方面面
leeg810312 7 小时 5 分钟前 3
Azure 翻译文档 API
https://docs.microsoft.com/en-us/azure/cognitive-services/translator/document-translation/reference/cancel-translation
阿里云日志索引更新
https://help.aliyun.com/document_detail/74912.html
MongoDB Atlas
https://docs.atlas.mongodb.com/api/
ELasticSearch 删除 API
https://www.elastic.co/guide/en/elasticsearch/reference/current/docs-delete.html#docs-delete-api-request
国际云厂商都是通过众多安全合规标准的,他们有 PUT DELETE 也能通过,凭什么说有 PUT DELETE 就是不安全?在我看来,安全问题并不是 PUT DELETE 本身造成的,但部分安全部门和厂商只会一刀切,这就是懒惰、不思进取、推卸责任。
lesismal 6 小时 45 分钟前
你如果有兴趣辩,可以把我回复的多楼层都看一下,先明确下 带上传 /删除文件的服务和 api 的区别、通用场景包括比如安全部门的需要与你说的云厂 api 的区别,你的云厂 api 自己处理好了那是你云厂自己的事情,所以云厂 api 就代表通用全场景了吗(比如这个帖子说的安全部门的需求)?
其他的,工程逻辑、多工种与部门协作,如果你只站在 curd 这种层次考虑问题,我前面楼层已经包含了的一些基本点你们都不看,那烦请不要跟我继续辩了
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK