mirror of
https://gitee.com/tawords/tawords-docs
synced 2025-01-11 11:58:14 +08:00
28 lines
2.3 KiB
Markdown
28 lines
2.3 KiB
Markdown
|
如果单纯考虑加解密，或者签名方式来保证请求合法，其实是远远不够的。事实上，一个安全的API平台往往需要多方面一起考虑，保证请求安全合法。
|
|||
|
|
|
|||
|
|
## 1、是不是实际客户端的请求？
|
|||
|
|
|
|||
|
|
设计专门的私有请求头：定义独有的Request headers，标明有此请求头的请求合法。
|
|||
|
|
请求包含请求时间：定义时间，防止中间拦截篡改，只对指定超时范围内（如10秒）的请求予以响应。
|
|||
|
|
请求URI是否合法：此URI是否在API平台注册？防止伪造URI攻击
|
|||
|
|
请求是否包含不允许的参数定义：请求此版本的这个URI是否允许某些字段，防止注入工具。
|
|||
|
|
部分竞争资源是否包含调用时版本（Etag）：部分竞争资源，使用If-Match头提供。如用户资金账户查询API，可以返回此时的账户版本，修改扣款时附加版本号（类似乐观锁设计）。
|
|||
|
|
|
|||
|
|
|
|||
|
|
## 2、API平台是否允许你调用（访问控制）？
|
|||
|
|
|
|||
|
|
访问控制，主要是授权调用部分。API都对外暴露，但是某些公共API可以直接请求，某些，需要授权请求。本质的目的，都是为了验证发起用户合法，且对用户能标识统计计费。
|
|||
|
|
|
|||
|
|
以HMac Auth为例，我们简单设计一个签名算法。开发者注册时获取App Key、App Secret，然后申请部分API的访问权限，发起请求时：
|
|||
|
|
|
|||
|
|
所有请求参数按第一个字符升序排序（先字母后数字），如第一个相同，则看第二个，依次顺延。
|
|||
|
|
按请求参数名及参数值相互连接组成一个字符串。param1=value1¶m2=value2...（其中包含App Key参数）
|
|||
|
|
将应用密钥分别添加到以上请求参数串的头部和尾部:secret + 请求参数字符串 + secret。
|
|||
|
|
对该字符串进行 SHA1 运算，得到一个二进制数组。
|
|||
|
|
将该二进制数组转换为十六进制的字符串，该字符串为此次请求的签名。
|
|||
|
|
该签名值使用sign系统级参数一起和其它请求参数一起发送给API平台。
|
|||
|
|
服务端先验证是不是实际客户端的请求，然后按照App Key查找对应App Secret，执行签名算法，比较签名是否一致。签名一致后查看此App Key对应的用户是否有访问此API的权限，有则放行。
|
|||
|
|
|
|||
|
|
执行成功后包装返回指定格式的结果，进行统计计费。
|
|||
|
|
|
|||
|
|
https://www.ituring.com.cn/article/208878
|