聽說拼多多因漏洞被薅了200億？- 談談軟體測試

摘要： 昨天看到一個大新聞：拼多多在20日凌晨出現漏洞，使用者可以領100元無門檻優惠券 。一夜之間，被黑產、羊毛黨和聞訊而來的吃瓜群眾薅了個底朝天，直到第二天上午9點才將優惠券下架。網上傳言這一波損失超過200億，但拼多多官方很快回應：漏洞確有此事，但損失沒這麼多，不到千萬，已報警...

昨天看到一個大新聞：拼多多在20日凌晨出現漏洞，使用者可以領100元無門檻優惠券 。一夜之間，被黑產、羊毛黨和聞訊而來的吃瓜群眾薅了個底朝天，直到第二天上午9點才將優惠券下架。網上傳言這一波損失超過200億，但拼多多官方很快回應：漏洞確有此事，但損失沒這麼多，不到千萬，已報警，正在追回 。

拼多多本來就是家爭議頗大的公司，這次事件更是引發輿論熱議。據說，這個優惠券本不能正常訪問，而是有做黑產（利用網際網路不正當牟利）的人挖到了一個漏洞，使得能從某個二維碼入口領取到這個券，並把這個券散發出去。你別以為這是想劫富濟貧，他們只是想拉足夠的炮灰墊背 ，同時自己迅速將這個券兌換成話費、Q幣等，以此獲利。這事情從法律角度來說算得上“不當得利 ”，就算涉事賬面金額真的有200億，大部分也是可以追回的。所以，沒吃到瓜的群眾別懊悔，反倒是真佔了便宜的，得考慮考慮了。

話說回來，可能有人要問了，怎麼黑產就能弄出一個不存在的優惠券？我不瞭解具體漏洞細節，但從目前的資訊來看，這個券在系統裡肯定確實存在，有可能是內部測試或者某些特定條件下可以領。然而估計程式上並沒有做更多的領取條件限制，只是隱藏了訪問這個券的公開入口 。就好比是有人在銀行的某個保險櫃裡放了一筆錢，但沒有上鎖，覺得別人不知道這裡藏了錢就沒事。後來有人發現了，就把保險櫃的位置告訴了所有人，那麼每個人都可以過來拿錢。

講道理，我沒上鎖也不代表你就能隨便拿。但從一個開發者的角度來看，不做必要的許可權驗證、規則判斷，以及特殊情況下的異常處理，僅僅通過隱藏公開入口來限制領取，這是極為低階的失誤 。讓人忍不住想吐槽：拼多多那麼有錢，招來的程式設計師咋這麼不專業？而且為什麼凌晨爆發的問題，到上午9點才封上，下架個優惠券也這麼難嗎？

不過吐槽歸吐槽，不可否認的是，軟體的 bug、缺陷、漏洞，這是永遠不可能杜絕的 。被人們看到的漏洞往往很低階，但考慮到軟體產品的複雜度，以及開發進度、需求變更等客觀情況，漏洞也並不是想象中那麼容易避免。就在半個月前，知名民宿平臺 Airbnb 就爆出過類似的大 bug：當你支付房費的時候，如果切換貨幣，價格並沒有跟著變 。你可以拿2000越南盾支付原價2000歐元的民宿。在計算機史上，類似的問題數不勝數，舉幾個知名例子：

• 1994年，英特爾的奔騰CPU晶片被曝出缺陷：會在精度要求很高的數學計算上出現問題 ，比如 (4195835/3145727)*3145727-4195835 這樣的結果計算出來不為 0。最後英特爾為此付出4 億多美元更換晶片 。就在大約一年前，英特爾的另一個晶片漏洞也波及了市面上絕大多數的電腦、手機和雲伺服器，這個我去年有文章科普過：關於這波IntelCPU漏洞，我見過最形象易懂的解釋
• 1999年，美國航天局的火星極地登陸器在著陸時失聯 。後經調查認定，故障原因很可能是一個決定關閉推進器的資料位設定邏輯有誤 。
• 1991年海灣戰爭中，美國的愛國者導彈防禦系統失效 ，未能成功攔截導彈致28名美軍士兵被炸死 。原因經分析後，是因為系統時鐘資料精度不夠 ，存在微小誤差，長時間執行後誤差積累放大，在攔截過程中可能引起數百米的偏差。
• 千年蟲問題 ：上世紀早期的軟體開發者為了節省空間，使用兩位數記錄年份 。然而到2000年時，一些軟體仍在使用，使得99年之後變成00年，引發異常。有人估計全球為此花費的相關費用有數億美元 。

