當(dāng)我在 Heroku 管理安全團隊時，我經(jīng)常做一個噩夢：

我的 PagerDuty 警報響了，提醒我發(fā)生了安全事故。在夢中，我盯著手機并意識到“不，大事不好”——接著，我就被驚醒了。

我仍然不確定夢中的安全事故到底是什么，但它很可能是 DoS 攻擊。雖然 DoS 攻擊簡單，但是它造成的影響卻可能是毀滅性的：攻擊者以超過服務(wù)器負載的方式向你的應(yīng)用程序發(fā)送流量。這雖然不像遠程代碼執(zhí)行或數(shù)據(jù)泄露那樣糟糕，但還是相當(dāng)可怕。如果客戶不能使用你的應(yīng)用程序，你就會失去他們的信任，損失金錢。

通常，我們討論兩種類型的 DoS 攻擊：

• “一般的”DoS 攻擊，即單臺機器就足以導(dǎo)致宕機。這種攻擊的一個經(jīng)典老派的版本是 zip 炸彈：攻擊者誘使你的服務(wù)器打開一個精心編制的 ZIP 文件，這個文件被壓縮得很小，但是解壓后，它卻會把你的整個磁盤空間給塞滿。
• DDoS（分布式拒絕服務(wù)）攻擊。這種攻擊需要攻擊者從多臺機器向你的站點發(fā)送超大流量。通常，這些攻擊來自僵尸網(wǎng)絡(luò)——被攻擊者控制的大量機器。這些僵尸網(wǎng)絡(luò)可以從互聯(lián)網(wǎng)的特定角落購買，讓任何一個有信用卡的人都能進行一次不錯的 DDoS 攻擊。

從事 Web 應(yīng)用程序工作的工程師經(jīng)常會遇到可用于 DoS/DDoS 攻擊的漏洞。

不幸的是，業(yè)界對于如何處理這些漏洞存在廣泛分歧。這種風(fēng)險很難分析：我曾見過開發(fā)團隊為如何處理一個 DoS 問題爭論了好幾個星期。

本文將試圖理清這些分歧，為工程和應(yīng)用程序安全團隊提供了一個框架來考慮 DoS 風(fēng)險，將 DoS 漏洞分為高、中、低三級，并在每一級提出了緩解措施的建議。這篇文章的主要關(guān)注點是大局，應(yīng)該適用于任何類型的 Web 應(yīng)用程序。但為了具體化，我加入了一些 Django 相關(guān)的具體示例。（我創(chuàng)建了這個框架，因此我對它非常熟悉。）

評估 DoS 風(fēng)險

在應(yīng)用層評估 DoS 漏洞的風(fēng)險可能很難。安全專家間存在著廣泛分歧：你經(jīng)常會看到 2 個不同的應(yīng)用程序安全團隊對相似問題的處理方式是截然不同的。

有人認(rèn)為：要完全抵御集中式 DDoS 攻擊，這幾乎是不可能的——一個足夠?qū)Ｗ⒌墓粽呖梢韵蚰阃斗疟饶愕膽?yīng)用程序能處理的更多的帶寬。如果沒有上游網(wǎng)絡(luò)提供商（例如 Cloudflare）提供用來防護機器人程序攻擊的特定工具，你永遠無法完全緩解 DDoS 攻擊。

因此，追蹤和修復(fù)假設(shè)的 DoS 漏洞似乎是在浪費開發(fā)人員的時間。這些團隊將大部分潛在的 DoS 問題視為可接受的風(fēng)險，并將精力集中在準(zhǔn)備網(wǎng)絡(luò)級別的緩解措施上。

另外一些團隊指出，傳統(tǒng)風(fēng)險模型有三個潛在問題：機密性、完整性和可用性。我們都知道，正常運行時間是一個安全問題。越來越普遍的情況是，攻擊者關(guān)閉服務(wù)，然后要求贖金來停止攻擊。最近針對Garmin 的攻擊是一個非常明顯的例子；攻擊者幾乎關(guān)閉了Garmin 的所有服務(wù)，據(jù)報道要求100 萬美元的贖金。（在這個例子中，攻擊是勒索軟件，但很容易看出DoS 攻擊也會有類似的效果）。因此，DoS 漏洞和其它任何漏洞一樣都是風(fēng)險，它們都應(yīng)該被緩解。

重要的是，這兩個立場都是合理的！將DoS 視為超出應(yīng)用程序安全范圍是合理的；同樣，將其納入范圍也是合理的。我經(jīng)常看到安全團隊在這兩個立場間爭論不休。如果確定不了對錯，就不可能找出解決的辦法。

攻擊者杠桿理論

對于這個爭論，我采用的是攻擊者杠桿理念。杠桿會放大力量：在杠桿長的一端施加很小的力量，就會在短的一端被放大數(shù)倍。具體到DoS 攻擊，如果一個漏洞有高杠桿率，這意味著攻擊者只需要很少的資源就能消耗你的大量服務(wù)器資源。

