基于HTTP协议RestAPI通信安全机制

一、编写目的

1.该文档针对公司内部APP、JS与服务器端API数据传输而定，通信规范处理以下几个问题

1. 请求来源身份（授权APP，已登录用户）是否合法；

2. 请求参数被篡改；

3. 请求的唯一性(不可复制)，防止重放攻击。

二、原理概述

1.通过appkey参与每次http请求时做签名，服务端同时做签名验证，解决app请求身份来源的合法性。

2.通过appkey与提交的参数参与每次http请求时做签名，服务端同时做签名验证，解决请求参数被篡改的可能。

3.通过随机数与时间戳机制，来防止重放攻击。每次请求的随机数在相应的http请求验证周期（默认60秒）中的唯一性来验证，随机数存入服务器缓存中，缓存周期为http请求验证周期（默认60秒），是否过期使用时间戳验证。

三、主要实现

1. 客户端

1) 传输协议

通信协议采用https，即安全的http协议，数据在TCP/IP协议的传输层做加密，保证数据在传输层中的安全。

2) 数据格式

http使用POST方式发送，数据为Json-RPC格式，如

Reuset数据格式{"id":1,"method":"account_login","params":{ "参数名1" : "参数名1的值", "参数名2" : "参数名2的值"}}

method为调用服务端的方法，params为发送到服务器的参数

Response数据格式

{"id":1,"result":{"status":"success","data":{"属性名":"l属性值"}}}

status为服务器的返回状态，值有三种

success--请求成功，处理正确时返回

failed--请求失败，当参数传入不正确或错误时返回

error--请求错误，应用程序处理错误时返回

data为返回的数据，格式为json的对象。

3) 安全性

原理：客户端根据约定算法计算签名，服务端根据相同算法，做签名验证。

a. 验证APP合法性

客户端在每次发送http请求时，在http的headers 里加入timestamp，nonce，signature三个信息，其他数据作为json格式提交的POST数据传输。

appkey 为开发app前由服务端针对为每个应用app生成一个固定的appkey，这个appkey写入客户端安装包中，appkey用来做签名，用于每次请求验证app的合法性，还用于用户登录成功后使用DES（对称加密算法）加密token（token为用户登录成功后的返回给客户端的用户认证标识）的密钥。

timestamp为客户端时间戳（注：1970年到现在unix时间的秒数，不是毫秒）。

nonce为随机数：16位，字母与数字的组合，不区分大小写。

data为POST提交的数据，格式为Json对象格式{a:”xxx”,b:”xxx”},数据的参数字段名按照的ASCII 码从小到大排序（字典序），如果没有发送的参数时，data的值为空字符串，格式如data=””。

token为用户登录认证标识，在做app验证时需要加入签名，值为””字符串。

signature为签名，全小写：签名算法如下

参与签名的字段包括nonce（随机字符串） timestamp（时间戳）, appkey（appkey），token（空字符串）,data（POST传输的数据） 。对所有待签名参数按照字段名的ASCII 码从小到大排序（字典序）后，拼接成字符串string1。这里需要注意的是所有参数名均为小写字符。对string1作md5加密。

即signature=md5(string1)。 排序示例：

appkey=xxxxxx

data={a:”xxx”,b:”xxx”}

    nonce=Wm3WZYTPz0wzccnW

timestamp=1414587457

token=””

步骤1. 对所有待签名参数按照字段名的ASCII 码从小到大排序（字典序）后，拼接成字符串string1：

appkeyxxxxdata{a:”xxx”,b:”xxx”}nonceWm3WZYTPz0wzccnWtimestamp1414587457token

步骤2. 对string1进行md5签名，得到signature：

0f9de62fce790f9a083d5c99e95740ceb90c27ed

b. 验证用户认证

客户端在每次发送http请求时，在http的headers 里加入timestamp，nonce，signature三个信息，其他数据作为json格式提交的POST数据传输。

appkey 为开发app前由服务端针对为每个应用app生成一个固定的appkey，这个appkey写入客户端安装包中，appkey用来做签名，用于每次请求验证app的合法性，还用于用户登录成功后使用DES（对称加密算法）加密token的密钥。

