服务老是被攻击？教你设计一套安全的接口访问策略，非常稳健！

最新推荐文章于 2025-03-08 10:28:18 发布

转载最新推荐文章于 2025-03-08 10:28:18 发布 · 121 阅读

CC 4.0 BY-SA版权

原文链接：https://mp.weixin.qq.com/s?__biz=MzUzMTA2NTU2Ng==&mid=2247589326&idx=2&sn=b38faef4e966684a5a844e90a949a086&chksm=fb4993acfc1a1d6c960cc60732c7a7713cfabe22656cf8427e23db1441fefab9a2c27e59d31f&scene=126&sessionid=0

文章标签：

#安全

👉 这是一个或许对你有用的社群

🐱 一对一交流/面试小册/简历优化/求职解惑，欢迎加入「芋道快速开发平台」知识星球。下面是星球提供的部分资料：

《项目实战（视频）》：从书中学，往事上“练”
《互联网高频面试题》：面朝简历学习，春暖花开
《架构 x 系统设计》：摧枯拉朽，掌控面试高频场景题
《精进 Java 学习指南》：系统学习，互联网主流技术栈
《必读 Java 源码专栏》：知其然，知其所以然

👉这是一个或许对你有用的开源项目

国产 Star 破 10w+ 的开源项目，前端包括管理后台 + 微信小程序，后端支持单体和微服务架构。

功能涵盖 RBAC 权限、SaaS 多租户、数据权限、商城、支付、工作流、大屏报表、微信公众号、CRM 等等功能：

Boot 仓库：https://gitee.com/zhijiantianya/ruoyi-vue-pro
Cloud 仓库：https://gitee.com/zhijiantianya/yudao-cloud
视频教程：https://doc.iocoder.cn

【国内首批】支持 JDK 21 + SpringBoot 3.2.2、JDK 8 + Spring Boot 2.7.18 双版本

来源：juejin.cn/post/
7121168651222253599

最近接手了一个项目，兴致勃勃的准备大干一场，结果一顿渗透测试下来我都快傻了。什么防重放攻击，请求体篡改，越权攻击，都整上来了，好嘛，我都不清楚这个项目这半年是怎么度过的。

不知道大家公司对接口安全这块是怎么考量的，但是对于面向公网提供服务的产品来说，这个可以说是很致命的了。那么，该如何设计一套比较安全的接口访问策略呢？

一、Token与签名

一般客户端和服务端的设计过程中，大部分分为有状态和无状态接口。一般用户登录状态下，判断用户是否有权限或者能否请求接口，都是根据用户登录成功后，服务端授予的token进行控制的。但并不是说有了token，请求就是安全的，那么万一token泄露了怎么办呢？谁都可以调用我的服务了吗？

就比如去银行取钱，需要用到银行卡。但不能因为你不小心把银行卡弄丢了，捡到的人就可以拿着你的银行卡去银行办理业务了。他们还需要对你的身份进行验证，你也要知道银行卡密码。

所以token只是用户权限以及会话的凭证，除了会话的凭证，我们也要校验请求的合法性，以防止token泄露而导致客户的损失。

而签名摘要计算则是用来进行请求合法性校验。经常同学们会把这两种搞混。以为使用token就是安全的。

基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能

项目地址：https://github.com/YunaiV/ruoyi-vue-pro
视频教程：https://doc.iocoder.cn/video/

二、签名计算设计

签名摘要的计算一般分为签名值和签名的key，signature生成方式如下：

signature = Base64(HMAC-SHA256(LOWER(MD5(key)), StringToSign))

2.1 签名字符串的设计

设计签名字符串时，我们要想好，我们要针对不同的攻击策略，设计什么样的请求头部

常用的签名字符串设计如下：

StringToSign =  Content-MD5 + "\n"
               + CanonicalizedHeaders

CanonicalizedHeaders构建方法如下：

1.以service为前缀的的Headers，但是不包括service-signature，如下

