数据传输过程的安全考虑

1. 数据包启用Gip压缩(服务端下行),节省流量,一般浏览器或httplib支持decode.

 

2. AES加密解密 

 加密和解密使用同一个key, 双方都保留此key,准确的说需要key和vector(向量)

 

3. RSA

加密时用public key加密, 解密时用private key解密,密钥是成对的,这样加密方只需要对方的公钥加密,私钥在解密方这里(甲乙双方反过来一样看待),安全。密钥不可能同时存在一方。

key有1024或2048位,即便同一内容,两次加密结果可能不同,但不影响解密。 

 

original: c360.pay

aes: vbPaUC/FGy5m4rQ4HO5JUg==

rsa: tsrks2u9Nf5EgA0akKCPj5YK/h9R7lldPyOipozk/XlCpnjhRcjPeSeZfCrIR1WPaMfSRsjanqrmoA5PuTE92cUi1cAx6+UjsVr2BBZKVmIhl2uoLSuIIIDIxp+kAOQ0DYLFHW4QgHlwSjqJjDAeu55ASuXx5D/MjZy3zKOXWqc=

 

可见AES加密的内容比RSA小很多,但RSA应该更安全些。

 

4. API接口安全

要有验证,不能直接访问。

cookie或auth sig , 在head增加此参数,根据一定的规则生成,服务端验证,确保这个请求是合法的

 

**参数加签名** 

所有请求必需有appkey和timestamp 

appkey和appsecret是对应一组(由服务端生成),传输过程中使用appkey(服务端根据此识别客户端并找出appsecret值),签名时使用appsecret做hash。

时间戳由客户端带上来,服务端验证如果时差太大刚认为请求无效(重复请求或数据被篡改)

 

举例:

/api/resource?para1=xxx&para2=xxx

生成签名: hash(para1=xxx&para2=xxx&appkey=xxx&timestamp=148897123456)=fx51lkd8vjkxsksdlk  

注:生成签名的规则及内容自己根据实际情况决定

最终客户端发起的请求如下:

/api/resource?para1=xxx&para2=xxx&appkey=xxx&timestamp=148897123456&sign=fx51lkd8vjkxsksdlk  

服务端收到后检验

a. 检查timestamp值是否合理,如果差值太大,直接response error

b. 根据appkey找到appsecret,和客户端一样的逻辑做hash, 得到的签名和sign参数比较, 如不相等直接response error

posted @ 2016-03-24 12:14  chy710  阅读(181)  评论(0编辑  收藏