當(dāng)我在 Heroku 管理安全團(tuán)隊(duì)時(shí)，我經(jīng)常做一個(gè)噩夢(mèng)：

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

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

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

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

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

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

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

評(píng)估 DoS 風(fēng)險(xiǎn)

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

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

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

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

重要的是，這兩個(gè)立場(chǎng)都是合理的！將DoS 視為超出應(yīng)用程序安全范圍是合理的；同樣，將其納入范圍也是合理的。我經(jīng)?？吹桨踩珗F(tuán)隊(duì)在這兩個(gè)立場(chǎng)間爭(zhēng)論不休。如果確定不了對(duì)錯(cuò)，就不可能找出解決的辦法。

攻擊者杠桿理論

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

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

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

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

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

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

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

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

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

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

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

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

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

緩解建議：消除

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

一個(gè)高杠桿率漏洞示例：ReDoS

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

不幸的是，這種漏洞在 Python 中很常見；內(nèi)置的正則表達(dá)式模塊 (re) 沒有針對(duì)這種漏洞的內(nèi)在保護(hù)（不像 re2 庫(kù)，Go 內(nèi)置的 regex 模塊，因此讓語(yǔ)言或多或少對(duì)這種攻擊免疫）。（Django 本身多年來(lái)也存在一些這種漏洞；例如， CVE-2019-14232 和 CVE-2019-14233 都是 ReDoS 漏洞。）在 Django，這些漏洞通常出現(xiàn)在兩個(gè)地方：基于正則表達(dá)式的 URL 解析和自定義驗(yàn)證器，以及應(yīng)用程序使用正則表達(dá)式的其它地方。幸運(yùn)的是，這種類型的漏洞很容易找到。請(qǐ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，這個(gè)庫(kù)從 Dlint 移植了 ReDoS 檢測(cè)功能。檢測(cè)需要一些使用 Semgrep 強(qiáng)大的 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)險(xiǎn)：復(fù)雜的資源匱乏

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

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

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

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

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

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

緩解建議措施：速率限制

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

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

復(fù)制代碼

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

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

下面是一個(gè)例子，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

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

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

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

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

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

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

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

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

結(jié)論

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

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

下次，你面對(duì) DoS 問題的不確定時(shí)，可以試試這個(gè)框架。我希望它能避免那些令人沮喪的爭(zhēng)吵！

原文鏈接：

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