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

《API应用接口安全管理细则.docx》由会员分享，可在线阅读，更多相关《API应用接口安全管理细则.docx（6页珍藏版）》请在第一文库网上搜索。

1、API应用接口安全管理细则一、API定义APl类型主要分为：内部API、企业定制APl与外部APl三种类型。本标准 主要关注外部APL即本标准所述的商业银行接口。两种形态：服务端到服务端、客户端SDK到服务端两种形态API。二、Token授权认证HnP协议是无状态的，一次请求结束，连接断开，下次服务器再收到请求， 它就不知道这个请求是哪个用户发过来的，但是对我们有权限访问限制的模块 而言，它是需要有状态管理的，以便服务端能够准确的知道HnP请求是哪个用 户发起的，从而判断他是否有权限继续这个请求。Token的设计方案是用户在客户端使用用户名和密码登录后，服务器会给客 户端返回一个TOken,并

2、将Token以键值对的形式存放在缓存（一般是RediS） 中，后续客户端对需要授权模块的所有操作都要带上这个TOkerb服务器端接收 到请求后进行TOken验证，如果TOken存在，说明是授权的请求。TOken生成的设计要求：1、应用内一定要唯一，否则会出现授权混乱，A用户看到了 B用户的数据；2、每次生成的Token一定要不一样，防止被记录，授权永久有效；3、一般Token对应的是Redis的key, value存放的是这个用户相关缓存信 息，比如：用户的id；4、要设置Token的过期时间,过期后需要客户端重新登录,获取新的Token, 如果Token有效期设置较短，会反复需要用户登录，体

3、验比较差，我们一般采 用Token过期后，客户端静默登录的方式，当客户端收到Token过期后，客户端 用本地保存的用户名和密码在后台静默登录来获取新的Token,还有一种是单独 出一个刷新Token的接口，但是一定要注意刷新机制和安全问题；根据上面的设计方案要求，我们很容易得到Token=md5（用户ID+登录的时间 戳+服务器端秘钥）这种方式来获得Token,因为用户ID是应用内唯一的，登录 的时间戳保证每次登录的时候都不一样，服务器端秘钥是配置在服务器端参与加 密的字符串（即：盐），目的是提高Token加密的破解难度，注意一定不要泄漏；三、时间戳超时机制客户端每次请求接口都带上当前时间的时

4、间戳timestamp,服务端接收到 timestamp后跟当前时间进行比对，如果时间差大于一定时间（比如：1分钟）， 则认为该请求失效。时间戳超时机制是防御DOS攻击的有效手段。四、URL签名写过支付宝或微信支付对接的同学肯定对URL签名不陌生，我们只需要将原 本发送给server端的明文参数做一下签名，然后在server端用相同的算法再做 一次签名，对比两次签名就可以确保对应明文的参数有没有被中间人篡改过。首先我们需要分配给客户端一个私钥用于URL签名加密，一般的签名算法如 下：2、对排序完的数组键值对用&进行连接，形成用于加密的参数字符串；3、在加密的参数字符串前面或者后面加上私钥，然后

5、用md5进行加密，得 到sign,然后随着请求接口一起传给服务器。例如：服务器端接收到请求后，用同样的算法获得服务器的sign,对比客户端的 Sign是否一致，如果一致请求有效；注意：对于客户端的私钥一定要妥善处理好，不能被非法者拿到，如果针对 于H5的项目，H5保存私钥是个问题，目前没有更好的方法，也是一致困扰我的 问题，如果大家有更好的方法可以留言一起探讨。五、防重放客户端第一次访问时，将签名Sign存放到服务器的RediS中，超时时间设 定为跟时间戳的超时时间一致，二者时间一致可以保证无论在timestamp限定时 间内还是外URL都只能访问一次，如果被非法者截获，使用同一个URL再次访

6、 问，如果发现缓存服务器中已经存在了本次签名，则拒绝服务。如果在缓存中的 签名失效的情况下，有人使用同一个URL再次访问，则会被时间戳超时机制拦截, 这就是为什么要求sign的超时时间要设定为跟时间戳的超时时间一致。拒绝重 复调用机制确保URL被别人截获了也无法使用（如抓取数据）。以上方案流程如下:1、客户端通过用户名密码登录服务器并获取Token；2、客户端生成时间戳timestamp,并将timestamp作为其中一个参数；3、客户端将所有的参数，包括TOken和timestamp按照自己的签名算法进 行排序加密得到签名sign4、将tokens timestamp和sign作为请求时必须

