怎么防止用户自己调用网站 API 发送 POST 请求篡改数据

[b00tyhunt3r]

譬如我有一个 API 节点， 这个 API 接收包含 1 个参数 "address" 的 POST 请求

正常来说这个 address 是客户端在发送 POST 请求的时候程序自动获取的， 用户无法自己更改 但是如果用户自己用开发者工具之类的 call 这个 API， 在请求中传入自己有效的 Token 绕过鉴权， 和一个篡改的 address 参数, 那岂不是可以随意滥用这个 API 私自修改 address 了吗？

刚刚接触 web 开发不是很懂，请问该如何防止这个情况的发生？

[iPhone9]

为什么你叫这个是篡改数据？

[timpaik]

api 设计原则之一：客户端永远不可信

[ganbuliao]

这种情况就 带一个 addressID 呗 后端通过 addressID 查出用户真实的 address 不就行了

[js8510]

我遇到过类似的。最后使用 presigned url 稍微增加了 手动 call api 的难度。

1. client request for address updates -> server
2. server return a presigned url for posing address chagnes and the url timeout in 200ms(一般是你 request response round trip 正常的时间范围)
3. client update address with presigned url.

因为 2. 返回的 presigned url 有 200ms timeout 而且只授权指定 ip. 所以，至少用户没办法手动操作直接 call api. 怎么着也要再搞个脚本 自动化一下。其实就拦截了不少特定场景下的用户了。

但是我觉得你的用户如果都是程序员，而且直接 call api 的动机很强，那基本上就没有用了。

[xuanbg]

合法的用户，拥有合法的权限，使用合法的方式调用接口，怎么就成了篡改数据？？？

如果这行为不符合你的预期，那一定是你的接口数据校验没做到位。这就不是身份验证或令牌的问题，而是对数据的操作没有进行必要的限制的问题。譬如订单都发货了，你还允许修改发货地址之类。

[zxcslove]

@xuanbg 除了游戏以外，用户应该对客户端有完全的权力，只是现在好多客户端都是吃里扒外，成了监军和叛徒。

[xiaooloong]

@markgor 「装个 Fiddler，你就算是 https 还不一样能拦截篡改。」问题就在于装 Fidder 的时候需要你信任 Fidder 的 根 CA，这个过程别说 tls 了，你电脑上应用程序的数字签名都没意义了。

[xylophone21]

可以看一看钉钉是怎么防虚拟定位打卡的
传统的
1. 客户端各种加密，防止非官方 App
2.客户端各种检测，防止 root 、虚拟机等模拟 GPS
以及比较狠的
1. [传说] 发现问题不报错，但是在后台标记，等着管理员找你

[pusheax]

无法防止。
重要的校验和限制，应当在服务器端完成，应当默认将客户端的所有输入都是不可信的。
即使是 https，也可以通过加自定义证书来实现中间人攻击。其它的什么验证码、token 也有办法绕过。
信息安全里面的 web 渗透测试就是研究这个的。
lz 可以去网上找几篇 burpsuite 和通过 burp 证书分析 ssl 流量的文章看一下。嗷，还有如何自动抓取 token 做爆破的。

[markgor]

@xiaooloong 我觉得有没意义是一回事，是否能拦截也是一回事；
而且我说的是针对前端参数可信情况，而你说的是个人电脑安全情况，完全不是一回事吧，
再者，我可以在虚拟机中装 Fiddler 进行拦截吧？（当然我没这样做过，我都是开发机直接装 Fiddler 来的）


@zyxk 没办法防，参考微信 web 版本，他们最后手段也只是根据注册账号的时间和使用频率等方面，限制账号是否能通过 web 登录。
而客户端的话可以采用 sdk 进行加密，甚至可以自定义协议。

其实微信就是一个最好参考对象；

[markgor]

其实讨论这个问题我觉得有点离题了。
问题本身精简而言就是 防篡改参数。

