百度安全实验室：支付安全不能说的那些事儿

对消息进行签名的过程和基于MD5的过程类似，也是首先将请求按key-value对排序，再使用RSA-SHA1算法（先SHA1再变形再RSA）和对方的RSA公钥生成签名，最后将签名附在原请求中形成完整的请求。 验签过程使用自己的RSA私钥进行验签，具体过程不表。

3、待签字符串的生成

以上两类签名机制均依赖于“待签字符串”的生成。在待签字符串的生成过程中有以下四个主要问题：

• 参数值为空的情况。在某些平台中，参数值为空的参数在待签字符串中被忽略。在某些平台中则不被忽略。
• 参数值的编码问题。在某些平台中，参数值编码后（编码方式也有不同）进入待签字符串。在某些平台中则在解码后进入待签字符串。
• 特殊字符问题。由于待签字符串使用&和=作为元字符，因此参数中存在的&和=等字符会影响待签字符串的结构。不同平台对特殊字符的处理也不同。
• 进入待签字符串的参数选择。某些平台中，所有参数均进入待签字符串中参与签名生成。而某些平台中只有指定参数才会进入待签字符串中参与运算。

待签字符串的种种性质导致了其“二义性”的出现。在某些情况下，同一个待签字符串可以等价于两个不同请求。例如这个待签字符串

a=A&b=B&c=C&d=D

可以由一个包含四个key-value对的原请求

{"a":"A", "b":"B", "c":"C", "d":"D"}

生成。在某些情况下，还可以由以下包含五个key-value对的原请求生成

{"a":"A", "b":"B", "c":"C", "d":"D", "junk":"JUNK"}

或者，在另一些情况下，可以由以下只包含三个key-value对的原请求生成

{"a":"A&b=B", "c":"C", "d":"D"}

这些变形依赖于“待签字符串”的生成方法。攻击者可以通过构造畸形请求来生成具有相同“待签字符串”的请求，从而绕过签名验证限制。

三、支付协议的安全漏洞

由以上分析，第三方支付过程的安全严重依赖于以下三点：

密钥的安全管理

支付平台签名算法的正确实现

商户对支付协议的正确使用

然而在生产环境中每个环节都有可能出错，引起严重的安全隐患。

1、密钥泄露

这是最常见的一种安全漏洞。密钥泄漏并不是一种罕见的情况，不少app在开发时，将密钥硬编码在app代码中（用于本地实现签名计算）。消息的完整性依赖于签名的计算，密钥泄漏后消息将无法保证未被篡改或伪造。但对称密钥和不对称密钥泄漏后的利用和危害有所区别。

图4展示了最常见的情况。MD5签名密钥编码在用户App中造成密钥泄露。在对相当多的app进行逆向工程后我们发现，有部分app直接照搬一些样例代码，导致key被直接明文编码到程序中，非常容易提取。还有一部分app作者使用了一些变形手段，例如将key拆成奇数位、偶数位分别存储，或使用特定常数进行异或存储。这些简单变形在熟练的攻击者面前是徒劳的。

由于商户和支付平台共享密钥，密钥泄漏后，攻击者既可以冒充商户向支付平台发送订单消息，又可以冒充支付平台向商户发送支付结果。当然，后者更加直接（如图4）。

例如，若攻击者准备购买一件商品，其订单消息为

notify_url=http://seller.com/notify&out_trade_no=12345&seller=alice&total_fee=100&sign=XXX,

攻击者可以首先通过修改notify_url到攻击者掌控的地址，如http://attacker.com/,提交请求:

notify_url=http://attacker.com/notify&out_trade_no=12345&seller=alice&total_fee=100&sign=XXX

来获得notify_url的结构。再伪造以下消息签名后发送给商户，伪造异步通知，实现免费购物。

target_url: http://seller.com/notify

post_data: put_trade_no=12345&seller=alice&total_fee=100&trade_status=SUCCESS&sign=XXX.

（编辑：西安站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!