APP开发实战9-API接口安全方案

3.2安全方案

3.2.1 HTTP命令的使用

APP和服务器交互通常是使用HTTP协议，常用的命令是GET和POST：

GET命令的参数暴露在发送给服务器的URL里，且通常服务器端对URL的长度有限制。

POST命令的参数在HTTP请求的BODY体里，比GET命令安全且数据长度没有限制。

从安全角度考虑，只要是带参数的请求，都应该使用POST命令。

APP向服务器发送的URL请求通常是如下格式：

http://+域名+/+模块名+/+方法名

比较极端的方法是把方法名也作为参数，传给服务器。

如http://www.test.com/customer/login中包含的方法名为login，对应的JSON数据如下：

{

"method":"login",

    "version":1.0,

        "params":{

            "username":"aaa",

            "password":"123456"

        }

}

在params中只包含此方法自身需要的参数。

3.2.2 使用时间戳参数

如果黑客截获了APP向服务器发送的请求，就可以向服务器反复发送某个请求，对服务器实施攻击，导致服务器瘫痪。

可以在APP向服务器发送的请求参数中，增加时间戳参数，如服务器发现这个时间戳与服务器当前时间间隔比较久，可判定此请求失效，不予处理，避免被恶意攻击。

如下所示是APP从服务器读取商品列表时发送的数据：

{

    "version":1.0,

    "timeStamp":1425065977,

    "authCode":"607a0aa16db850d06682d7711588ae46",

        "params":{

"categoryId":1,

            "offset":0,

            "limit":10

        }

}

timeStamp是APP发起此次请求的服务器当前时间，authCode是根据timeStamp的数值，按MD5算法或其它算法生成的验证码。timeStamp和authCode是一一对应的关系，如果timeStamp的值变了，则authCode的值也随之变动。

服务器端收到APP发的请求后，首先比较timeStamp的数值与服务器收到该请求的时间，当两者相差比较大(如相隔了60秒)，则可能是黑客发起的非正常请求，服务器对此请求不予处理；如两者相差在允许范围内，则验证用timeStamp的数值按APP端同样的算法，生成的字符串内容是否和APP发送的authCode内容一致。

使用此方法，需要APP端和服务器端的时间保持同步。APP在启动时，通过接口获取到服务器端的时间，和APP端的时间比较；如果不一致，APP端在计算"timeStamp"的数值时，需要把两者的差值也计算在内。

3.2.3数据加密

数据加密有如下几种方式：

A使用HTTPS对APP和服务器的交互数据加密。

B使用HTTP协议，自行设计用对称加密或非对称加密方式加密：

对称(AES和DES)

非对称(RSA和ECC)

对称加密是加密解密用同样的“钥匙”，非对称加密加密解密用不同的“钥匙”，建议采用更安全的非对称加密方式。

C使用HTTP协议，自行设计用MD5加密。许多APP的密码就是用MD5加密后，传给服务器的。

3.2.4密码的处理

APP向服务器发送密码的时候，应先对密码进行加密，然后再发送，之前已经提过需要对传输过程加密，这样相当于对密码进行了两次加密。

存储在APP端或服务器端的密码也都是要加密后再存储，不能存储明文。(最好不要在APP端存储密码，以防被破解)

3.2.5数据的存储

一些比较重要的数据，如支付宝和微信支付都会用到密钥文件，这类文件最好存储在服务器端，不要存储在APP端。