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数据如下所示。

        {
          "version":1.0，
          "params":{
            "username":"aaa"，
            "password":"123456"
          }
        }

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

还有一种方案是把方法名也作为参数，传给服务器，对应的URL如下所示。

http://www.test.com/customer（此网址仅举例用，并非一个可以真正访问的网址。）

对应的JSON数据如下所示。

        {
          "method":"login"，
          "version":1.0，
          "params":{
            "username":"aaa"，
            "password":"123456"
          }
        }

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 数据加密

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

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

（2）使用HTTP协议，自行设计用对称加密或非对称加密方式加密。对称加密是加密、解密用同样的“钥匙”，非对称加密的加密、解密用不同的“钥匙”，建议采用更安全的非对称加密方式。

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

3.2.4 密码的处理

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

存储在用户终端设备或服务器中的密码也都是要加密后再存储，不能存储明文（最好不要在用户终端设备中存储密码，以防被盗取和破解）。

3.2.5 数据的存储

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