service-nonce：客户端生成32位随机字符串，所有客户端5分钟内不能重复，重复时平台回复nonce重复，客户端需要重新请求。
service-date：请求生成的时间，与服务器本地时间差超过5分钟，认为鉴权失败。
service-session-id：客户端会话id，用于本次登录后的所有请求会话标识。
service-client：客户端信息，包括客户端类型、客户端版本、操作系统等。

2.Header名称全部小写，值前后应不包含空格

3.Header的名称和值之间用“:”相隔，组成一个完整的header

4.根据header名称的字符顺序，将header从小到大进行字典排序，每个header之后跟一个“\n”

StringToSign生成示例

eB5eJF1ptWaXm4bijSPyxw==\n
service-client:ewogICAgImRhdGEiOiB7CiAgICAgICAgImNsaWVudFR5cGUiOiAieHh4IiwKICAgICAgICAiY2xpZW50VmVyc2lvbiI6ICIzLjAiCiAgICB9Cn0=\n
service-date:2022-07-22T14:43:07Z\n
service-nonce:d36e316282959a9ed4c89851497a717f\n
service-session-id:0123456\n

2.2. 签名key设计

一般客户端请求的接口类型有三种，分别是有登录状态和无登录状态以及登录这个特殊接口。无登录状态前的接口都是服务为了提供能力而做的一些接口，相比而言都是提供通用能力的。不涉及客户个人信息相关。安全风险较小。

用户登录后的接口一般都是涉及到客户信息的接口，隐私泄露风险较大。因此对于每一种状态可采用不同的key值设计。讲风险降到最低。

2.2.1. 用户未登录签名key值

用户未登录时，平台提供通用能力，调用服务端接口时使用约定好的固定SK进行接口签名鉴权即可。固定SK由后台提供16位的随机字符串。

2.2.2. 用户登录签名key值

我们知道，所有在客户端和前端保存的key值永远不是最安全的，有可能被拆包而发现对应的加密SK，从而被不法分子破解，因此用户登录时，传输密码时，如果使用固定key，有可能body体被解开，密码被泄露的风险。

登录时用户会输入密码，而服务端也知道用户加密后的密码，那么使用用户输入的密码当做key则是最安全的方式。并且交互过程中不需要将用户密码放在body体重传到后端进行校验，只需校验签名的准确性即可。这样就可以极大的增加用户密码的安全性。

用户登录验证时会输入用户的密码，则登录时用户密码作为签名的key进行鉴权校验。加密key为：SHA256(LOWER(MD5(passwd)),salt)，salt为用户的盐值，可以使用用户的手机号。

2.2.3. 用户登录签名key值

用户登录成功之后，所有接口都要有鉴权，为了每个用户安全起见，针对每个用户颁发自己的SK，登录成功后获取。这样客户端将sercet保存到内存中，可以有效防止SK泄露。

用户注册成功后，针对用户账户后台生成16位的sercet
用户登录成功后，后台返回用户的sercet
登录之后的接口鉴权使用sercet进行鉴权。

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能

项目地址：https://github.com/YunaiV/yudao-cloud
视频教程：https://doc.iocoder.cn/video/

三、接口合法性校验流程

请求合法性校验流程如下：

1、首先对接口的请求头的nonce进行5分钟内是否重复的校验，可以有效的防止重放攻击。

2、然后对时间戳进行校验，防止客户端时间篡改攻击。

3、之后对请求的MD5进行校验，防止对请求体进行篡改。

4、最后将nonce，date，md5以及session进行组合签名校验，校验签名值是否成功。可以有效防止上面单一修改验证通过，但签名值校验不通过的问题。

基于以上的校验，基本上可以防止大部分攻击场景。当然为了更加安全，你还可以增加黑白名单限制、接口访问限流、用户常用设备绑定、用户异地登录等保护用户财产的安全性设计。

好了，不知道这篇文章大家对安全的设计是否有了更深刻的理解呢？大家有没有更好地接口安全设计方案，可以一起聊一聊哈。

欢迎加入我的知识星球，全面提升技术能力。

👉 加入方式，“长按”或“扫描”下方二维码噢：

星球的内容包括：项目实战、面试招聘、源码解析、学习路线。

文章有帮助的话，在看，转发吧。
谢谢支持哟 (*^__^*）