没搞懂 HTTP 请求的安全验证，求指导！

[Eyon]

比如请求 https://abc.com/api ，服务器那边可能需要一个验证，比如要求 headers.Authorization === "abcdefg",

那么，也就是说我在请求是，必须在 headers 中添加 Authorization = 'abcdefg'就可以成功请求，这个逻辑没错吧？

问题是：

比如自己做个网站，浏览器打开首页，就需要从服务器提供的 API 中获取一些数据以供后续服务，API 那边定义是要求 headers.Authorization === 'abcdefg'，所以前端写 axios 请求的时候，就加上了 authorization="abcdefg"这个请求，正常工作没有问题。可是，由于在浏览器中的请求标头中可以看到 Authorization:abcdefg 这个明文信息，任何人都可以看到，那不就是任何人都可以通过其他任何方式(比如 postman)来请求这个数据了吗？

当然，你可能会说加密。即便吧 abcdefg 加密成任何形式的密钥，但始终能在请求标头中看到加密后的密钥，用这个密钥发送请求依然可以成功，意义何在呢？

当然，这个问题一定是我自己哪里逻辑没搞清楚。求解答！

[AV1]

一句话：
Authorization 是用来识别你是谁的，不是用来拦截你是怎么进来的，不在乎你用的是浏览器、postman 、curl 。

[aliveyang]

你的 Authorization 怎么就任何人都可以看到呢？在你身后看？

[psydonki]

@byte10 估计你没看懂我的回答...

图片在这个帖子加不上了，可以查看我回复历史，最近的那个图片；


对于普通用户而言，获得自己的短期 access_token 没有问题；当然也可以 copy 出来通过 postman 请求后端的资源；
比如像这样的 header ，Authorization: Bearer {{jwt}}


OP 这样实现的问题在于同时暴露了后端服务的地址和长期 /固定 token ；
最明显的隐患在于，假设用户 A 获取自己信息的 url:
https://api.abc.com/users/12345
headers:
Authorization: Basic {{base64 encoded username:password}}

假设 12345 是用户 id, 我完全可以猜测 id 就是一个递增序列，通过 postman 去请求其他人的信息；
https://api.abc.com/users/12346
headers:
Authorization: Basic {{base64 encoded username:password}}

@Eyon 不确定解释清楚了没有，如果你们团队的架构是微服务的话，你可以 Google 一下 azure api gateway.

[byte10]

@psydonki 你用自己的 token ，去请求别的用户数据，这个是横向越权。。这个是漏洞、业务设计的漏洞。

[rb6221]

大哥，Authorization 就跟钥匙一样，你不把钥匙给别人他就没法用 postman 拿到跟你一样的数据
每个人的钥匙不同，所以每个人获取的数据也不一定相同，比如已登录和未登录，登录 A 和登录 B 等等。
“为什么 V2EX 可以随便看”因为很多内容站长没有做区分。当然也有一些内容站长做了区分，比如你能看到我的消息提醒吗？你要拿到我的 Authorization 才能看到我的消息提醒，但是你怎么拿到呢？我会给你吗？
“某些请求没有这个 Authorization 是不是就代表没有这个功能”当然不是，也有其他的方式，只不过 Authorization 是一种比较流行的方式。
另外，Authorization 是可以设置有效期的，后台发现有问题可以随时令他失效，这样就算你拿到了我的 Authorization ，一旦被我发现，我会换一个用，你手里这个也就废了

[wdssmq]

《爱宠大机密》里，那只兔子用萝卜啃了把钥匙打开了笼子，每次涉及相关讨论时我都会想到这个；

动画肯定是不现实的：

1 、萝卜的硬度不够； 2 、要和真钥匙形状一样；

现实中解决了这两个问题可以说它就是把真钥匙；

[ji39]

浏览器打开首页就要加额外的请求头，难以理解

[blackeeper]

@byte10 你抓一下包就知道了，TLS 层 hello 包握手的时候可以看到域名，这也是 GWF 拦截域名最主要的点

[Kinnice]

