接口鉴权实践

以你之姓@ 2023-02-25 02:26 9阅读 0赞

### 文章目录 ###

*   *  目标
     *  技术方案架构图
     *   *  web前端
         *  web后端
     *  接口鉴权
     *  token 认证
     *  参数加密与解密
     *  签名 sign
     *  接口幂等性
     *  接口业务安全设计

## 目标 ##

*  了解接口鉴权细节
 *  实践接口鉴权
    
    参考：[活动 Web 页面人机识别验证的探索与实践][Web] 推荐阅读
    
    [API 接口安全性设计][API] 推荐阅读
    
    [接口的幂等性原则][Link 1]
    
    [接口交互鉴权以及数据处理 ][Link 2]
    
    \[开放接口的安全验证方案(AES+RSA)\]([http://wubaoguo.com/2015/08/21/%E5%BC%80%E6%94%BE%E6%8E%A5%E5%8F%A3%E7%9A%84%E5%AE%89%E5%85%A8%E9%AA%8C%E8%AF%81%E6%96%B9%E6%A1%88(AES+RSA)/][http_wubaoguo.com_2015_08_21_E5_BC_80_E6_94_BE_E6_8E_A5_E5_8F_A3_E7_9A_84_E5_AE_89_E5_85_A8_E9_AA_8C_E8_AF_81_E6_96_B9_E6_A1_88_AES_RSA]
    
    对称加密-SymmetricCrypto
    
    [Java生鲜电商平台-API接口设计之token、timestamp、sign 具体设计与实现][Java_-API_token_timestamp_sign]
    
    [开放API接口签名验证，让你的接口从此不再裸奔][API 1]
    
    [开放式API接口的安全处理][API 2]

> 可以阅读下上述参考的文章

## 技术方案架构图 ##

（参见[活动 Web 页面人机识别验证的探索与实践][Web] 文章）

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI4ODE3NzM5_size_16_color_FFFFFF_t_70]  
细节的可以参考上述文章，我的理解：

### web前端 ###

*  验证码（人机识别）
    
    又称为：全自动区分[计算机][Link 3]和人类的[图灵测试][Link 4]
    
    在日常使用的软件和网站中经常见到，当提交一些数据，需要填写验证码，用来检验当前用户是否是一个机器人，防止直接调用接口。在爬虫中，对于简单的验证码，可以通过机器学习来识别，对于复杂的人机识别，一般也不是很好处理。
 *  业务流程控制
    
    正常用户请求网站会等待页面加载，点击按钮等一系列动作，在其中添加数据埋点，记录触发的时间和触发的动作，用户的ip，信息，将这些信息汇总，通过验证算法来鉴别是否是正常用户。比如携带一些额外的参数，请求后台，来判断是否是正常请求。在一些反爬虫的校验中，会判断是否有 **user-agent** **referer** **origin** 等请求头信息
 *  数据加密
    
    对私密数据加密，比如账号密码，手机号等等。在许多网站中都很常见，但是，基于前端的加密，只要我们找到这些加密算法（js），都可以用来模拟加密过程。所以前端代码需要混淆，增加破解的难度。如下的登陆流程中，就包含对参数的加密和无效参数的提交。
    
    [登陆网站][Link 5]

### web后端 ###

*  鉴权服务
    
    用户登陆后，授予token标识当前用户，每次请求都要携带token请求接口。在传统web项目中，通常就是cookie存储的sessionid来标识用户。前后端分离架构中，将token设置在请求头的 Authorization中。建立ip白名单，来过滤恶意ip的请求。
 *  https协议
    
    使用https协议（http+ssl安全套接层），保证数据传输中的安全性。
 *  接口规范
    
    请求参数的校验和过滤，防止sql注入等。响应前端的数据，敏感数据需要脱敏，加密后再响应。

## 接口鉴权 ##

在微服务盛行的环境下，前后端分离的架构越来越流行，前端发送的Ajax请求，绝大多数都是需要授权后才能获取响应结果。针对服务间的接口调用，也需要鉴权后才允许访问通过。通常会将鉴权服务，单独抽离成为一个服务，避免在各个微服务中重新构建一套鉴权。

下图参考 [API 接口安全性设计][API]

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI4ODE3NzM5_size_16_color_FFFFFF_t_70 1]

## token 认证 ##

每次携带token，每次请求先校验token 的有效性和合法性。常见做法就是将登录后的用户信息存入redis中，设置过期时长为半小时，当用户每请求一次，重新设置redis的过期时间是半小时。

## 参数加密与解密 ##

*  对称加密
    
    加密解密使用同一套密钥。AES,DESede,DES 等等
    
    对称加密(也叫私钥加密)指加密和解密使用相同密钥的加密算法。有时又叫传统密码算法，就是加密密钥能够从解密密钥中推算出来，同时解密密钥也可以从加密密钥中推算出来。
 *  非对称加密
    
    分为公钥和私钥，可以使用公钥加密，私钥解密。也可以使用私钥加密，公钥解密。效率低于对称加密。RSA,DSA等
    
    非对称加密有公钥和私钥两个概念，私钥自己拥有，不能给别人，公钥公开。根据应用的不同，我们可以选择使用不同的密钥加密：
    
    1.  签名：使用私钥加密，公钥解密。用于让所有公钥所有者验证私钥所有者的身份并且用来防止私钥所有者发布的内容被篡改，但是不用来保证内容不被他人获得。
    2.  加密：用公钥加密，私钥解密。用于向公钥所有者发布信息,这个信息可能被他人篡改,但是无法被他人获得。