例如，如果你的Web 應(yīng)用程序的一個bug 允許單個 GET請求消耗 100% 的 CPU，那么這就是一個非常高的杠桿率。只需要少量攻擊，你的 Web 服務(wù)器就會陷入癱瘓。另一方面，一個低杠桿率的漏洞需要花費攻擊者的大量資源，最后才會讓可用性降低一點點。如果一個攻擊者必須花費數(shù)千美元才能讓一臺服務(wù)器癱瘓，那么你能比他們更快地進行擴展。

杠桿率越高，風(fēng)險越高，我就越有可能直接解決這個問題。杠桿率越低，我就越有可能接受這個風(fēng)險或者依賴網(wǎng)絡(luò)級別的緩解措施。

當(dāng)然，具體問題需要具體分析。根據(jù)杠桿率，我將 DoS 風(fēng)險分為高、中、低三個風(fēng)險級別。對每個風(fēng)險級別，我將分析如何識別漏洞屬于哪個級別，討論一些示例，并給出一些緩解建議。

高杠桿率 DoS 漏洞：容易放大的資源匱乏

典型的高風(fēng)險 DoS 漏洞是那些攻擊者本身只需要很少資源就能造成資源匱乏的漏洞。這可能意味著耗盡任何類型的資源，包括：

• 磁盤空間——例如，一個漏洞放大上傳數(shù)據(jù)并塞滿磁盤，比如典型的 zip 炸彈。
• 網(wǎng)絡(luò)帶寬——例如，一個漏洞放大輸入流量，而單個輸入請求會消耗大量帶寬，導(dǎo)致網(wǎng)絡(luò)堵塞。我在微服務(wù)系統(tǒng)中看到過這樣的 bug，單個輸入請求觸發(fā)大量的內(nèi)部 API 請求（包括在網(wǎng)絡(luò)上傳送相當(dāng)大的文件），并阻塞了內(nèi)部網(wǎng)絡(luò)帶寬。
• CPU 占用——例如，一個漏洞觸發(fā)了一個 accidentally quadratic 算法，導(dǎo)致 Web 服務(wù)陷入癱瘓。
• 并發(fā)限制——大部分服務(wù)器都有一個最大并發(fā)量限制（例如最大線程數(shù)或最大進程數(shù)，或數(shù)據(jù)庫最大連接數(shù)）；一個漏洞導(dǎo)致進程運行非常慢（甚至永不退出），則會導(dǎo)致服務(wù)器達到這些限制并開始拒絕請求。

在所有這些情況中，共同因素是應(yīng)用程序的一個 bug 會導(dǎo)致顯著的放大效應(yīng)。

身份認(rèn)證影響風(fēng)險

當(dāng)考慮資源放大 DoS 問題的風(fēng)險時，一個重要因素是觸發(fā)該漏洞所需的身份認(rèn)證級別。

如果一個完全匿名的用戶就能輕易觸發(fā)一個資源匱乏攻擊，那么攻擊者就很容易利用這個漏洞讓你崩潰。無需身份認(rèn)證的 DoS 問題應(yīng)該被視為高風(fēng)險。

另一方面，如果只有經(jīng)過你公司單點登錄服務(wù)器驗證過的用戶才能觸發(fā)該漏洞，那么，這就是一個非常低的風(fēng)險。大部分攻擊者不是內(nèi)部人員（盡管有些是！）。而且，如果攻擊者出現(xiàn)，很容易確定和阻止。

在大多數(shù)情況下，“我們可以確定并阻止攻擊”是一種合理的，盡管不完備的緩解策略。大多數(shù)漏洞介于這兩個極端之間：大多數(shù)服務(wù)讓創(chuàng)建新賬戶非常簡單（例如，你只需要一個郵箱地址）。這確實賦予了一些能力來確定和阻止漏洞，但這往往是不夠的。

緩解建議：消除

一般來說，我建議將這類 DoS 漏洞——特別是無需身份驗證的漏洞——視為高風(fēng)險，并且予以消除。如果它被利用，這些漏洞就是災(zāi)難性的；它們能讓單個攻擊者就擊潰你的應(yīng)用程序。我會投入跟其它高風(fēng)險安全漏洞（例如 XSS 和 CSRF）一樣的精力來發(fā)現(xiàn)并消除這種 bug。

一個高杠桿率漏洞示例：ReDoS

最后一種資源匱乏的常見例子（并發(fā)量限制）是正則表達式拒絕服務(wù)（regular expression denial-of-service），又叫 ReDoS。當(dāng)特定類型的字符串會導(dǎo)致不恰當(dāng)構(gòu)建的正則表達式表現(xiàn)非常差時，ReDoS bug 就會發(fā)生。