@Eyon 是的，就是非常非常的轻松就可以获取到。

[Kinnice]

1. http headers 内的鉴权，无论是 Authorization 还是 Cookie ，都是可以被用户轻易拿到，并且在 postman 等工具内复现
2. https 保证了中间人（即运营商等）不会获取到你的这些参数
3. 你想让用户只能在浏览器内获取结果，其他工具内不可以，这是不存在的，但是可以通过
3.1 加密返回内容（对返回的 json 进行加密），然后使用 js 进行解密后展示，提高对抗难度。
3.2 动态修改你的鉴权参数例如携带请求时间，如果过了指定范围即不返回。
3.3 .....

[qwqaq]

参考《 HTTP 权威指南》第 13 章 摘要认证：

基本认证便捷灵活，但极不安全。用户名和密码都是以明文形式传送的，也没有采取任何措施防止对报文的篡改。安全使用基本认证的唯一方式就是将其与 SSL 配合使用。

摘要认证与基本认证兼容，但却更为安全。

摘要认证是另一种 HTTP 认证协议，它试图修复基本认证协议的严重缺陷。具体来说，摘要认证进行了如下改进：

- 永远不会以明文方式在网络上发送密码。
- 可以防止而已用户捕获并重放认证的握手过程。
- 可以有选择地防止对报文内容的篡改。
- 防范其他几种常见的攻击方式。

[qwqaq]

@qwqaq *可以防止恶意用户捕获并重放认证的握手过程。

[coolzjy]

OP 的问题应该是我给你钥匙只想让你开锁进门，但是不妨碍别人拿到了这把钥匙也能开锁。

基于其他人无法很容易的拿到钥匙这一假设，我们一般认为通过这把钥匙进门的人就是你。但在进行一些风险等级比较高的操作时（比如删除账户，或涉及资金等），通常需要其他认证因素辅助来确定你就是你（比如支付宝的登陆密码 /支付密码）。

至于 OP 后面补充的图书馆的例子，那就属于防止接口恶意使用的问题了，这个跟钥匙 /锁就没什么关系了。

[timpaik]

如果楼主想要保护的其实是自己应用在 api 平台是私钥的话，请搞一个后端作鉴权和限流。楼主很明显问了一个 X-Y 问题。。。

[byte10]

@coolzjy 是的，很简单的逻辑。
@blackeeper soga, 谢谢指正

[aecra1]

信任是有边界的

[chnwillliu]

@Eyon

“用户既然看得到这个 Authorization: Basic xxxxxxxx 这一串，可以直接在 Postman 中请求得到 json 格式的帖子列表，而用不着抓包，这个不是很尴尬吗？”

一点也不尴尬啊。浏览器又叫 user agent, 本来 user agent 就可以有很多种形式，postman 是，你代码里的 http client 也是，甚至命令行的 curl ，他们都是 user agent 。http 又不是设计来只给浏览器用的。

[chnwillliu]

Http 协议只是提供了一种建议的鉴权方式，它方便你的服务端去鉴别 user agent 发起的这次请求是否符合某些身份要求。在 Http 协议的概念里是没有浏览器这种东西的，只有 user agent, 或者说 http client 端。

[xiangyuecn]

简单点讲，就是：滥用

[chnwillliu]

@Eyon

"没有设计用户系统，所以我就不知道这个东西的意义在哪里。"

这就是问题所在啊。不同系统对鉴权的要求不一样。

你开了家图书馆，读者进来只要到服务台领一张通行证跑到入口处，保安一看通行证，上写天王盖地虎，就让你进了。这就是你在用的认证。下次你知道口令了，自己弄了张一样的纸写上天王盖地虎，保安照样让你进。

你觉得这样不对是吗，那是因为你的图书馆不应该用这种最简单的方式呀。

HTTP authorisation 并没有限制你只能用天王盖地虎这种对口号的方式鉴权。你可以有用户系统，鉴定用户名密码，每次报用户名密码太烦了，那可以鉴定一次然后发临时通行证。没有用户系统还要对任意用户提供服务，那要哪门子 authorisation 。