API接口安全性

安全防御方案

• 加随机数
  该方法优点是认证双方不需要时间同步，双方记住使用过的随机数，如发现报文中有以前使用过的随机数，就认为是重放攻击。缺点是需要额外保存使用过的随机数，若记录的时间段较长，则保存和查询的开销较大。

• 加时间戳
  该方法优点是不用额外保存其他信息。缺点是认证双方需要准确的时间同步，同步越好，受攻击的可能性就越小。但当系统很庞大，跨越的区域较广时，要做到精确的时间同步并不是很容易。

• 加流水号
  就是双方在报文中添加一个逐步递增的整数，只要接收到一个不连续的流水号报文(太大或太小)，就认定有重放威胁。该方法优点是不需要时间同步，保存的信息量比随机数方式小。缺点是一旦攻击者对报文解密成功，就可以获得流水号，从而每次将流水号递增欺骗认证端。

• Token授权机制
  用户使用用户名密码登录后服务器给客户端返回一个Token（通常是UUID），并将Token-UserId以键值对的形式存放在缓存服务器中。服务端接收到请求后进行Token验证，如果Token不存在，说明请求无效。

• 签名机制
  将Token和时间戳加上其他请求参数就行MD5或SHA-1算法（可根据情况加点盐）加密，加密后的数据为本次请求的签名sign，并将该签名存放到缓存服务器中，超时时间设定为跟时间戳的超时时间一致（这就是为什么要尽量短，二者时间一致可以保证无论在timestamp规定时间内还是外本URL都只能访问一次）。服务端接收到请求后以同样的算法得到签名，并跟当前的签名进行比对，如果不一样，说明参数被更改过，直接返回错误标识。同一个签名只能使用一次，如果发现缓存服务器中已经存在了本次签名，则拒绝服务。

• 数据传输加密
  目前普遍采用SSL协议中相关算法进行传输层的加密，通常是对称的摘要算法（配合证书通过https进行数据对接），或者使用VPN（IPSEC VPN、SSL VPN、MPLS VPN）进行传输甚至专用电路MSTP。

• 数据的完整性
  主要是指数据的真实性和防篡改。目前通常采用签名算法来保证，如MD5，RSA等。
  签名时将字符转化成字节流时指定的字符集保持一致， 根据HTTP协议要求，传递参数的值中如果存在特殊字符（如：&、@等），那么该值需要做URLEncoding，这样请求接收方才能接收到正确的参数值。这种情况下，待签名数据应该是原生值而不是encoding之后的值。例如：调用某接口需要对请求参数email进行数字签名，那么待签名数据应该是：email=test@test.com，而不是email=test%40test.com。
  RSA签名方法需要公钥和私钥，数据提供方使用私钥对数据进行加密，并由数据提供方向数据接收方提供公钥进行解密。当数据提供方将数据发送到数据接收方，该数据将被数据提供方私钥进行加签，同时数字签名也将被包括在发送到数据接收方的数据中。
  当接收到来自数据提供方数据，数据接收方首先​​构造待签名字符串，然后把待签名字符串、数据提供方提供的公钥、数据提供方提供的参数sign的值三者一同放入RSA的签名函数中进行非对称的签名运算，来判断签名是否验证通过。

组合使用情况

• 
  
• 将方法 加随机数 、 加时间戳 组合使用，这样就只需保存某个很短时间段内的所有随机数，而且时间戳的同步也不需要太精确。
• 将方法 加时间戳、Token、签名机制 组合使用。
  
  • 客户端通过用户名密码登录服务器并获取Token
  • 客户端生成时间戳timestamp，并将timestamp作为其中一个参数
  • 客户端将所有的参数，包括Token和timestamp按照自己的算法进行排序加密得到签名sign
  • 将token、timestamp和sign作为请求时必须携带的参数加在每个请求的URL后边（http://url/request?token=123&timestamp=123&sign=123123123）
  • 服务端写一个过滤器对token、timestamp和sign进行验证，只有三个参数都正确且在规定时间内，本次请求才有效
    

结果在以上三中组合机制的保护下

• 如果黑客劫持了请求，并对请求中的参数进行了修改，签名就无法通过；
• 如果黑客使用已经劫持的URL进行DOS攻击，服务器则会因为缓存服务器中已经存在签名而拒绝服务，所以DOS攻击也是不可能的；
• 如果黑客隔一段时间进行一次DOS攻击（假如这个时间大于签名在缓存服务器中的缓存时长），则会因为时间戳超时而无法完成请求，这就是为什么签名的缓存时长要跟时间戳的超时时长一样。