不幸的是，這種漏洞在 Python 中很常見；內(nèi)置的正則表達式模塊 (re) 沒有針對這種漏洞的內(nèi)在保護（不像 re2 庫，Go 內(nèi)置的 regex 模塊，因此讓語言或多或少對這種攻擊免疫）。（Django 本身多年來也存在一些這種漏洞；例如， CVE-2019-14232 和 CVE-2019-14233 都是 ReDoS 漏洞。）在 Django，這些漏洞通常出現(xiàn)在兩個地方：基于正則表達式的 URL 解析和自定義驗證器，以及應(yīng)用程序使用正則表達式的其它地方。幸運的是，這種類型的漏洞很容易找到。請參閱以下 r2c 文章：

• Finding Python ReDoS bugs at scale using Dlint and r2c
• Improving ReDoS detection and finding more bugs using Dlint and r2c

如果你用 Python，你可以在應(yīng)用程序中使用 Semgrep 掃描 ReDoS，這個庫從 Dlint 移植了 ReDoS 檢測功能。檢測需要一些使用 Semgrep 強大的 pattern-where-python 子句編寫的額外邏輯，這些子句讓規(guī)則能充分利用 Python 的全部功能，因此你必須使用--dangerously-allow-arbitrary-code-execution-from-rules 標(biāo)志。

復(fù)制代碼

$ semgrep --config https://semgrep.dev/r/contrib.dlint.redos           --dangerously-allow-arbitrary-code-execution-from-rules

中杠桿率 DoS 風(fēng)險：復(fù)雜的資源匱乏

稍微深入研究風(fēng)險案例，我們發(fā)現(xiàn)資源匱乏的一個不同類型：你的應(yīng)用程序本身就比較慢或者資源比較緊張。例如：

• 復(fù)雜的報告，需要讀取或計算大量數(shù)據(jù)。考慮一下，在一個很長的時間內(nèi)對聚集指標(biāo)的實時報告，或者一份匯總數(shù)百萬筆交易的季度財務(wù)報告。
• 數(shù)據(jù)庫或搜索引擎寫入，這需要高價的重新索引。典型的 Web 應(yīng)用程序是以寫入速度慢為代價來實現(xiàn)讀取速度快的設(shè)計的。這對于分布式數(shù)據(jù)庫的一致性寫入尤其如此（ CAP 定理！）
• 類似 GraphQL 的 API，能生成任意深度的數(shù)據(jù)庫表連接。這是一個超出這里深度的話題；如果想了解更多，請參閱 Apollo 團隊的 Securing Your GraphQL API from Malicious Queries 。

如果一個攻擊者發(fā)現(xiàn)一個比正常速度慢得多的區(qū)域，就可以向該端點發(fā)送垃圾信息，造成與上述類似的資源耗盡。但是，這些通常并不是 bug；它們只是應(yīng)用程序的特性。有些特性總是比較慢或占用資源比較多；對某些事情很少有“修復(fù)”方法，只是需要一些時間。有時，性能優(yōu)化可以降低風(fēng)險，但是那通常需要大量的投資或不可接受的權(quán)衡（例如放棄一致性寫入）。

然而，還是有一些緩解因素可以降低這類問題的風(fēng)險：

• 這種端點通常都在一些身份驗證或登錄驗證后。例如，GraphQL API 需要一個 API key；財務(wù)報告只開放給有特殊權(quán)限的用戶；數(shù)據(jù)庫寫入只會被已經(jīng)登錄的用戶觸發(fā)。這能降低上述風(fēng)險。
• 這種特性通常比高杠桿率等級的風(fēng)險需要更多的攻擊流量來擊垮。例如，雖然在典型的應(yīng)用程序中寫入比讀取慢，但是也不是那么慢；一個調(diào)優(yōu)得比較好的數(shù)據(jù)庫能處理每秒上千次寫入。因此，攻擊者必須更費力地投入更多資源來造成資源匱乏。

綜上所述，我認(rèn)為這意味著將這種類別的潛在漏洞視為可接受的風(fēng)險是更為合理的。“我們將屏蔽試圖讓我們崩潰的 API key”似乎是一個合理決定。

緩解建議措施：速率限制

換言之，有一個常見架構(gòu)上的緩解措施值得考慮：速率限制。速率限制對某個特定端點在一段時間窗口內(nèi)設(shè)置了請求數(shù)量的閾值。速率限制很容易搭建和應(yīng)用，通常是一個簡單的正向工程實踐。只要你設(shè)置的限制足夠高，不妨礙正常使用，它們就可以防止一系列問題，包括 DoS。

在 Django 中， django-ratelimit 提供了一個簡單的基于裝飾器的 API，使得為視圖增加速率限制非常容易：

復(fù)制代碼

