zjuchenyuan
commented
6 years ago Security Rules:
1. 订单只能由商家服务器MS产生并签名
2. 绝对不能在APP(MA)中放置任何key
3. SDK必须给用户显示订单的详情
4. SDK必须验证订单是APP的（而不是攻击者中间人攻击提供的其他订单）
5. 客户端与服务器之间只使用安全通讯
6. 对于收到的信息的签名总是验证
7. 商家收到回调之后还需要主动发起一次查询确认订单的支付情况Four attacks:
- 篡改价格: 违背规则1和7，支付一个更低价格的订单来完成原订单
- 伪造的通知: 违背规则2和7，甚至6，不花钱也能完成订单
- 订单替换: 违背规则3,4,5，在中间人攻击下使其他人为我付钱
- 未授权的查询: 违背规则2，可以使用支付渠道商API查询敏感的交易信息
可以检测的缺陷
1. 本地产生订单 搜索本应该是服务器向渠道商提交订单的API地址
2. 泄露密钥 微信提供了API和明确的报错 可以判断32字节长的东西是不是正确的key；对于Alipay和Unipay则检查私钥（格式ASN1，证书包含ali/alipay，相同的类包含特定的字符串如”&service=mobile.securitypay.pay”）
3. 不完整的提示 检查TP-SDK是否显示了：1)订单号 2)正在购买的商品名称 3)购买者 4)提供商 5)总金额
4. 缺失交易检查 替换掉下发的订单/TN信息，看TP-SDK会不会接受不是当前MA的订单
5. 不安全的网络通讯 目前自动化检测的方法还不够准确，所以人工触发订单，难以大规模应用
6. 回调通知不进行额外验证 在泄露了密钥的基础上，提交订单 篡改订单但利用正确的签名进行回调通知 看是否确认这个订单（人工检查）
7. 不验证签名 在不支付订单的情况下 使用假的签名进行回调通知 这要在上述6的基础上（如果没能检测出这个问题可能是由于额外验证的存在
in order to achieve safe pay, please refer to this paper:
https://www.ndss-symposium.org/ndss2017/ndss-2017-programme/show-me-money-finding-flawed-implementations-third-party-app-payment-android-apps/
In this code,
verifyCallbackdoes not verify the amount data.