7、携带的参数加在每个请求 的URL后边。例：5、服务端对token、timestamp和sign进行验证,只有在token有效、 timestamp未超时、缓存服务器中不存在sign三种情况同时满足，本次请求才 有效；六、采用HTTPS通信协议众所周知HTTP协议是以明文方式发送内容，不提供任何方式的数据加密， 如果攻击者截取了客户端和服务器之间的传输报文，就可以直接读懂其中的信息, 因此HnP协议不适合传输一些敏感信息，比如信用卡号、密码等。为了解决HnP协议的这一缺陷，需要使用另一种协议：安全套接字层超文 本传输协议HnPS,为了数据传输的安全，HnPS在HnP的基础上加入了 SSL 协议，

8、SSL依靠证书来验证服务器的身份，并为客户端和服务器之间的通信加密。HnPS也不是绝对安全的，如下图所示为中间人劫持攻击，中间人可以获取 到客户端与服务器之间所有的通信内容。中间人截取客户端发送给服务器的请求，然后伪装成客户端与服务器进行通 信；将服务器返回给客户端的内容发送给客户端，伪装成服务器与客户端进行通 信。通过这样的手段，便可以获取客户端和服务器之间通信的所有内容。使用中间人攻击手段，必须要让客户端信任中间人的证书，如果客户端不信 任，则这种攻击手段也无法发挥作用。2针对安全性要求一般的app,可采用通过校验域名，证书有效性、证书关 键信息及证书链的方式；七、签名算法签名计算：Sig

9、nature = Hmac-Shal(SecretKey, StringToSign)签名字符串(StringToSign)的构造：StringToSign 二HttpMethod + n+ Path + n+ Body-MD5 + n+ Date + n+ param-stringHttpMethod: HnP 请求方法,如 GET、POST、PUT、DELETE,需大写。Path： URI path, api/v1/messageBody-MD5: HTTP Body 的 MD5 摘要,小写。如果 body 为空,Body-MD5 为空 字符串Date： HnP首部字段，请求的当前时间。格

10、式遵循rfc822,如MOn, 24 Nov2014 12:11:17 GMTparam string：将所有参数(包括GET或POST的参数，忽略值为空的参数)格式化为“key=VaIUe” 格式，如 “kl=vl、k2=v2、k3=v3” 包括 url 参数和 POST 请求的表单方式，当参数为json的情况下不参与，将格式化好的参数键值对以 字典序升序排列后，拼接在一起，如kl71&k2=v2&k3=v3，根据HnP协议要求，传递参数都需要对参数值做 URL Encoding,这样请求接受方才能接受到正确的参数值。这种情况下，做签名 时使用的应该是原生值而不是encoding之后的值。签

11、名PHP代码签名代码-PHP?php$key =appseJCkeaSUHYFkAVEitqagAr;Sbody =content：just a test”, msg_type：1, PUSh_type：1;Jdate 二,Tue, 25 Nov 2014 14:00:52 CST,;echo _getSign($key, $body, $date);时间的生成/echo date (, D, d M Y H: i: s T,);function _getSign($key, $body, $date)$md5_body = md5(Jbody);$SigrFarray (POST”, zza

12、pi/v 1 /message, $md5_body, $date, )；$Sign=implode(n， $sign);return hash_hmac(, shal, $sign, $key);)示例调用接口推送消息。假设用户已经创建过App,服务端分配了 APPId和APPSec。AppId 为：appid_b515357337f7415ab9275df7a3f92d94AppSec 为：appsec_ckeasUHYFkAvEitqagAr此接口的 HttPMethod 为：POSTPath 为：apivlmessage推送的参数以json格式通过body传递，body内容为：cont

13、ent:just a test”, msg_type：1, PUSh_type：1计算出的 Body-MD5 为：7eb8c78fl834ac82d0203a5a0a35ce80取得当前时间 Date 为:Tue, 25 Nov 2014 14:00:52 CST推送消息没有URL参数，所以ParanIString为空。StringToSign 为：zzPOSTapivlmessage7eb8c78fl834ac82d0203a5a0a35ce80Tue, 25 Nov 2014 14:00:52 CST对 StringToSign 进行HmaC-ShaI 签名，得到 Signature：3b

14、635f825d3c34eb6497b636e35e81777ef3c659将Date和Authorization加入HnP报文首部最终发送的HnP报文如下：POST apivlmessage HTTP1. 1Host: push, scloud. letv. comAuthorization: LETV appid_b515357337f7415ab9275df7a3f92d94 3b635f825d3c34eb6497b636e35e81777ef3c659 Date: Tue, 25 Nov 2014 14:00:52 CST“content：just a test”, msg_type：1, PUSh_type：1