from ratelimit.decorators import ratelimit @ratelimit(key='user’, rate=’10/s’)def my_view(request):    …

或者，如果你在使用 Django REST 框架，它可以通過一系列配置實現(xiàn)內(nèi)置的速率限制。對一些應(yīng)用程序來說，廣泛應(yīng)用速率限制是很好的辦法——甚至可以在每個視圖上應(yīng)用速率限制。在那些例子中，你可以用Semgrep 來發(fā)現(xiàn)并警告未被裝飾的視圖。

下面是一個例子，Semgrep 配置可以發(fā)現(xiàn)沒有被 @ratelimit裝飾器裝飾的視圖：

復(fù)制代碼

rules:- id: my_pattern_id patterns: - pattern-either: - pattern: | def $FUNC(..., request, ...): ... - pattern-not: | @ratelimit.decorators.ratelimit(...) def $FUNC(..., request, ...): ... message: | This view Appears not to have a rate limit applied. Consider applying one with the @ratelimit decorator. fix: | severity: WARNING

你可能想針對你的具體應(yīng)用程序修改規(guī)則集；這只是個起點。迭代開發(fā)一個定制規(guī)則集的一個好方法是從這個規(guī)則集開始在 Semgrep 的交互實驗室進行迭代。

低杠桿率 DoS 風(fēng)險：DDoS

最后，我們討論最后一種 DoS 攻擊：真正的 DDoS 攻擊，即一個攻擊者指揮大量計算機向你的應(yīng)用程序發(fā)送大量流量。這些流量通常不是針對具體應(yīng)用程序的；它通常是一些沒有意義的 TCP 或 UDP 包，設(shè)計用來使網(wǎng)絡(luò)本身崩潰。

一次 DDoS 攻擊的規(guī)模通常只受限于攻擊者的預(yù)算。這種類型的攻擊通常會使應(yīng)用程序安全工程師舉手投降——包括我自己！實在沒有什么措施可以用來緩解這種漏洞。在應(yīng)用程序級別肯定是沒有方法的。我比較同意，真正的 DDoS 攻擊是超出了應(yīng)用程序安全范疇的。

緩解建議：充分準(zhǔn)備和網(wǎng)絡(luò)級別的安全措施

那就是說，你可以在網(wǎng)絡(luò)層級做一些事情，主要是在準(zhǔn)備方面：

• 你應(yīng)該考慮將應(yīng)用程序放在可以防護DDoS 的 Cloudflare 之類的服務(wù)后面。你還能從 CloudFlare 之類的 CDN 獲得大量性能好處，因此，這通常是值得的。
• 你應(yīng)該理解網(wǎng)絡(luò)層級以及網(wǎng)絡(luò)規(guī)則可以應(yīng)用到哪個層級。許多 DDoS 攻擊是可以被識別的（通過 IP、源端口、流量類型或某種組合）。知道如何應(yīng)用網(wǎng)絡(luò)規(guī)則來阻止惡意流量有助于你快速對攻擊做出響應(yīng)。
• 除了自己控制的系統(tǒng)外，你應(yīng)該了解你的網(wǎng)絡(luò)供應(yīng)商是誰以及它們可以應(yīng)用哪些緩解措施。通常，你的網(wǎng)絡(luò)供應(yīng)商能比你更有效地阻攔這些攻擊。例如，如果你在 AWS 上托管主機，作為 AWS Shield Advanced 的一部分，你可以得到 AWS DDoS 響應(yīng)團隊 24x7 的支持。這個服務(wù)的起始價格是 36000 美元每年，這看起來可能貴的離奇或者超級便宜，一切取決于你的業(yè)務(wù)。

如果你想了解更多關(guān)于準(zhǔn)備和緩解 DDoS 攻擊的內(nèi)容，谷歌的 Building Secure and Reliable Systems 第 10 章是個不錯的起點。

結(jié)論

DoS 漏洞有各種各樣。其中，有一些應(yīng)該被提高優(yōu)先級并立即修復(fù)，但另外一些被視為“可接受的風(fēng)險”也算合理。畢竟，沒有一種方案可以適用于所有漏洞；你需要在找到合適的響應(yīng)前考慮漏洞的相對風(fēng)險。

我發(fā)現(xiàn)評估風(fēng)險的最佳框架是 amplification：考慮到需要多少攻擊流量來觸發(fā)某個等級的服務(wù)降級。如果幾個零散的請求就能讓你的服務(wù)器崩潰，那這是一個非常高的風(fēng)險，應(yīng)該被妥善處理。另一方面，如果非常多的流量只能導(dǎo)致適度的速度降低，那你將這個問題的優(yōu)先級排在其它問題之后也是合理的。

下次，你面對 DoS 問題的不確定時，可以試試這個框架。我希望它能避免那些令人沮喪的爭吵！

原文鏈接：

https://r2c.dev/blog/2020/understanding-and-preventing-dos-in-web-apps/