这是一个创建于 487 天前的主题，其中的信息可能已经有所发展或是发生改变。
其它的 HTTP 方法都被评为中级风险，不整改估计过不了安全关，系统没法上线，这事如何破？ 我严格要求团队遵循 restful 规范，写了一堆 PUT/Delete/BATCH
 |
1
leo97 2023-07-25 16:26:53 +08:00 via Android
安全水平不行
|
 |
2
infun 2023-07-25 16:28:29 +08:00  2
安不安全不知道，方便是真的方便
|
 |
3
corcre 2023-07-25 16:28:59 +08:00 4
写邮件, 让他留书面证据, 然后拿去问项目负责人, 他说改你就改
|
 |
4
retanoj 2023-07-25 16:29:33 +08:00 6
这事儿怨不得你们的安全 QA ，要埋怨还得找根源（比如他们遵守的那份规范的制定方）
|
 |
5
trlove 2023-07-25 16:29:34 +08:00
很多安全检测工具是只允许 post/get 更严重的是只允许 post 跟你们的安全人员用的安全检测工具有关
|
 |
6
drvDPqg5nO7kZWhv 2023-07-25 16:29:48 +08:00 20
安全 QA 可以下岗了，他真的不合适做这个。
在他知识里，喝 25°的水是安全，26°的水不安全，但是 25°的敌敌畏喝了也安全。 |
 |