基于 WEB 形式,基本无解，哪怕你对请求参数进行加密，然后再把 JS 代码各种加密，最终别人甚至不需要解密你的 JS，直接 devtools 上打点，看看哪里是对参数加密的，把加密函数复制出来就可以了。（我之前遇到过大多数的都是这样
高深一点的，通过浏览器特性进行加密，类似携程防爬原理，某些特性某版本的浏览器是支持 /不支持的，通过这些差异来进行加密，后端通过请求的 ua 和规则验证下，就知道是否被篡改 /爬虫的请求了。

基于 APP 形式的：
这种玩法就多了，
一、使用自定协议
二、sdk 中写加密函数，分发 sdk 给第三方而不是给请求地址第三方
........

但其实就如楼上有人提过，不是不能破解，而是当破解效益低于破解成本时，没人会去破解；
现在很多第三方直接开通开放平台，接口我也直接给你调用，这种情况下谁还会去分析破解呢？
包括 v2ex，直接开放了 API 。

[xiaooloong]

@markgor 是我理解错你的意思了，无视我_(:зゝ∠)_

[wineast]

所以你的问题是防篡改，而不是防监听 /防抓包，所以和是否是 http/https 请求没关系
1. 防监听方面：当然 https 协议稍微安全点，中间人可以通过伪造证书的办法来抓到包，市面上现在的 fiddler，Charles 之类的，都是用此方法进行抓包。阻止的办法也很简单，现在很多银行类的 app 都在用，就是证书双向验证，只允许他颁发 /授权的证书进行通信，这样，自己办法的合法证书就无法通信了。
2. 防篡改方面，上面很多大佬都说了业界的标准方法了，方法加签+服务端验证，可以解决大部分的安全漏洞，至少大部分的 app，都是使用这个办法。
2.1 方法加签：将方法内所有参数 md5 加密，生成一个 signature，服务端接收到所有参数后，用同样方法再次生成 signature，做校验，另：参数可以加入时间戳，后续用服务端时间校验，可以保证请求在短期内有效，而长期无效
2.2 服务端校验：上面已经说过了，就是类似传 addressId，去数据库里校验这个 addressId 是否有值或者是否属于本 token，又比如对时间戳校验，是否在 5 分钟之内，等等等等业务级别的校验。
当然，防篡改方面，如果你的客户端是 web 端，理论上，你的加密过程（算法，包括私钥）都是透明的，就算用了混淆，黑客直接调用就好了，这里就有一个成本的问题

[zoharSoul]

验签

[Quarter]

我觉得上面有写回答好像达不对题

你这个问题的话，个人觉得没办法完全禁止，但是可以加大难度，用加密让用户无法查看到请求的数据结构，然后加上代码混淆，提高代码阅读复杂度，不让人轻易看懂代码执行逻辑，目前 web 端的话只想到这个

[2i2Re2PLMaDnghL]

实质上有一些诡异的策略，叫做低门槛高风险。
你随便修改，但被发现你随便修改侵害了服务提供方的利益，那么嘿嘿嘿

另外还有一种比较诡异的，API 限流付费。
钱能解决的问题，谁还去搞破解，傻之逼吗？

@seakingii 那更简单了，直接篡改 GPS 数据。你就算保证了整个客户端设备都是可信的，你也不能保证周围的电磁环境是可信的，使用单发射源发射信号并施以恰当的延迟可以模拟三维空间中任意位置，甚至可以不在地球表面。

@zxcslove 游戏也应该允许用户对客户端有完全的权力
游戏界内最优秀的常青树，都是可以用 mod 高度自定义的：老滚 5 还能玩 10 年，甚至 MC 1.7.10 都还能玩 30 年。
就算是网络游戏，甚至是 moba，也有 dota2 可以自行换皮（只有自己能看到），滚 OL 可以第三方汉化。
更别说 nethack 这楞是活了这么久的……

[tabris17]

请求加签名，如果只是浏览器请求那就算了吧，都可以破解

[zxcslove]

@2i2Re2PLMaDnghL 咱们意思差不多，我说游戏例外主要也是考虑公平性方面的。按道理讲，客户端应该完全为客户负责，可以是服务方提供，也可以是自制或从第三方获取。

[efaun]

防止不了，postman 可以直接模拟浏览器行为

[yc8332]

这种基本无法防止的。。你要做的是校验数据