REST API 安全问题

[gzf6]

楼主是做前端的，现在学着用 koa2 写 api 服务器，公司的后端接口一般都设计为 get 或 post 方法，很少用 put 或 delete 方法，想请教下，这两个方法有什么安全上的问题吗?

[zhengxiaowai]

没，他们不习惯用而已

[FrankFang128]

有毛安全问题，你问问他们具体是什么问题，肯定说不出来，看看 stackoverflow 就知道了
https://security.stackexchange.com/questions/38635/how-is-http-put-and-delete-methods-insecure-if-they-really-are

大概的原因是：

1. 有些傻逼后端没听过 get 和 post 之外的 verb （因为 form 表单只之处 get 和 post ），所以安全判断的时候只判断了 get 和 post，导致其他 verb 可能有安全问题（实际上就是程序员傻逼，跟 verb ）没关系。
2. 由于很多系统是不会去修复以前的漏洞的，所以干脆在 nginx 层面直接禁用 get 和 post，一了百了，呵呵（头痛医脚的典型）

程序员里面食古不化的人其实也挺多的，楼主不要被他们带偏。

[FrankFang128]

*纠正上文：因为 form 表单只支持 get 和 post

[FrankFang128]

还有傻逼面试官认为 『 post 比 get 安全』，然后把 get 也禁用了，所有 API 只允许 POST，呵呵。

[also24]

很多号称 REST API 的，其实都只是搞了个皮像肉不像的东西，假装 REST 了而已

[FrankFang128]

也不想想，如果真不安全为什么 HTTP 协议不禁用这些 verb 呢。
没逻辑的程序员我最鄙视了。

[gzf6]

@FrankFang128 啊，老哥，消消气，消消气，大过年的 😅

[version]

接口还是 post 好点.方便以后加参数也不担心转码的问题..
如果是一些接口一定不会加参数的用 get
put 主要考虑浏览器和兼容问题..因为用新的也没啥特性.还不如老套路 get post

[ala2008]

和安全没有大关系。楼上说的比较好

[springmarker]

有的防火墙会把 put 和 delete 屏蔽掉，restful 有时候也用着累

[richzhu]

@version 请问一下大佬 put delete 方法在什么情况下加了什么参数会需要转码而 post 不需要🤔

[lastpass]

本质上没有什么区别。
不过是一种规范，或者说风格上的东西。
就像你写死循环喜欢用 for(;;)或 while(true)一样

[cedoo22]

没啥区别，CRUD 完全都用 POST，纯粹是为了好管理代码而已。。。不用给业务代码打字员额外负担。

[Cbdy]

反对 @FrankFang128 的说法，请不要误导别人
在 HTTP 访问控制（ CORS ）有差异
HEAD、GET、POST 可能是简单请求，HEAD、PUT 等不是简单请求
参考
https://jianzhao.org/#/concept/http-cors
https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Access_control_CORS

[gzf6]

@lastpass 嗯，我也觉得是风格问题，现在公司的后端是一个动作一个接口，api 复用率太低，我是想着一个 api 对应 get post put patch delete 这五种动作，语义上理解好一点，就是对一个 api 资源执行不同的动作。

[lsongiu]

有一次用了 delete，前端同学不会调。。。

[gzf6]

@lsongiu 嗯，可能还是得兼顾团队吧，减少沟通成本，不过还是希望团队能共同进步。

[mamtou]

新年快乐

[mozutaba]

@Cbdy 同反对，而且我就是只用 post 的。同时觉得前端到处吹的 REST API 太局限了。

[learnshare]

安全性取决于用的人，而不是 HTTP method

[wenzhoou]

@Cbdy Head 是简单请求。put 不是简单请求，这不符合语义吗？

[H3x]

方法本身是没有问题的，但是容易被误用，导致产生安全问题。
基于这个情况很多市面上的 waf 产品都是禁用 put delete 等方法的，这变相的导致用的人更少了。

[gzf6]

@learnshare 同感，因为后端处理数据前还要进行数据验证，HTTP method 只不过发送了请求和参数

[no1xsyzy]

@mozutaba 吹 RESTful 的不是语义网的那群吗？（换句话说是吹 AI 的人）