token为用户第一次登录认证成功后服务器返回的登录标识，格式为guid，服务端DES加密，密文传输，客户端接收后DES解密，存放在客户端本地，用于当访问需要验证用户身份认证的接口时做签名。

uid为用户登录认证成功后服务器端返回给客户端的用户id（数据库用户表自增ID），与token一一对应，明文传输，uid为整型，必填。

timestamp为客户端时间戳（注：1970年到现在unix时间的秒数，不是毫秒）。

nonce为随机数：16位，字母与数字的组合，不区分大小写。

data为POST提交的数据，格式为Json对象格式{uid:1,b:”xxx”},数据的参数字段名按照的ASCII 码从小到大排序（字典序），此时data数据中必须包含uid字段。

signature为签名，全小写：签名算法如下

参与签名的字段包括nonce（随机字符串） timestamp（时间戳）, appkey（appkey），data（POST传输的数据），token（用户登录标识） 。对所有待签名参数按照字段名的ASCII 码从小到大排序（字典序）后，拼接成字符串string1。这里需要注意的是所有参数名均为小写字符。对string1作md5加密。

即signature=md5(string1)。 排序示例：

appkey=xxxxxx

data={uid:1,b:”xxx”}

    nonce=Wm3WZYTPz0wzccnW

timestamp=1414587457

token=xxxxx

步骤1. 对所有待签名参数按照字段名的ASCII 码从小到大排序（字典序）后，拼接成字符串string1：

appkeyxxxxdata{uid:1,b:”xxx”}nonceWm3WZYTPz0wzccnWtimestamp1414587457tokenxxxxx

步骤2. 对string1进行md5签名，得到signature：

0f9de62fce790f9a083d5c99e95740ceb90c27ed

2. 服务端

1) 传输协议

服务端通信协议采用https，即安全的http协议，数据在TCP/IP协议的传输层做加密，保证数据在传输层中的安全。在IIS开启使用https协议，在开启前，请到CA申请证书，在IIS配置https协议时使用该证书。

2) 数据格式

    服务端使用Maticsoft.Json.RPC.dll组建，搭建api，数据传输格式规范见客户端。

3) 安全性

    原理：客户端根据约定算法计算签名，服务端根据相同算法，做签名验证。

a. 验证APP合法性

服务端验证算法：

Ø 接收到客户端明文传输的时间戳，与当前服务器时间戳（unix时间）相减然后取绝对值，大于HTTP请求周期（默认60秒），则超时，验证失败。

Ø 接收到客户端明文传输的随机数，先到服务器缓存中查找该随机数是否存在，如果存在，则说明发送重复请求，验证失败，如果不存在，在存入缓存，缓存周期为HTTP请求周期（默认60秒）。

Ø 根据签名算法（见客户端）验证接收的客户端明文传输的签名值与服务端计算的签名值是否一致，不一致，验证失败，一致，验证成功。

b. 验证用户认证

Ø 接收到客户端明文传输的时间戳，与当前服务器时间戳（unix时间）相减然后取绝对值，大于HTTP请求周期（默认60秒），则超时，验证失败。

Ø 接收到客户端明文传输的随机数，先到服务器缓存中查找该随机数是否存在，如果存在，则说明发送重复请求，验证失败，如果不存在，在存入缓存，缓存周期为HTTP请求周期（默认60秒）。

Ø 当客户端调用用户登录接口登录验证成功后，服务端生成token，token包含有uid（数据库用户表自增ID），过期时间ExpireTime，token值SignToken，guid类型，先存入缓存，缓存过期时间默认一个月，然后当返回给客户端时DES密文加密传输返回给客户端。

Ø 当客户端访问需要用户验证的接口时，参数必须带有uid，明文传输，服务端接收到uid先到缓存中查找对应的token值，如果没有则用户登录过期，如果有，则取出，参与服务端签名验证。

Ø 根据签名算法（见客户端）验证接收的客户端明文传输的签名值与服务端计算的签名值是否一致，不一致，验证失败，一致，验证成功。

五、以上就是全部内容，如有疑问或发现bug请移步QQ群：855531299共同讨论学习；

源码地址：https://gitee.com/shangyakejiwenhua/sykj