由此看來，程式設計師還真是一個高危職業，一不小心就可能造成巨大損失。如果你沒有生產過嚴重的 bug，可能是你運氣真的好，但更可能是你程式碼寫得還不夠多。 對此我自己也是不少血淚教訓。那面對難以避免的 bug，開發者應該怎麼辦呢？我的建議：

1、重視軟體測試

正因為漏洞的普遍存在，以及可能帶來的潛在損失，所以軟體測試是即為必要的。除了需要有專門的測試人員把關，每個合格的開發者也應該是一個合格的測試者，正如有句話說的：一個優秀的程式設計師就是那種即使是過單行道都要往兩邊看的人 （Doug Linder）。對於自己寫出的程式碼，你自己是最瞭解的人。在開發早期就做好單元測試 ，可以大大提升程式的穩定性，降低後期測試的成本。當你寫的每個函式都通過單元測試，成為一個功能模組時，再進行整合測試 ；最後對整個完成的產品進行系統測試 。

企業更是應當重視軟體測試的必要性，如果只追求功能快速迭代，拼命趕進度，最後有可能得不償失。因為 bug 或操作失誤導致企業破產的例子也不鮮見。

測試的方式一般分為黑盒測試 和白盒測試 。上面說的開發者自測一般是白盒測試，即你對程式碼的實現邏輯是已知的。白盒測試在選取測試用例時，講究對程式碼邏輯的覆蓋 ，即你選用的測試資料要能保證讓每一行程式碼每一個條件都被執行到，尤其是一些邊界條件 。而黑盒測試是指不考慮程式碼邏輯，僅關注程式的功能和輸入輸出。軟體釋出測試版讓使用者使用，就屬於一種黑盒測試。在黑盒測試時，講究對等價類的覆蓋 ，通俗地講就是覆蓋到所有可能發生的情況，包括正常的和不正常的，同樣要注意邊界。

我們碼上行動 有個期中專案，就是對教程中“猜數字”遊戲的擴充套件，增加多次遊戲的功能。看似簡單的功能，實現起來不難，但幾乎大部分同學提交的程式碼都會存在一定的缺陷。這就是由於程式設計新手缺乏測試的意識和方法，一般只會按照自己的設想輸入，發現結果對了就認為大功告成。其實不然，你得考慮使用者如果猜的數字超過範圍怎麼辦？輸入了小數怎麼辦？輸入空白怎麼辦？輸入了字元怎麼辦？……

那測試做到什麼程度才到位？我覺得知乎上有人分享的一個笑話很到位：

更多關於測試的知識，歡迎大家找本《軟體測試 》相關書籍看一看，這個真的很有必要。

2、相信墨菲定律

墨菲定律：如果你擔心某種情況發生，那麼它就更有可能發生。

測試做得再好，也只能是減小 bug 的概率。作為一個開發者，你還是要認清現實，做好最壞的打算。

• 如果你要上線新功能，那很可能導致宕機
• 如果你要更新資料庫，那很可能會丟失資料
• 如果你沒有檢查備份，那很可能它就恢復不了
• 如果你搞一個促銷活動，那很可能會被羊毛黨擼死
• 如果系統出現了漏洞，那很可能是在半夜
• ……

但真當你意識到這些絕望的時候，反倒可以提前做好應急預案，將損失限制在最小。如果拼多多在設定出100元無門檻券的時候就相當虎視眈眈的黑產羊毛黨，可能事情就不會這樣。不過也許現在就是他們的應急預案也說不定呢：控制損失的同時還賺了一大波曝光。世事難料啊！

換個角度，能造成巨大損失也是一種幸運。相比之下，你的產品掛了兩天都沒人發現，域名過期了都沒人跟你搶，那才叫悲慘。所以最後，希望各位有朝一日都能參與影響巨大的專案 ，但要有安全意識，千萬別捅出大簍子

════