[FrankFang128]

@Cbdy 这跟安全有啥关系。

[FrankFang128]

楼上大部分的观点不就是：因为有些傻逼软件这么做，所以为了『安全』（实际上是兼容）我们也学傻逼吧。

我的观点：

1. 一定要指只用 get post 是迁就傻逼的做法，不是对的做法
2. 不是为了安全，是为了兼容。要安全请上 HTTPS

[NoKey]

我不知道是不是所有版本，反正部分版本的 tomcat，要支持 put 等，需要修改配置
很多项目早些时候就运行起来了，tomcat 的配置是能不动就不动，免得动了出问题呢。。。
然后就是部分浏览器版本，不支持 put 等
然后呢，put 又不是必须的，可以被替代的
除非是新项目，新运行环境，然后项目负责人又比较新潮
不然，很多不会用的
话说，之前遇到一个甲方，看到 rest ful 风格的请求 uri，说你们这是什么鬼，改了！

[specita]

想我当初刚来这个公司，写 API 文档用的就是 restful 的语义，几十个接口写了几天，然后给前端看，前端直接问我什么是 delete,什么是 put,怎么调用,他折腾半天之后告诉我他们的框架只支持 get 和 post，当时心里一万个草泥马。 但是没办法，初来乍到，硬着头皮把接口方法改回 post 了

[Lonely]

@FrankFang128 #2 你是受刺激了，上来就喷？

[Cbdy]

@FrankFang128 服务端有一个 GET 请求（简单请求）的接口，浏览器可以直接用 XHR 或者 fetch 跨域访问（少一次预检（ OPTIONS ）），如果这个请求是 PUT、PATCH 等，这个请求可以在预检阶段就拦下来，避免跨域请求对服务器的产生未预期的影响。这本身是 HTTP 协议安全的一部分

[mrbeannnnn]

@FrankFang128 因为历史的安全原因，put,delete 操作服务器上的文件导致成功入侵。详情百度 IIS6 put 漏洞

[lolizeppelin]

method 对 http 服务器来说只是一个字段,具体怎么处理看你 http 服务里的代码里怎么写 然后再到业务代码处理

这些你只要完整的看过一遍 http 服务代码就懂了

至于前端什么的不支持 put 和 get 也是没关系的,标准的 http 服务框架代码都支持 method 重定向

[jonahtan]

@specita 哈哈哈，我把接口 docs 拿给前端小伙伴，那小伙儿也是说你没事别瞎整行不大哥。post get 满足不了你了是不？
吓的我赶紧整改。

[lolizeppelin]

@mrbeannnnn

method 只是个规范 不涉及任何安全问题 安全问题存在于实现代码中

iis6 有问题也是 iis6 自己的 http 实现有问题
他代码里的的 put delete 相关代码有问题不带表 put delete 本身有安全问题

[lolizeppelin]

@Cbdy

安全行为是浏览器实现的,有用但是靠不住的

限制只能靠后端自己, so.....

[ranwu]

全栈就没这些问题，想怎么做就怎么做[:smirk:]

[ichou]

其实我一直不太理解为什么为什么大家一直喜欢追着 RESTful 怼，RESTful 只一种是设计风格又不是标准，不同的框架里的实现方式都尚且是有差别的，更别说到了具体的环境具体的人

1. 因为有过不愉快经历就对 REST 过份怨念的朋友，如果您是在认真研究过 REST 并且在生产项目上实施过之后得出的结论，我尊重您；如果不是，请收起你那份『老子不用的，就是垃圾』的莫名优越感
2. 对于那些你觉得『假装 REST 』的项目，没必要苛求，因为他们可能也是因为团队、环境的各种阻力才做出了妥协，但至少，他们是想要遵照这一风格的，没毛病
3. 我喜欢 REST，因为它和 OOP 一起可以让整个项目的结构足够清晰，看一眼路由表就能大概了解整个系统的架构
4. RESTful 是一种风格，到目前为止我不知道有哪一种实现可以称得上最佳实践。记得几年前听金数据创始人陈金洲的一个分享，那个时候我所在的团队已经用了好几年 REST 了，觉得 REST 就是我们用的那样，听完之后才知道，我们用的是个屁，stay hungry stay foolish

