今天领导给我派了个任务.
原文:"严格管控 API 接口共享,有效限制并发现二次封装、转发行为."
让我提供可行性方案.
按我的理解,如果把接口文档和秘钥给别人了.别人拿到数据想怎么处理怎么处理,根本无法触及.
我只能做到拦截攻击者修改请求参数,拦截重复的请求.
就是防止用户看了 f12,把参数一改,这样请求.
是不是我对封装和转发的理解不对?
另外提一嘴,这是省处 x 局传下来的指示,无法反驳,必须做.做不到忽悠也要忽悠过去.
大家能指点下如何实现或者如何忽悠吗
1
zhazi 2023-02-24 13:36:29 +08:00
让我们看看神奇海螺怎么说
限制或发现 API 接口的二次封装和转发行为,可以考虑以下几种方法: API 密钥限制:可以在 API 接口中加入 API 密钥验证,限制只有特定的应用程序或开发人员才能够调用 API 接口。这样可以防止未经授权的第三方应用程序或开发人员封装和转发 API 接口。 记录 API 调用日志:记录 API 调用日志可以帮助开发人员追踪和监视 API 的使用情况,包括 API 被哪些应用程序或开发人员调用、调用次数和调用频率等。通过这些信息,开发人员可以判断是否存在二次封装和转发行为。 API 访问限制:可以设置 API 的访问限制,例如限制 API 的调用次数、频率和流量等。这样可以防止过度使用和滥用 API 接口,减少二次封装和转发的可能性。 加密传输:在 API 接口的传输过程中使用加密技术,例如 SSL/TLS 等,可以防止第三方应用程序或开发人员通过网络拦截和窃取 API 接口数据。 数字签名:可以在 API 接口中加入数字签名验证,确保请求和响应数据的完整性和安全性。这样可以防止第三方应用程序或开发人员篡改 API 接口数据。 以上方法可以有效地限制或发现 API 接口的二次封装和转发行为,但需要开发人员在设计 API 接口时就考虑这些因素,并对 API 接口进行适当的安全设计和实现。 |
2
nothingistrue 2023-02-24 13:49:02 +08:00
“严格管控 API 接口共享”,这已经说得很明确了,是防止第三方合作者,把秘钥等认证方式共享出去。二次封装跟转发差不多,都是把你们原本是给第三方合作者(一包方)用的接口,第三方把接口包装了一下当成自己的接口再买给第三方的第三方(二包方甚至更多包方)。二次封装是把 key 套个壳就扔给二包方使用,二包方直接访问你们的接口。转发是 key 不外放,二包方也不能直接访问你们的接口,他们需要先访问一包方,再有一包方代为访问你们的接口。
类比到互联网服务可能更容易理解,就是账号共享。 |
3
Juszoe 2023-02-24 13:50:25 +08:00
限制 IP ,调用频率。无法完全杜绝这种现象,但也能大幅限制了。
|
4
nothingistrue 2023-02-24 13:55:12 +08:00
防 API 共享比防账号共享容易多了,因为 API 的用户是第三方合作者,是可以强实名的,发现之后就不用防止,直接法务伺候。不过如何发现被共享就是一门大学问了,要看你们接口是如何开放的。然而这不重要,既然是 x 局派领导,领导再派小兵的任务,忽悠一下就行了。
|
5
tool2d 2023-02-24 14:20:30 +08:00
以前前端提交数据都是用 json ,我现在全部改成了加密二进制传输。
普通用户想靠 F12 修改内容,还是要有点水平才行的。 |
6
InDom 2023-02-24 14:26:41 +08:00
复杂签名,一次性请求,限制频率,加强监测.
|
7
mafanding 2023-02-24 14:38:44 +08:00
1.限制 IP 和调用次数(这已经不是限制频率了,而是要求业务方告诉你们他一天的业务预计调用次数按照这个限制)
2.收费 没有完全杜绝的办法只能提高调用的成本 比如:1 天一个 apikey100 次或一个 ip100 次,每次 1 块 |
8
cslive 2023-02-24 14:43:07 +08:00
ip 白名单
|
9
bk201 2023-02-24 14:52:42 +08:00
出现异地 ip 调用直接 ban ,但是也拦不住对方做跳板机转发。
|
10
Seulgi 2023-02-24 15:33:45 +08:00
学腾讯开放平台,请求地址白名单,发放 key ,相当于一个 key 会绑定几个请求域名,拿到这个 key 不是这些域名也没法请求。
|
11
wonderfulcxm 2023-02-24 15:38:20 +08:00 via iPhone
除非 ip 白名单,其他都能利用啊
|
12
ONEBOYS 2023-02-24 15:41:51 +08:00
说 ip 白名单的人想简单了吧,人家是二次封装,不是直接给别人用
|
13
superliy 2023-02-24 15:43:02 +08:00
|
14
Seulgi 2023-02-24 15:43:09 +08:00
然后就是记录请求日志,一个 key 每日的调用量,做一个相对异常报警,突然量上去了,肯定不正常。这种情况,可以限制每日调用量,参考各平台的免费接口调用次数方案。如果对方量上去了,要求你们开更高的套餐,让提供原因就行了。zf 部门接口,这么高级别的话,接口调用次数升级肯定都是线下详谈,还是比较安全的。
|
15
SenLief 2023-02-24 15:44:07 +08:00
技术解决远没有法律来的快,根据大概的请求数设定一个合同限制,超过限制就停掉这个 token 的请求不就好了。
|
16
Seulgi 2023-02-24 15:44:21 +08:00
@superliy 白名单+接口调用量分级制。按需求来沟通开哪个级别。后续升级提交申请。这种 zf 部门,你申请材料也不可能随便填填就让你过。
|
17
superliy 2023-02-24 15:44:47 +08:00
看来限制频率是唯一的办法
|
18
VYSE 2023-02-24 15:49:45 +08:00
做成 SDK 集成设备指纹, 上风控策略, 找专业安全公司吧
|
19
pengqiuyuan 2023-02-24 15:50:14 +08:00
chatgpt
|
20
pengqiuyuan 2023-02-24 15:50:24 +08:00
您对于接口的封装和转发的理解是正确的,如果其他人拿到接口文档和秘钥,他们可以随意地使用接口返回的数据,这是无法限制的。但是,您仍然可以采取一些措施来尽量限制和发现二次封装和转发行为。
以下是一些可能有用的措施: 接口权限管理:确保只有授权的应用程序和用户才能访问 API 接口,通过 OAuth2.0 等授权方式进行权限管理,限制接口的访问者范围。 请求频率限制:对于接口的访问次数和频率进行限制,限制每个应用程序或用户对接口的访问频率。例如,您可以设置每秒或每分钟最多能够接收多少个请求。 防止恶意攻击:通过防火墙或其他安全设备防止网络攻击,例如 DDoS 攻击、SQL 注入等,这些攻击可能导致接口数据泄漏或接口服务不可用。 监控接口访问日志:记录每个接口的访问日志,包括访问者的 IP 地址、访问时间、请求内容等信息,及时发现异常请求行为。 检查请求头和参数:检查请求头和参数是否合法和正确,如果有异常或错误的请求头或参数,拒绝访问。 接口数据加密:对于需要保护数据安全的接口,使用加密方式传输数据,例如使用 HTTPS 协议传输接口数据。 以上是一些可能有用的措施,但无法完全保证二次封装和转发行为不会发生。因此,您可以考虑对于敏感的接口或数据进行特别处理,例如对于一些重要的接口或数据,采用额外的安全认证方式,例如人工审核等。同时,也需要不断地进行接口安全方面的监控和改进,及时发现和修复潜在的漏洞和安全问题。 最后,关于如何“忽悠”过去这个任务,我建议您尽量遵守领导的指示,采取一些可行的措施来限制和发现二次封装和转发行为,如果有任何不确定或有困难的地方,您可以向领导或其他相关人员咨询并协商解决。 |
21
lambdaq 2023-02-24 15:55:21 +08:00
当年邓亚萍做人民搜索,跟谷歌合作,要求开放 api
谷歌给你提供几个加了密的 dll 。。。你去调用吧。2333 |
22
zhang77555 2023-02-24 16:01:10 +08:00
只能用频率限制,因为只要别人是个合法用户他就总有办法二次封装
控制调用频率其实也是能解决你交差的问题的,因为他把你们的服务封装给别人用,你控制了频率,那么他这个服务也卖不了几个人了 |
23
leon0204 2023-02-24 16:02:35 +08:00
加个验证码,人脸识别 ,封装之后的用户怎么能提供呢 ,这不就好了
|
24
outas 2023-02-24 16:05:33 +08:00
这个问题各大开放平台都已经帮你解决好了,限制调用频率、每日上限次数、收费,直接照着抄
|
25
yc8332 2023-02-24 16:35:16 +08:00
无解的。只能限制频次、限 ip ,增加付费而已。
|
26
lakehylia 2023-02-24 16:42:47 +08:00
大数据呗。比如支付接口,客户是注册的餐饮,但是经常大半夜调用接口,那肯定是卖接口了。客户是餐饮,但是支付的金额老是 100 / 200 / 500 这样的整数,卖接口了。等等。
|
27
wanguorui123 2023-02-24 17:19:30 +08:00
单点登录
|
28
aschoolboy OP 感谢大家提供思路,公职部门,只要个方案,没有好办法根本杜绝,但我已经应付过去了.
|