九、應(yīng)用邏輯漏洞
作者：Peter Yaworski
譯者：飛龍
協(xié)議：CC BY-NC-SA 4.0
應(yīng)用邏輯漏洞不同于其他我們討論過的類型。雖然 HTML 注入、HTML 參數(shù)污染和 XSS 都涉及到提交一些類型的潛在惡意輸入，應(yīng)用落地及漏洞實際上涉及到操縱場景和利用 Web APP 代碼中的 Bug。
這一類型攻擊的一個值得注意的例子是 Egor Homakov 對 Github 的滲透，Github 使用 RoR 編寫。如果你不熟悉 Rails，他是一個非常流行的 Web 框架，在開發(fā) Web 站點時，它可以處理很多繁雜的東西。
在 2012 年 3 月，Egor 通知了 Rails 社區(qū)，通常，Rails 會接受所有提交給它的參數(shù)，并使用這些值來更新數(shù)據(jù)庫記錄（取決于開發(fā)者的實現(xiàn)。Rails 核心開發(fā)者的想法是，使用 Rails 的 Web 開發(fā)者應(yīng)該負責(zé)填補它們的安全間隙，并定義那個值能夠由用戶提交來更新記錄。這個行為已經(jīng)在社區(qū)內(nèi)人人皆知了，但是 Github 上的線程展示了很少的人能夠鑒別出來它帶來的風(fēng)險（https://github.com/rails/rails/issues/5228）。
當核心開發(fā)者不同意他的時候，Egor 繼續(xù)利用 Github 上的認證漏洞，通過猜測和提交參數(shù)值，它包含創(chuàng)建日期（如果你熟悉 Rails 并且知道多數(shù)數(shù)據(jù)庫記錄包含創(chuàng)建和更新日期列，它就不太困難）。因此，它在 Github 上穿件了一個票據(jù)，日期的年份是未來。它也設(shè)法更新 SHH 訪問密鑰，這可以使他訪問 Github 官方的代碼倉庫。
之前提到了，這個滲透通過 Github 后端代碼實現(xiàn)，它并沒有合理驗證 Egor 所做的事情，這在隨后可用于更新數(shù)據(jù)庫記錄。這里，Egor 發(fā)現(xiàn)了叫做大量賦值漏洞的東西。
應(yīng)用邏輯漏洞，即發(fā)現(xiàn)前面討論的這種類型的攻擊，更加有技巧性，因為它們依賴代碼判定的創(chuàng)造丁思渭，并且并不僅僅是提交潛在的惡意代碼，開發(fā)者沒有轉(zhuǎn)義它。（不要嘗試在這里簡化其它類型的漏洞，一些 XSS 攻擊也很復(fù)雜?。?/p>
使用 Github 的例子，Egor 知道了系統(tǒng)基于 Rails 以及 Rails 如何處理用戶輸入。在其他例子中，它涉及直接編程調(diào)用 API 來測試應(yīng)用的行為，就像 Shopify 的管理員權(quán)限繞過那樣?；蛘撸婕爸貜?fù)使用來自驗證 API 調(diào)用的返回值，來進行后續(xù)的API 調(diào)用，本不應(yīng)該允許你這么做。
示例
1. Shopify 管理員權(quán)限繞過
難度：低
URL：shop.myshopify.com/admin/mobile_devices.json
報告鏈接：https://hackerone.com/reports/100938
報告日期：2015.11.22
獎金：$500
描述：
Shopify 是一個巨大并健壯的平臺，它包含 Web UI 以及受支持的 API。這個例子中，API 不驗證一些權(quán)限，而 Web UI 明顯會這么做。因此，商店的管理員，它們不被允許接受郵件提醒，可以通過操作 API 終端來繞過這個安全設(shè)置，在它們的 Apple 設(shè)備中收到提醒。
根據(jù)報告，黑客只需要：
- 使用完全訪問權(quán)限的賬號登錄 Shopify 移動應(yīng)用
- 攔截
POST /admin/mobile_devices.json的請求 - 移除該賬號的所有權(quán)限
- 移除添加的移動端提醒
- 重放
POST /admin/mobile_devices.json的請求
這樣做之后，用戶可以接收到所有商店處的訂單的移動端提醒，因此忽略了商店配置的安全設(shè)置。
重要結(jié)論
這里有兩個重要結(jié)論。首先，并不是所有東西都涉及代碼注入。始終記住使用代碼并觀察向站點傳遞了什么信息，并玩玩它看看什么會發(fā)生。這里，所有發(fā)生的事情是，移除 POST 參數(shù)來繞過安全檢查。其次，再說一遍，不是所有攻擊都基于 HTML 頁面。API 終端始終是一個潛在的漏洞區(qū)域，所以確保你考慮并測試了它們。
2. 星巴克競態(tài)條件
難度：中
URL：Starbucks.com
報告鏈接：http://sakurity.com/blog/2015/05/21/starbucks.html
報告日期：2015.5.21
獎金：無
描述：
如果你不熟悉競態(tài)條件，本質(zhì)上它是兩個潛在的進程彼此競爭來完成任務(wù)，基于一個廚師場景，它在請求被執(zhí)行期間變得無效。換句話說，這是一個場景，其中你擁有兩個進程，它們本應(yīng)該是互斥的，不應(yīng)該同時完成，但是因為它們幾乎同時執(zhí)行，它們被允許這么做了。
這里是一個例子：
你在手機上登錄進了你的銀行站點，并請求將 $500 從你的一個僅僅擁有 $500 的賬戶轉(zhuǎn)到另一個賬戶。
這個請求花費很長時間（但是仍然處理），所以你在你的筆記本上登錄，并且再次執(zhí)行了相同請求。
筆記本的請求幾乎立即完成了，但是你的手機也是這樣。
你刷新了銀行賬戶，并發(fā)現(xiàn)你的賬戶里有 $1000。這意味著請求執(zhí)行了兩次，這本不應(yīng)被允許，因為你一開始只擁有 $500。
雖然這個很基礎(chǔ)，理念都是一樣的，一些條件存在于請求開始，在完成時，并不存在了。
所以，回到這個例子，Egor 測試了從一個星巴克的卡中轉(zhuǎn)賬，并且發(fā)現(xiàn)他成功觸發(fā)了競態(tài)條件。請求使用 CURL 程序幾乎同時創(chuàng)建。
重要結(jié)論
競態(tài)條件 是個有趣的攻擊向量，它有時存在于應(yīng)用處理一些類型的余額的地方，例如金額、積分，以及其他。發(fā)現(xiàn)這些漏洞并不總是發(fā)生在第一次嘗試的時候，并且可能需要執(zhí)行多次重復(fù)同時的請求。這里，Egor 在成功之前執(zhí)行了 6 次請求。但是要記住在測試它的時候，要注意流量負荷，避免使用連續(xù)的測試請求危害到站點。
3. Binary.com 權(quán)限提升
難度：低
URL：binary.com
報告鏈接：https://hackerone.com/reports/98247
報告日期：2015.11.14
獎金：$300
描述：
這真是一個直接的漏洞，不需要過多解析。
本質(zhì)上，在這個場景下，用戶能夠登錄任何賬戶，代表被黑的用戶賬戶，并查看敏感信息，或執(zhí)行操作，并且一切只需要知道用戶的 UID。
在你滲透之前，如果你登錄了Binary.com/cashier，并查看了頁面的 HTML，你會注意到有個<iframe>標簽包含 PIN 參數(shù)。這個參數(shù)實際上就是你的賬戶 ID。
下面，如果你編輯了 HTML，并且插入了另一個 PIN，站點就會自動在新賬戶上執(zhí)行操作，而不驗證密碼或者任何其他憑據(jù)。換句話說，站點會將你看做你所提供的賬戶的擁有者。
同樣，所需的一切就是知道某人的賬戶號碼。你甚至可以在出現(xiàn)在iframe中的時間修改為PAYOUT，來觸發(fā)另一個賬戶的付款操作。但是，Bianry.com表示，所有取款都需要手動人工復(fù)查，但是這并不是說，這就一定會被發(fā)現(xiàn)。
重要結(jié)論
如果你尋找機遇漏洞的驗證，要留意憑據(jù)傳遞給站點的地方。雖然這個漏洞通過查看頁面源碼來實現(xiàn)，你也可以在使用代理攔截器的時候，留意傳遞的信息。
如果你的確發(fā)現(xiàn)了被傳遞的一些類型的憑據(jù)，但他們看起來沒有加密時，要注意了，并且嘗試玩玩它們。這里，PIN 是
CRXXXXXX而密碼是0e552ae717a1d08cb134f132。顯然 PIN 沒有解密，但是密碼加密了。未加密的值是一個非常好的地方，你可以從這里下手。