[jorneyr]

HTTPS + token(放 header 或者 cookie 里)

[firebroo]

和安全没有关系。

[mmmfj]

请求用的方法和安全无关

[shuizhengqi]

post 本来就比 get 好用，说没区别的是自身经验太少。

[blueorange]

以前公司给别人学校里面做了个系统， 学校网管拿漏扫工具， 扫到 put 和 delete 方法， 直接报高危漏洞。哎， 没办法呀

[scriptB0y]

我见过一个 REST API，url 是：xxx.com/api/rest 只有这一个，然后 POST body 里面写各种参数...

[micean]

有的机房连 404 都直接给你拦了……

[yzkcy]

@FrankFang128 #4 POST 还真比 GET 更安全。

[xuanbg]

全用 POST 还是有好处的，就是比较简单。说真的，REST 接口 url 路径里面带参数的，网关上面鉴权或者过滤器鉴权还得写正则替换，很烦的。

[loading]

鉴权没做好，怪规范，很科学。

[freakxx]

跟安全没关系，
规范问题，
更多的考虑是语义的问题，
针对的都是对资源做处理。

[royzxq]

有的场景下只用 post 和 get 是为了兼容。还有就是 post 比 get 要好用是真的，get 拿到的真的就只是个字符串。另外一个就是 get 和 delete 都只能通过 querystring 来传参数（ header 另算）。

[swcat]

不就是请求行开头那几个字母不一样么。。。。
关安全啥事

[WilliamYang]

method 跟是否安全没有关系

[Hstar]

有一部分是对前端的妥协，设计了 PUT 或者 DELETE 的借口，前端过来和我说，“我们这个库不支持 PUT 方法的呀，换个好不好嘛”

[Sparetire]

@Cbdy "这本身是 HTTP 协议安全的一部分"
----------
这什么时候成了 HTTP 协议安全的一部分了...跨域是浏览器的安全策略而已, 简单请求非简单请求也就和浏览器有关, 脱离浏览器的环境, 这世界上这么多 HTTP 客户端都不管你什么简单不简单的请求...

[gouflv]

什么年代了，还讨论这个

[hilbertz]

用 protobuf rpc 最安全

[Sparetire]

@Cbdy "如果这个请求是 PUT、PATCH 等，这个请求可以在预检阶段就拦下来，避免跨域请求对服务器的产生未预期的影响"
---------
另一方面, 同源策略从来就不是为了避免什么跨域请求对服务器产生未预期的影响, 难道只有 PUT, PATCH 这样的非简单请求才会对服务器产生未预期的影响? 简单的 GET, POST 就不能对服务器产生未预期的影响?
照这样的说法, 如果真有人想对服务器造成未预期影响, 他只要发简单的 GET, POST 请求就好了.
然而是否会产生未预期的影响, 完全取决于服务器对 HTTP Method 的处理是否幂等, 如果不幂等, 简单的 GET 请求也照样会产生影响. 这完全是人的问题, 和协议安全性没有任何关系.
见过脑子不正常的后端拿着表单 GET 也能做插入的, HTTP 完全不背这锅

[mitoop]

@FrankFang128 上次有个测试这么问我，我说什么问题？ 最后不了了之了。😀

[so1n]

前端不支持其他方法，cdn 或者防火墙过不了 get post 外的其他方法

[tonyaiken]

虽然按照最佳实践增删查改应该对应 POST, DELETE, GET, PUT，但是只用 GET POST 也够应付。安全问题的话只要不要在用 GET 的时候要求把 API Key 之类的放在 query parameter 应该就够了。

[limuyan44]

什么年代了，rest 还是正统啊，好用就行。前面竟然竟然还有用不好 rest 就是煞笔的说法，未成年吗。开发么，适合就好，没必要上来就啥不都不管就搞 rest。话说说不清几个请求方法具体有什么区别的多了去了。

[Cbdy]

@Sparetire 同源策略本身是为了弥补协议的安全性，了解不同 Method 在同源策略中的表现差异是有必要的

[pryhub]

我们这边几千万的项目，只用了 post 和 get,还不是 rest,手动狗头。。

