REST API 安全问题

[gzf6]

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

[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 导致漏洞那是具体实现的事情)
所以我想我们不应该偏离主题太远, 不然给人感觉像外交部发言人答记者问