API应用接口安全管理细则.docx

API应用接口安全管理细则 API定义 API类型主要分为：内部API、企业定制API与外部API三种类型。本标准主要关注外部API，即本标准所述的商业银?接?。 两种形态：服务端到服务端、客户端SDK到服务端两种形态API。 Token授权认证 HTTP协议是?状态的，?次请求结束，连接断开，下次服务器再收到请求，它就不知道这个请求是哪个?户发过来的，但是对我们有权限访问限制的模块??，它是需要有状态管理的，以便服务端能够准确的知道HTTP请求是哪个?户发起的，从?判断他是否有权限继续这个请求。 Token的设计?案是?户在客户端使??户名和密码登录后，服务器会给客户端返回?个Token，并将Token以键值对的形式存放在缓存（?般是Redis）中，后续客户端对需要授权模块的所有操作都要带上这个Token，服务器端接收到请求后进?Token验证，如果Token存在，说明是授权的请求。 Token?成的设计要求： 1、应?内?定要唯?，否则会出现授权混乱，A?户看到了B?户的数据； 2、每次?成的Token?定要不?样，防?被记录，授权永久有效； 3、?般Token对应的是Redis的key，value存放的是这个?户相关缓存信息，?如：?户的id； 4、要设置Token的过期时间，过期后需要客户端重新登录，获取新的Token，如果Token有效期设置较短，会反复需要?户登录，体验?较差，我们?般采?Token过期后，客户端静默登录的?式，当客户端收到Token过期后，客户端?本地保存的?户名和密码在后台静默登录来获取新的Token，还有?种是单独出?个刷新Token的接?，但是?定要注意刷新机制和安全问题； 根据上?的设计?案要求，我们很容易得到Token=md5(?户ID+登录的时间戳+服务器端秘钥)这种?式来获得Token，因为?户ID是应?内唯?的，登录的时间戳保证每次登录的时候都不?样，服务器端秘钥是配置在服务器端参与加密的字符串（即：盐），?的是提?Token加密的破解难度，注意?定不要泄漏； 时间戳超时机制 客户端每次请求接?都带上当前时间的时间戳timestamp，服务端接收到timestamp后跟当前时间进??对，如果时间差?于?定时间（?如：1分钟），则认为该请求失效。时间戳超时机制是防御DOS攻击的有效?段。 URL签名 写过?付宝或微信?付对接的同学肯定对URL签名不陌?，我们只需要将原本发送给server端的明?参数做?下签名，然后在server端?相同的算法再做?次签名，对?两次签名就可以确保对应明?的参数有没有被中间?篡改过。 ?先我们需要分配给客户端?个私钥?于URL签名加密，?般的签名算法如下： 2、对排序完的数组键值对?&进?连接，形成?于加密的参数字符串； 3、在加密的参数字符串前?或者后?加上私钥，然后?md5进?加密，得到sign，然后随着请求接??起传给服务器。 例如： 服务器端接收到请求后，?同样的算法获得服务器的sign，对?客户端的sign是否?致，如果?致请求有效； 注意：对于客户端的私钥?定要妥善处理好，不能被?法者拿到，如果针对于H5的项?，H5保存私钥是个问题，?前没有更好的?法，也是?致困扰我的问题，如果?家有更好的?法可以留??起探讨。 防重放 客户端第?次访问时，将签名sign存放到服务器的Redis中，超时时间设定为跟时间戳的超时时间?致，?者时间?致可以保证?论在timestamp限定时间内还是外 URL都只能访问?次，如果被?法者截获，使?同?个URL再次访问，如果发现缓存服务器中已经存在了本次签名，则拒绝服务。如果在缓存中的签名失效的情况下，有?使?同?个URL再次访问，则会被时间戳超时机制拦截，这就是为什么要求sign的超时时间要设定为跟时间戳的超时时间?致。拒绝重复调?机制确保URL被别?截获了也?法使?（如抓取数据）。 以上?案流程如下： 1、客户端通过?户名密码登录服务器并获取Token； 2、客户端?成时间戳timestamp，并将timestamp作为其中?个参数； 3、客户端将所有的参数，包括Token和timestamp按照??的签名算法进?排序加密得到签名sign 4、将token、timestamp和sign作为请求时必须携带的参数加在每个请求的URL后边。 例： 5、服务端对token、timestamp和sign进?验证，只有在token有效、timestamp未超时、缓存服务器中不存在sign三种情况同时满?，本次请求才有效； 采?HTTPS通信协议 众所周知HTTP协议是以明??式发送内容，不提供任何?式的数据加密，如果攻击者截取了客户端和服务器之间的传输报?，就可以直接读懂其中的信息，因此HTTP协议不适合传输?些敏感信息，?