[gzf6]

@pryhub 又不是不能用 [手动狗头]

[chanchan]

我是受不了很普通的一个东西被吹得有多牛逼一样

[Sparetire]

@Cbdy 所以到底同源策略是"HTTP 安全的一部分"还是"弥补协议的安全性"的？以及简单请求是否也会对服务器产生"未预期的影响"呢？
不然令人替广大移动端应用感到担心不是，毕竟他们没有同源策略的保护

[lovedebug]

我敢说好多人连 RESTFUL 定义都没看过 😂 就在瞎扯
先明白 restful 出现的背景和要解决的问题再来谈优劣吧

[hunterhug]

全部的 HTTP 方法，最后都变成了 HTTP 文本协议，然后发出去。REST，资源状态链转移，我敢说大公司都没有严格参照，只有哪种很炫，很拽，很拉风的创业公司，为了装 13，所以会天天把 REST 挂在嘴边。


中间件开发都用 RPC 好吗，gRPC 一用，我管你怎么 PO。不过，给前端的接口，还是要和前端协商一下，怎么写都行。

[fatbear]

一年多前的 Tomcat PUT rce 漏洞了解下 http://www.4hou.com/vulnerable/7743.html

[libook]

RTFM。

到底是什么是 REST，请仔细看一下 https://zh.wikipedia.org/wiki/%E8%A1%A8%E7%8E%B0%E5%B1%82%E7%8A%B6%E6%80%81%E8%BD%AC%E6%8D%A2

中间有一句：“ PUT 和 DELETE 方法是幂等方法。GET 方法是安全方法（不会对服务器端有修改，因此当然也是幂等的）。”

所谓 REST 使用的 Method “安全”或“不安全”并不是信息安全上的概念，而是一个请求对现有数据是否有影响。。

HTTP Method 不只有 GET POST PUT DELETE，所有 Method 功能机制基本上差不多，没有什么特别大的区别，只是用途不大一样而已，主要是语义化，便于区分。看官方文档： https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

[owenliang]

没有讨论意义，可以用 REST 框架做纯 REST 风格的 API

[JamesC]

get, post,patch,put,delete 不过是 Http Method 而已。本身并不存在安全问题。与其猜测后端意图，不如直接询问一下。

[lalala121]

我记得我看 restful 那本书的时候，关于安全只是说到 rest 的方法名太直白，对于公司内部交互来说比较方便，但是不适合用于外部接口，容易让人猜到你的用意，其他的就没提了

[ibugeek]

之前有看过一个视频说：类似于 restful 这种命名方式的话，你的整个接口访问地址都非常容易猜出来。

[yc8332]

很少完全遵守 restful 规范的接口。。。还是习惯 post get

[stevenkang]

所有只读操作均用 GET 请求，例如获取 ID 为 1 的用户数据 GET /user/1，
所有写入操作均用 POST 请求，例如修改 ID 为 1 的用户数据 POST /user/1，

GET、POST、PUT、DELETE 简化为 GET ／ POST 读写操作就完事。

[feiyuanqiu]

@hunterhug #67 你说的大公司只包含国内的吧？

微软: https://docs.microsoft.com/en-us/rest/api/
微软 API 设计指南: https://github.com/Microsoft/api-guidelines
Paypal： https://developer.paypal.com/docs/api/overview/#
Paypal API 设计规范： https://github.com/paypal/api-standards/blob/master/api-style-guide.md
github: https://developer.github.com/v3/
google: https://developers.google.com/drive/api/v2/reference/
amazon aws: https://docs.aws.amazon.com/zh_cn/AmazonS3/latest/API/Welcome.html
apple: https://developer.apple.com/documentation/apple_news/read_section_information

上面还有说 「类似于 restful 这种命名方式的话，你的整个接口访问地址都非常容易猜出来」...只要接口命名规范，都容易猜出来，这本来就是它的优点，别人都是担心开发者不好找接口，专门弄了 HATEOAS，把资源相关的接口暴露出来

rest 是个很自然优雅的接口方案，熟悉规范后，接口的可读性也非常好，国内不流行只能说因为普遍的面向对象的设计能力欠缺，识别不出来业务中的核心领域对象；对 http 协议的认识也浅薄

