原创声明:本文为作者原创，未经允许不得转载，经授权转载需注明作者和出处
0：前情回顾
通过此文： 7：用户数据签名详解（加解密、签名系列）
可以知道：
wx.getUserInfo()返回的signature只能验证“用户基本信息”数据完整性。
encryptedData与iv也需要单独的检验数据完整性
1：用户敏感信息加解密过程(简化版)
微信服务器：响应wx.getUserInfo()的过程：
1:通过AES-128-CBC、PKCS#7、密钥、初始向量，把“用户敏感信息明文”加密为密文(encryptedData)
2:把“密文encryptedData”，“初始向量iv“等用户信息发送到小程序*
小程序：获取用户敏感密文并发送到服务器
1：小程序调用wx.getUserInfo()接口，得到“密文encryptedData”，“初始向量iv“等用户信息
2：把数据发送给服务器
后台服务器：根据约定的AES算法，对“密文encryptedData”进行解密
1:通过AES-128-CBC、psck#7、密钥、初始向量，把密文encryptedData解密为“用户敏感信息明文”
此过程详情，请查看:
3：AES加密与Base64编码（加解密、签名系列）
2：分析解密后的用户敏感信息明文
.
由图可知，除了appid是双方可约定的，其他信息都是用户的个人信息（不同用户数据不同）
假如敏感信息中没有appid：
开发者解密后“用户敏感信息明文”后，用户不同信息不同，具有随机性。
假如黑客把encryptedData或iv修改后，因为解密后的数据的随机性，开发者无法知道数据的完整，是否被修改。
在用户敏感信息明文中加入appid后：
有了openid，开发者只需要比对解密后的“用户敏感信息明文”中的openid和小程序后台的openid是否一致即可。
如果黑客把encryptedData或iv修改后，解密后“明文信息”肯定和“用户敏感信息明文”相同，所以得到的openid自然也不同。
综上所述：
开发者只要校验“从密文解密后得到的appid”和自身appid是否一致，即可验证数据的完整性、安全性。
此外：
在用户敏感数据中的timestamp：
是微信服务器响应小程序调用wx.getUserInfo()，把敏感信息密文发送到小程序时的时间戳，用于自己服务器检验数据的时效性。