## 签名 sign ##

防止请求参数被更改。可以使用对称加密，或者非对称加密。

将请求参数拼接（如 param1=22&reqnum=858&key=value），使用 signkey 加密，将加密后的参数（sign=加密参数&reqnum=858）提交至提交接口中，提交接口接收参数解密,比对 reqnum 是否跟解密后的参数一致，一致认为参数没有被修改，不一致认为参数被修改。

可以参考：

nonce：随机值，是客户端随机生成的值，作为参数传递过来，随机值的目的是增加sign签名的多变性。随机值一般是数字和字母的组合，6位长度，随机值的组成和长度没有固定规则。

sign: 一般用于参数签名，防止参数被非法篡改，最常见的是修改金额等重要敏感参数， sign的值一般是将所有非空参数按照升续排序然后+token+key+timestamp+nonce(随机数)拼接在一起，然后使用某种加密算法进行加密，作为接口中的一个参数sign来传递，也可以将sign放到请求头中。接口在网络传输过程中如果被黑客挟持，并修改其中的参数值，然后再继续调用接口，虽然参数的值被修改了，但是因为黑客不知道sign是如何计算出来的，不知道sign都有哪些值构成，不知道以怎样的顺序拼接在一起的，最重要的是不知道签名字符串中的key是什么，所以黑客可以篡改参数的值，但没法修改sign的值，当服务器调用接口前会按照sign的规则重新计算出sign的值然后和接口传递的sign参数的值做比较，如果相等表示参数值没有被篡改，如果不等，表示参数被非法篡改了，就不执行接口了。

## 接口幂等性 ##

对于同一次发出的一次请求和多次请求的结果是一致的，不会因为请求多次，出现副作用。

出现副作用的一般表现在，更新数据，插入数据的接口。

在支付业务中，支付系统已经扣款，但是订单系统因为网络原因，没有获取到确切的结果，因此订单系统需要重试。支付系统并没有做到接口的幂等性，订单系统第一次调用和第二次调用，用户分别被扣了两次钱，不符合幂等性原则（同一个订单，无论是调用了多少次，用户都只会扣款一次）

解决方法： 业务逻辑的控制

## 接口业务安全设计 ##

接口设置，要避免一些参数来深度影响接口的结果。

*  查询到额外数据
    
    比如，数据库表的每条记录都会设置，是否删除的标志，普通用户一般情况下，是只允许查看生效的数据，所以这个参数不应该由前端传递，应该在后台限定死，限制只查询生效数据。
    
    比如地区编码，在查询条件中常见，一般情况下，只允许当前用户查看自己区域下的数据，如果这个由前台参数传递，如果修改了地区编码，就可以查看到别的地区数据。
 *  防止接口被循环
    
    比如生效的活动列表，在数据库可能配置了很多活动列表，前端获取当前生效的活动列表，根据活动id返回了活动信息，可能的活动id是 1,2,3 如果活动的id 是有顺序的，那么接口可能就被 顺序请求（1,2,3,4,5），获取到了整个数据表的数据，用户的id 订单id 同理，都可能被循环。
 *  重要操作增加权限校验
    
    常见操作就是验证用户的手机验证码，来确定当前操作用户是真正的用户。  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI4ODE3NzM5_size_16_color_FFFFFF_t_70 2]

[Web]: https://tech.meituan.com/2019/03/07/humans-and-bots-apart-for-activity-web-security.html
[API]: https://zhuanlan.zhihu.com/p/91485269
[Link 1]: https://www.cnblogs.com/hozon/archive/2019/01/18/10286494.html
[Link 2]: https://www.cnblogs.com/huatuoxie/p/9822953.html
[http_wubaoguo.com_2015_08_21_E5_BC_80_E6_94_BE_E6_8E_A5_E5_8F_A3_E7_9A_84_E5_AE_89_E5_85_A8_E9_AA_8C_E8_AF_81_E6_96_B9_E6_A1_88_AES_RSA]: http://wubaoguo.com/2015/08/21/%E5%BC%80%E6%94%BE%E6%8E%A5%E5%8F%A3%E7%9A%84%E5%AE%89%E5%85%A8%E9%AA%8C%E8%AF%81%E6%96%B9%E6%A1%88%28AES+RSA%29/
[Java_-API_token_timestamp_sign]: https://www.cnblogs.com/jurendage/p/12653865.html
[API 1]: https://www.jianshu.com/p/ad410836587a
[API 2]: https://zhuanlan.zhihu.com/p/33272881
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI4ODE3NzM5_size_16_color_FFFFFF_t_70]: /images/20230209/8c5ec8a8f463482c922295d0865270dc.png
[Link 3]: https://baike.baidu.com/item/%E8%AE%A1%E7%AE%97%E6%9C%BA
[Link 4]: https://baike.baidu.com/item/%E5%9B%BE%E7%81%B5%E6%B5%8B%E8%AF%95
[Link 5]: https://blog.csdn.net/qq_28817739/article/details/80119328
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI4ODE3NzM5_size_16_color_FFFFFF_t_70 1]: /images/20230209/17ad8bd07f1d491e8757e57457ce180d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI4ODE3NzM5_size_16_color_FFFFFF_t_70 2]: /images/20230209/ee7320689f06467e9f5421fd67b4c12e.png