[Cbdy]

@Sparetire 注意到，HTTP 协议书在不断演进的，可以认为 CORS 是对早期 HTTP 协议的一个补丁

[Amit]

rest 是个很不错的方案，可以尽量往上靠，但不可能完全做到，比如用户名、密码，用户名是不能修改的，密码做了 hash 且不能暴露出来。
@ibugeek 接口容易猜出来其实是优点。一套合格的 API 要做到及时别人全部知道路径也能通过权限控制方式保证安全，而不能靠隐藏接口地址获得虚幻的安全感

[hunterhug]

@feiyuanqiu 确实是指国内的。REST 对一些不是资源的，比如登陆，登出接口还是无能为力。但 REST 确实优雅，和面向对象如 Java Bean CURD 很像。规模化的话，接口人员还是要好好按照 REST 来设计接口。

[Sparetire]

@Cbdy "可以认为 CORS 是对早期 HTTP 协议的一个补丁"
-------------
前面我们说的是同源策略, CORS 只是同源策略的一部分, 并不能代表整个同源策略, 而同源策略本来就只是浏览器才有的概念, 同源策略中很多东西和 HTTP 半毛钱关系都没有, 比如 Canvas 的跨域, LocalStorage 的跨域, 也就 CORS 和 HTTP 有那么些关系, 所以我不懂为什么从同源策略又缩小范围到 CORS, 姑且就认为之前是想表达 CORS 而不是同源策略吧
特地又去确认了一遍 HTTP 的 RFC 文档和同源策略, 不然我以为自己以前看了假的文档. 事实上 HTTP 里从来没提过 CORS, 不知道为什么这个"补丁"不写在 HTTP 规范中?
事实上 CORS 只是在 Fetch 的规范中定义了, 包括那些相关的头部, 而不是什么"HTTP 安全的一部分", 而关于 CORS, 原文是这么说的
It is layered on top of HTTP and allows responses to declare they can be shared with other origins.
也就是 HTTP 上层的约定 /协议, 不可否认 CORS 解决了一些安全问题, 但是这只是针对浏览器的, 上层协议专门为浏览器打的补丁也要算作 HTTP 的补丁, 不合适吧? HTTP 作为更通用广泛的协议, 浏览器的特定需求不该由他来考虑吧?
参考
https://fetch.spec.whatwg.org/#http-cors-protocol
https://www.w3.org/Security/wiki/Same_Origin_Policy
https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy
https://tools.ietf.org/html/rfc7231
https://tools.ietf.org/html/rfc2616
如果有误还请指正.

现在扯得偏离楼主问题有点远了, 我来整理下, 没理解错的话
楼主的问题是 PUT, DELETE 等 HTTP Method 是否存在安全问题(范围应该 HTTP 协议)
你给的(有安全问题的)论据是 PUT 等 Method 在 CORS 下存在区别(范围缩小到 CORS, 浏览器范围)
以及"如果这个请求是 PUT、PATCH 等，这个请求可以在预检阶段就拦下来，避免跨域请求对服务器的产生未预期的影响。这本身是 HTTP 协议安全的一部分"
我只想指出这两个论据存在问题并不能推导出"PUT, DELETE 等 HTTP Method 是否存在安全问题", 至于 HTTP 本身安不安全, 明文的还指望多安全, 要加密上 HTTPS, 要防止资源被跨域读取上 CORS, CSP, 而问题本身, PUT, DELETE 并不会比 GET, POST 更不安全(协议上来说, 至于举例 XX 服务器因为 PUT 导致漏洞那是具体实现的事情)
所以我想我们不应该偏离主题太远, 不然给人感觉像外交部发言人答记者问

[Cbdy]

@Sparetire
我并没有 PUT、DELETE 不安全的意思，但它们本身和安全相关，这是我反对 @FrankFang128 （“有毛安全问题，你问问他们具体是什么问题，肯定说不出来”）的我原因。
关于你提到的 CORS、Fetch 规范等，我可能确实混淆了，但他们和 HTTP 是紧密相关的

[HelloAmadeus]

很多开发都是把 HTTP 协议当成传输层协议来用的