http安全篇
一、app与服务端交互确保来源的安全
作为一个移动互联网App，天生是需要和服务器通信的。那么，服务器如何识别客户端的身份？我们如何保证数据传输过程中的安全性？要靠两个东西：使用AppKey做身份识别，使用AppSecret校验数据。
这两个东西的定义可以参考淘宝开放平台上这种比较严肃的说法：
AppKey
客户端调用API时的唯一标识，服务器通过App Key来鉴别应用的身份。调用API接口时必须传入的参数。
App Secret
App Secret是服务端给客户端分配的密钥，用来保证应用来源的可靠性，防止请求数据被伪造。
其中，AppKey用来标识客户端的身份，通常保密性没有什么要求。就好比别人知道了我们的名字并不能假冒我们的身份一样。但AppSecret就不一样了。
先说一下App Secret的使用流程。
一个App请求中，通常包含AppKey、业务数据、时间戳等等。我们把这些信息定义为A、B、C。我们要把A、B、C这些信息发往服务器肯定不能直接扔过去，那么毫无安全性可言。通常的做法是把A、B、C和AppSecret（D）一起需要做一个校验，生成一个校验码（sign client），把校验码和A、B、C一起发送给服务器，服务器收到信息后，根据客户端发来的AppKey从数据库中检索对应的AppSecret，然后也同样把A、B、C和AppSecret（D）一起做一个校验，生成一个校验码（sign server）。如果sign client和sign server相同，就证明数据在传输过程中没有被修改过。
可以看出，整个过程中D（AppSecret）和校验过程是旁观者无法得知的。但是校验过程无非就那么几种算法，很好破解。所以说，AppSecret的保密工作就很重要了。
怎么做好AppSecret的保密工作呢？
写在代码里？Java很好编译呢。
做为资源文件？更二。
去服务器请求？请求过程会被劫持噢。
目前，最简单有效的办法还是打到.so库中。
二、登陆状态以及银行U盾原理
首先：登陆状态可以被劫持，就算用https传输，只能是确保账号密码不泄露，但是服务器返回的cookie还是会被劫持，从而劫持用户的登陆状态。
接下来我们看下支付的流程：
1、在支付的时候，首先服务器生成返回一个随机唯一的字符串gid
2、然后和请求的参数parm经过U盾公钥的加密，组成新的字符串sn（如果不加密，无法确保来源是本人操作）
3、连带请求参数parm一起发给服务器，服务器接收后，用gid和pram用私钥解密得到gn，然后用gn和sn匹配成功，则说明此请求是合法的。
4、服务器清除gid的合法性，防止重复提交。
郑重声明：本站内容如果来自互联网及其他传播媒体，其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享，并不代表本站赞同其观点和对其真实性负责，也不构成任何其他建议。