8
CEBBCAT 2023-07-25 16:31:03 +08:00 10
那当然是举报前端使用 OPTIONS 方法有安全漏洞 /doge
|
|
9
CEBBCAT 2023-07-25 16:35:33 +08:00
即如楼主就是项目负责人，“安全 QA”是请的第三方公司，那么目标就明确了，是项目上线，阻碍也明确了，“安全 QA”设置了不合理的规则。
可以分享一下跟对方团队的沟通进度吗？ |
|
10
corcre 2023-07-25 16:39:12 +08:00
@dog82 这下场面就非常尴尬...那我估计你是乙方, 乙方的话估计甲方也不听你说的, 只认第三方的评估报告, 那你也就只能改了(要不你拉上 QA 去甲方那说说其实这一项没啥影响
|
 |
12
shengX 2023-07-25 16:41:44 +08:00
我之前所在的项目也是（运营商），需要拿到安全测试报告才能上线，因为项目中有没有限制 put 、delete 的请求，安全不通过，后来为了上线，直接禁用掉了
|
|
13
drvDPqg5nO7kZWhv 2023-07-25 16:44:10 +08:00 4
行业的耻辱
|
 |
14
datou 2023-07-25 16:45:08 +08:00
不允许 option 吗？
|
 |
15
AuYuHui 2023-07-25 16:45:23 +08:00
全部 POST 吧，还少 一个 GET 接口
|
 |
16
kuaner 2023-07-25 16:46:56 +08:00
这事可太常见了，也不能怪安全公司，很可能是他们遵守的某个 GB 里面定义的
|
 |
18
Leviathann 2023-07-25 16:47:09 +08:00
直接 JSON-RPC 一步到位
|
 |
19
x86 2023-07-25 16:47:52 +08:00 1
叫人事查下安全的背景，不是关系户就是短期培训班出来的
|
 |
20
ttentau1 2023-07-25 16:48:09 +08:00 2
正常，iis 如果没配置好，用 put 请求就可以写东西然后执行。所以直接全禁了最好
|
 |
21
raycool 2023-07-25 16:49:42 +08:00 2
建议全部 post 一把梭
|
 |
22
w8123 2023-07-25 16:51:33 +08:00 12
只有我觉得 restful 规范不行嘛，在协议上用一堆方法，不够麻烦的，get/post 一把梭多好
|
 |
23
gam2046 2023-07-25 16:51:49 +08:00 3
以我对接过一些国企的经验来看，整改就完事。
和对方抬杠毫无意义，甲方需要第三方出具合格的报告，第三方依据的一些国标或者甲方内部的安全审计标准来的，无条件服从就行了。第三方甚至能告诉你哪里不合格已经很 nice 了，有些刁民只说不合格，但是不告诉你原因，全靠猜。 赚钱嘛，不寒掺。任何规范都需要为赚钱让路。 |
 |
25
liuidetmks 2023-07-25 16:54:48 +08:00
月经贴
|
 |
26
k9982874 2023-07-25 16:57:56 +08:00 via Android 1
不能无视的话，前面套层网关，请求全用 post ，路由和参数全放 body 里，在网关重新解析转发到业务 service
|
 |
27
Nazz 2023-07-25 17:00:26 +08:00
反问他为什么 PUT/DELETE 不安全, 和 GET/POST 有什么区别
|
 |
28
justNoBody 2023-07-25 17:02:23 +08:00 1
这个问题我在 v 站都看到好多次了，OP 可以搜一下帖子能找到靠谱的原因。
凭我的记忆，印象中是因为多年前 IIS 导致的这些 QA 公司认为非 POST 和 GET 请求不安全。 但是甲方爸爸并不懂这些，他们也不在乎，反正让你改你就改，你除了改没有别的办法。 把前端所有的 PUT/DELETE/PATCH 都改成 POST （一般来说前端请求方法都是统一的，所以实际上应该只需要改几行代码就可以了），在 header 中增加一个自定义属性，后台转一下，后台代码就不用改了。 如果是用的 spring ，增加一个`OncePerRequestFilter`实例就可以了 |
|
29
drvDPqg5nO7kZWhv 2023-07-25 17:02:59 +08:00
@k9982874
我想到了发财之路，开发一套 js 和网关来卖， 前端集成这个 js ，然后到适配器网关，然后还原成原来的请求。专门解决这种“安全的项目”的痛 |
 |
30
janzwong 2023-07-25 17:03:49 +08:00 7
应该是合规侧有强制要求，因为除 GET 、POST 之外的方法都存在一定安全隐患，例如 OPTIONS 可以查询支持的方法，比方说支持 PUT ，但是 apache 存在有关 PUT 方法上传 webshell 或任意文件的漏洞（像是 CVE-2017-12615 诸如此类的漏洞），所以安全 QA 才会有这样的要求。
|
 |
31
githmb 2023-07-25 17:08:00 +08:00
不允许 HEAD 吗？
|
 |
32
raysonx 2023-07-25 17:10:24 +08:00
http 的各种 verb 只有拼写上的不同。历史上有些应用（比如 IIS 的 webdav ）使用了某些 verb 且实现上存在漏洞，被某些安全规范给一刀切了
|
 |
33
xshell 2023-07-25 17:14:16 +08:00
post 一把锁。
|
 |
34
dog82 OP @xshell 我终于知道为啥有些项目 POST 一把梭哈了，原来还喷他们不动 restful 规范，现在自己吃亏了才知道疼
|
 |
35
zpf124 2023-07-25 17:18:18 +08:00 12
楼主的问题我们也遇到过，但你们的 QA 估计就只会背八股文，知其然不知其所以然，实际上是 WebDAV(对小白)不安全。
restful 是 作者发现人家 WebDAV 搞的这套 http method 很符合他的想法，所以复用(偷)了他们定义的 http method 而已，仅此而已，实际两者没什么关系。 而安测会将这个提示为风险的实际原因是针对小白的规则拦截导致被 AOE ，根本原因是有些小白用 IIS 或者其他一键脚本开启了 WebDAV 服务但没做鉴权，效果就和允许匿名的 FTP 服务一样，导致文件被脚本小子加密或者删除。 我们是某个合作的甲方人家找的安测出的报告里包含 “中风险漏洞: 使用 PUT ，http method”, 不过人家给的报告还包含里处理建议/参考， “打开服务设置，选择 IIS 服务器，关闭 WebDAV 服务”，所以我们一看就明白了 另外我们的要求只是高危漏洞必须处理，其他的可以商量，所以我们就解释说明了一下就 ok 了，如果你们的安测是甲方 的而且道理说不通，要求必须按规定，按他们原有的测试脚本，那你只能投降了。 ------------------------------- 最后如果楼主只能改了，那也不算非常麻烦，spring 有个拦截器可以把 POST( "xxx/api", {"_method":"put"}） 转换识别为 put 请求，这样整体后端代码就不用改了。 前端呢也可以将 http 工具再封装一下， 把其他 method 改成 post + _method 参数的方式。 |
 |
36
flyqie 2023-07-25 17:21:00 +08:00 via Android
post + http code 200
这是最稳的方案，restful 那一套在某些场合非常容易出你这种问题。。 鬼知道他们会用什么奇奇怪怪的玩意。。 |
 |
37
zhangxh1023 2023-07-25 17:22:47 +08:00
如果你是作为乙方，帮甲方做项目，而安全是甲方提出的要求
那么，改就完事儿了。没必要挣扎。 或者说，你忽略掉《安全》这个词儿，就当成满足他们内部的规范。 本质上和 rsa 换成 sm2 ，mysql 换成 达梦 之类的，没区别。 |
 |
38
baiyi 2023-07-25 17:22:49 +08:00
@zpf124 #35 请问 restful 的作者是谁？ http method 是 WebDAV 定义的吗？在哪个 RFC 文档里？
|
 |
39
zoharSoul 2023-07-25 17:23:25 +08:00 1
让你 restful, 掉沟里了吧
|
 |
40
shyangs 2023-07-25 17:27:07 +08:00 1
|
 |
41
mdn 2023-07-25 17:27:10 +08:00
前端拦截非 POST ，在 request headers 里添加 x-method
后端拦截处理 x-method restful 曲线救国 |
|
42
flyqie 2023-07-25 17:27:12 +08:00 via Android
|
|
43
mdn 2023-07-25 17:29:50 +08:00 2
|
 |
44
iosyyy 2023-07-25 17:31:39 +08:00 1
@guilinxiaobing #6 实际上是 25 度的水和 25 度的 h2o
|
 |
45
ma836323493 2023-07-25 17:31:59 +08:00
在我看来 restful 规范 需要很多方的默契。 记得刚毕业的时候，完全遵照 restful ， 前端不配合， 后来就改了，restful 确实不咋地， 我喜欢见明知意 的接口
|
 |
46
blackmirror 2023-07-25 17:34:04 +08:00
这不很好吗，明正言顺的直接全 POST
|
 |
47
LeegoYih 2023-07-25 17:35:05 +08:00 3
我们集团很多项目都是 POST 梭哈的，HTTP Status 除了 200 401 500 其他都不用，公司项目能跑就行。
见过项目用 RESTful ，经过多年迭代已经变成 POST 梭哈的形状了，有些接口命名很痛苦，比如消息撤回，驳回通过，审批通过这种。 |
 |
48
ytmsdy 2023-07-25 17:35:42 +08:00 3
我 TMD 还碰到过说 443 端口有漏洞，然后领导让把 443 端口换成其他端口。
刚刚开始我还怼了一下，架不住隔三岔五的过来说，我捏着鼻子给改了。 |
|
49
shyangs 2023-07-25 17:43:02 +08:00
RESTful, Lisp 這類學院派的東西，我通常用來寫學校作業，教授看了高興.
公司真實業務就上 POST 、Java ，自己好招人，也免得遇到甲方找麻煩 平白無故多幾天加班為他們改. |
 |
50
nullpoint007 2023-07-25 17:43:20 +08:00
@ytmsdy 你这个是真的狠,https 默认端口都能改,哈哈
|
 |
51
cominghome 2023-07-25 17:46:20 +08:00
让他说清楚为什么不安全，他要是说不明白就不给尾款
|
|
52
zpf124 2023-07-25 17:49:07 +08:00 1
@baiyi 这东西不是百度谷歌随便一搜就找得到么
https://www.ruanyifeng.com/blog/2011/09/restful.html https://datatracker.ietf.org/doc/html/rfc4918 restful 作者只是提了一个想法，但没有形成什么明确的规则协议，所以关于 restful 的细节大家各有各的理解，因为最初的作者就是论文里笼统一说，不像 graohQL 。 而 WebDAV ，这玩意出现的不算太晚，但最初人家都是自己客户端和服务通信的，只是基于 http 协议了而已，这样不安客户端的用户也能查看，它和 gRPC 一样，属于特定领域在 http 上实现的私有协议。 WEB 主流世界用不上他们这功能自然支持情况很差，尤其是后端，这是 spring 官方有我提到的那个拦截器的原因，因为在 restful 火起来的同时期的 tomca 7 吧还是 8 都还不支持 PUT 请求。 |
 |
53
akira 2023-07-25 17:49:44 +08:00
你们自己花钱请的评审团队。。大哥，你这钱花的有点亏啊。。
|
 |
55
dode 2023-07-25 17:54:35 +08:00
PUT/Delete 和 POST 安全性上是一样的
|
 |
56
est 2023-07-25 17:57:51 +08:00 17
他说的不安全不是说「语意」不安全，也不是「业务」或者「设计」不安全，也不是资金不安全，也不是「架构」不安全，而是说：
安全设备/日志分析/工具套件/网关盒子无法处理 GET/POST 之外的 http verb ，无法管控或者审计，所以不安全。 |
 |
57
wushenlun 2023-07-25 17:58:25 +08:00 via Android
这是对的，引擎支持的方法存在风险，比如 put 的 webshell 上传 ，除了语义不同基本上没区别
|
 |
58
QlanQ 2023-07-25 17:59:02 +08:00
又学到了
我用 restful 只是为了路由好看 不需要太多命名 例如 /user/5 ，一个路径通过不同的 method 就可以实现多个功能 如果都用 post 的话，就要好几个路径 命名困难症 |
 |
59
lambdaq 2023-07-25 18:01:01 +08:00 2
|
 |
61
workshop 2023-07-25 18:08:07 +08:00 2
@Nazz put 和 delete 都不安全，因为它们可以往服务器上传文件，有某些著名的服务器配置不当，会留下漏洞，攻击者可以通过上传 webshell 来提权。而 put 本身如果服务器可以通过配置允许上传或者 delete ，就容易造成忽略，留下尾巴。
|
|
62
workshop 2023-07-25 18:08:58 +08:00
put 和 delete 都不安全，因为它们可以往服务器上传文件，有某些著名的服务器配置不当，会留下漏洞，攻击者可以通过上传 webshell 来提权。而 put 本身如果服务器可以通过配置允许上传或者 delete ，就容易造成忽略，留下尾巴。但是如果你比较注意，用 put 和 delete 也没问题。
|
 |
63
victimsss 2023-07-25 18:12:41 +08:00
https://github.com/moby/moby/issues/9015
docker 甚至一大堆云原生的项目不是照样 restful |
|
64
victimsss 2023-07-25 18:15:38 +08:00
|
 |
65
mcfog 2023-07-25 18:21:32 +08:00
POST /resource/:id?_method=DELETE
框架或网关 rewrite 一下搞定 |
 |
66
BBCCBB 2023-07-25 18:23:19 +08:00
POST 一把梭
|
 |
67
Features 2023-07-25 18:24:05 +08:00
很多防火墙都是这样的，没啥奇怪的
而且 update 用 put 的话，遇到数据包太大，浏览器类型的宿主环境会报错的，OP 没遇到过吗？ 我也是很不理解为啥非要用 restful |
 |
69
tiedan 2023-07-25 18:41:44 +08:00
“老夫所有接口 post 一把梭”
|
|
71
Nazz 2023-07-25 19:12:22 +08:00
@workshop 服务器的问题 http method 不背锅. 本质都一样, $method / HTTP/1.1\r\n .
|
 |
72
kenvix 2023-07-25 19:23:55 +08:00
有些地方合规要求就是这么奇怪，所以我现在已经不怎么用 RESTful 风格了，没必要为难自己，像 /admin/user/delete 把谓词放到路径结尾也没那么难看。
|
 |
73
TransAM 2023-07-25 19:32:50 +08:00 via Android
这好办，让乙方把这条规则去掉，否则不付款。
|
 |
74
leeyuzhe 2023-07-25 19:43:51 +08:00
误解，ctmd ，之前刚被折腾过，怎么解释都不听
|
 |
75
sampeng 2023-07-25 19:43:55 +08:00 via iPhone
最近也在做合规的事，只要是和合规相关，没得选。喜好屁股等被 x 就好
|
|
76
sampeng 2023-07-25 19:45:14 +08:00 via iPhone 1
上面都在讨论技术问题，lz 是外部安全外包团队出具安全评测报告的。所以这是不是一个技术问题，这是一个销售问题。人家合同里写必须要经过第三方 QA 检测通过你有什么办法
|
 |
77
Bromine0x23 2023-07-25 20:13:26 +08:00
出安全报告这种事怎么感觉闭着眼睛跑扫描器就能赚钱
|
 |
79
wanguorui123 2023-07-25 20:48:29 +08:00
技术不行怪路不平
|
 |
80
tairan2006 2023-07-25 22:25:10 +08:00 3
乐了，还有人在讨论 restful API 的问题……
所以你们没用过 k8s 或者 docker 的 http api 么，那不都是 restful 的……特别是 k8s ，PATCH 用的飞起，真是服了。 |
 |
81
infactory 2023-07-25 22:29:15 +08:00
在业务系统里用 restful 就没见过有善终的
restful 里在中间件小项目里用用得了，真上规模的大项目用存粹是恶心前后端所有人 |
 |
82
wupher 2023-07-25 22:31:08 +08:00
1. 你去问问 ChatGPT 。
|
 |
83
mingl0280 2023-07-25 23:03:21 +08:00 via Android
……讲真，这属于你们的安全 QA 水平太次了
|
 |
84
twl007 2023-07-25 23:35:56 +08:00 via iPhone
完了 AWS S3 的 API 岂不是也不安全
可以建议安全 QA 去给 AWS 发个 ticket 建议只用 GET/POST 并且附上详细原因 |
 |
85
rbq123456 2023-07-25 23:40:06 +08:00
这又不是技术问题，只能改。我之前公司也是按照 restful 规范，但是移动那边说不行，只能改成 get 和 post 。你自己不是甲方，那你就只能改，只能忍。
|
 |
86
lishoujun 2023-07-25 23:47:53 +08:00
RFC 9110 HTTP Semantics
只有魔法才能打败魔法，告诉对方，我们是严格按照国际标准开发的。 我没有找到 gb 标准，如果能找到对应的 gb 标准，说服力更强。 |
 |
87
lesismal 2023-07-25 23:48:34 +08:00 2
|
 |
88
OutOfMemoryError 2023-07-25 23:52:44 +08:00 1
我们甲方爸爸是省级联通，在某个项目的第一轮安全外包测试结果里面有提到过这个，说不安全，会删除/移动/修改资源啥的。。。
但是没办法 我们应用设计的时候就已经用了其他的 METHOD ，只好在 NGINX 层做了一次方法转换, 然后在 spring 里面做了支持 if ($uri ~* "/(GET|POST|PUT|DELETE)/$") { set $param_method $1; } add_header X-HTTP-Method-Override $param_method; 然后对应后端处理一下 https://gist.github.com/Zerek-Cheng/b6cc7a92a3ac64e6be852d1cb089e64b |
|
89
lesismal 2023-07-26 00:10:15 +08:00
@Nazz 之前的帖子喷了不少，浪费时间，这个帖子我不继续回复了
https://www.v2ex.com/t/816040#reply90 https://www.v2ex.com/t/816040?p=2#L151 |
 |
90
Jtyczc 2023-07-26 00:39:21 +08:00 via Android
两年前就是 post 一把梭了，公司项目都是 post ，反正我来打工的，老板想怎么样就怎么样，如果前面是坑照样踩，出了问题也不是我们背锅。
|
 |
91
leeg810312 2023-07-26 01:10:28 +08:00 via Android 1
这个第三方公司和楼上好多都是什么三流公司？我做内部项目还是客户项目，安全检查从没有遇到过不能用 put 和 delete 的情况，还漏洞呢，都是什么年代的上古漏洞？
|
 |
92
yagamil 2023-07-26 01:22:11 +08:00
会不会甲方只会 POST ，GET ，其他的认为多余且危险？
|
 |
94
Slurp 2023-07-26 02:09:16 +08:00 5
@lesismal 😁 TCP 、HTTP 、RESTful 、Actor 、FP 、设计模式 AOE 个遍的还是第一次见，翻了一下喜欢 if err 喜欢 Go ，怕不是经典大道至简…… 看到 Go 社区都是这种 b 人我就放心了。
|
 |
95
james122333 2023-07-26 04:35:01 +08:00 via Android 1
|
|
96
james122333 2023-07-26 04:46:35 +08:00 via Android
我一开始都是只用两个 method
resource 区分 后来知道 restful 也很少用 restful 基本没不同 如果 webserver 没问题 webdav 我不喜欢这东西 新增 method 可以 但 xml 格式不能忍 |
 |
97
xiadong1994 2023-07-26 04:48:52 +08:00
要吃弱智的饭，就不要嫌弱智傻。如果不吃，就把弱智踹开。
|
|
98
james122333 2023-07-26 04:49:39 +08:00 via Android
尤其维护某专案 webdav 我都快累死了
|
|
99
shyangs 2023-07-26 07:08:51 +08:00 2
|
 |
100
documentzhangx66 2023-07-26 07:12:51 +08:00 3
防黑有两个层次：理论防黑与实践防黑。楼主说的这个问题，属于后者。
也就是说，如果大家都遵守规范去做，这玩意其实是不会有安全问题的。但实践中我们发现，很多人为了偷懒，为了高效率，根本不会按规范去做，才导致了这些问题。 类似的问题还有偷懒了没把控制命令与数据分开的 SQL 注入漏洞、脚本注入漏洞； 偷懒没规划权限与加密的早期版本的 Windows 的共享 SAMBA 、FTP 、HTTP 等等。 |
Select Language