API接口安全设计方案(已实现)

1、背景

网络安全方案,主要从数据加密与api接口安全两个方面考虑,数据加密https已经加密了,就不再次加密了;主要从api安全方面考虑。

2、接口安全设计

在代码层面,对接口进行安全设计
一、使用token进行用户身份认证
二、使用sign防止传入参数被篡改
三、用时间戳防止暴力请求

一、使用token进行用户身份认证

用户身份认证的流程图如下:

具体说明如下:

1、 用户登录时,客户端请求接口,传入用户名和密文的密码
2、 后台服务对用户身份进行验证。若验证失败,则返回错误结果;若验证通过,则生成一个随机不重复的token,并将其存储在redis中,设置一个过期时间。
  其中,redis的key为token,value为验证通过后获得的用户信息
3、 用户身份校验通过后,后台服务将生成的token返回客户端。
  客户端请求后续其他接口时,需要带上这个token。后台服务会统一拦截接口请求,进行token有效性校验,并从中获取用户信息,供后续业务逻辑使用

二、使用sign防止传入参数被篡改

为了防止中间人攻击(客户端发来的请求被第三方拦截篡改),引入参数的签名机制。
  具体步骤如下:

1、客户端和服务端约定一个加密算法(或MD5摘要也可), 客户端发起请求时,将所有的非空参数按升序拼在一起,通过加密算法形成一个sign,将其放在请求头中传递给后端服务。
2、后端服务统一拦截接口请求,用接收到的非可空参数根据约定好的规则进行加密,和传入的sign值进行比较。若一致则予以放行,不一致则拒绝请求。

由于中间人不知道加密方法,也就不能伪造一个有效的sign。从而防止了中间人对请求参数的篡改。

三、用时间戳防止暴力请求

sign机制可以防止参数被篡改,但无法防dos攻击(第三方使用正确的参数,不停请求服务器,使之无法正常提供服务)。因此,还需要引入时间戳机制。
  具体的操作为:客户端在形成sign值时,除了使用所有参数和token外,再加一个发起请求时的时间戳。即

sign值来源 = 所有非空参数升序排序+token+timestamp

而后端则需要根据当前时间和sign值的时间戳进行比较,差值超过一段时间则不予放行。
  若要求不高,则客户端和服务端可以仅仅使用精确到秒或分钟的时间戳,据此形成sign值来校验有效性。这样可以使一秒或一分钟内的请求是有效的。
  若要求较高,则还需要约定一个解密算法,使后端服务可以从sign值中解析出发起请求的时间戳。
  总结后的流程图如下:

3、项目拟采用的方案

(1)获取token

这里还是隐藏下了。

(2)接口新增三个字段:token、timestamp、sign

{ 
  "address": "33",
  "bussinessType": "22",
  "city": "111",
  "companyName": "st232ring",
  "token": "idfajdjjlkczkvhcklgjkfsj<jjkv",
  "timestamp": "20210714164139",
  "sign":"fdakfljdkfjdks"
}

(3)签名sign生成规则

规则:sha1(keyvalkeyval+token+timestamp+id)

例如:sha1(address33bussinessType22city111companyNamest232ringtokentimestampid)

这里新增一个id值,与token对应,传输过程中不使用,只用于加密,保证数据即使被截获,因为请求中没有id的传输,更加安全。

(4)几个参数上面已经说过了,简单再说一句。

token身份认证;

timestamp方式防止dos攻击,防止重放,简单说就是一次接口调用,只能用一定时间,比如比对时间,60s内该次调用有效,60秒后失效;

sign签名,通过参数+token+timestamp+id固定位加密,保证参数不会被修改,调用有效;


更多信息请关注公众号:「软件老王」,关注不迷路,软件老王和他的IT朋友们,分享一些他们的技术见解和生活故事。

posted @ 2021-07-16 16:38  软件老王  阅读(914)  评论(0编辑  收藏  举报