后端交互校验

交互校验经常使用参数：
(1) Authorization/session_id

        用户认证参数。
(2) 客户端签名 Signture

        签名的功能是校验服务端收到的请求来自于对应的客户端，确保对不是对应客户端发起的请求不予响应。其中常见的签名方法有ASE加密解密，比对信息摘要等。最简单的方式好比将一个随机值+时间戳+约定值进行组合顺序的MD5加密，而后在服务器收到该请求时生成新的签名进行比对，若签名一致则响应该请求，不然不予响应。其中signture能够这样生成：

        signture = md5（随机值 + 时间戳timestamp + 约定值）

 

常见问题举例：

(1) 重放攻击

    典型的重放攻击是经过抓包客户端生成的签名不断地进行接口请求。如利用该签名不停地请求短信验证码接口，直到服务器的验证码余额耗光。

    防止重放攻击的最有效方式就是保持signture的惟一性。客户端必须生成惟一的signture，同时服务端也要保证对一个signture只响应一次请求。

    要确保signture的惟一性，能够在生成签名时采用时间戳timestamp这个参数的惟一性；同时为了确保服务端响应的惟一性，能够标记记录响应过的signture，再重复接收时不予响应。

    而在服务器端对signture作记录，通常能够采用 磁盘文件、数据库、缓存（Redis,Memcached等）记录。其中写进磁盘文件存在调用效率低，分布式系统不适用等弊端。若数据量较小时可采用缓存存储，若数据量较大可采起数据库存取（注意：需考虑请求数增长会加大数据库压力的问题）。

(2)  签名超时机制

    上述确保签名惟一性的方法，在记录的signture数量增长到必定数量后会效率很低。每次请求都须要去比对以前请求记录下的签名，明显是很不合理的。因此对于签名的记录，应当有必定的时效性，好比作一个数据库临时表，或者是redis缓存。在考虑时效性的同时，咱们还须要考虑到记录的签名到期后，会被攻击者继续利用失效签名进行重放攻击的风险。

    因此须要引入签名超时机制，当请求中的timestamp参数与当前服务端时间相隔大于signture的缓存时间，则不去响应该请求。通常超时时间须要知足：

    （服务端当前时间 - 客户端提交时间） < 超时时间 < signture缓存时间

(3)  超时机制下溢攻击

    按照上面超时机制的原理，对应的程序逻辑应该以下：

    if( (服务端时间 - 客户端时间) < 超时时间 ){

        //正确响应

    }else{

        //超时，不予响应

    }

    可是其中也须要考虑客户端提交时间远大于服务器时间的状况，及攻击者在signture失效后，采用超前的timestamp参数生成signture，进行重放攻击。其原理是服务端时间 - 客户端提交时间 = 负数 < 超时时间，从而绕过了超时机制，因此在计算服务端时间与客户端时间间隔时，须要额外判断其间隔为整数。

    固然，为了确保服务端与客户端时间的一致性，常常须要服务端提供查询时间接口，使得客户端提交的时间戳参数与服务端的时间一致。

 

以上是我在作后端交互时的一些总结，后续若遇到其余问题，会继续更新。

若其中有总结错误的地方，也请你们多多指教。