如何阻止对Web应用程序发起的DoS攻击？( 二 ) _DoS攻击

高杠杆率 DoS 漏洞：容易放大的资源匮乏典型的高风险 DoS 漏洞是那些攻击者本身只需要很少资源就能造成资源匮乏的漏洞。这可能意味着耗尽任何类型的资源，包括：

磁盘空间——例如，一个漏洞放大上传数据并塞满磁盘，比如典型的 zip 炸弹。
网络带宽——例如，一个漏洞放大输入流量，而单个输入请求会消耗大量带宽，导致网络堵塞。我在微服务系统中看到过这样的 bug，单个输入请求触发大量的内部 API 请求（包括在网络上传送相当大的文件），并阻塞了内部网络带宽。
CPU 占用——例如，一个漏洞触发了一个 accidentally quadratic 算法，导致 Web 服务陷入瘫痪。
并发限制——大部分服务器都有一个最大并发量限制（例如最大线程数或最大进程数，或数据库最大连接数）；一个漏洞导致进程运行非常慢（甚至永不退出），则会导致服务器达到这些限制并开始拒绝请求。

在所有这些情况中，共同因素是应用程序的一个 bug 会导致显著的放大效应。
身份认证影响风险当考虑资源放大 DoS 问题的风险时，一个重要因素是触发该漏洞所需的身份认证级别。
如果一个完全匿名的用户就能轻易触发一个资源匮乏攻击，那么攻击者就很容易利用这个漏洞让你崩溃。无需身份认证的 DoS 问题应该被视为高风险。
另一方面，如果只有经过你公司单点登录服务器验证过的用户才能触发该漏洞，那么，这就是一个非常低的风险。大部分攻击者不是内部人员（尽管有些是！）。而且，如果攻击者出现，很容易确定和阻止。
在大多数情况下，“我们可以确定并阻止攻击”是一种合理的，尽管不完备的缓解策略。大多数漏洞介于这两个极端之间：大多数服务让创建新账户非常简单（例如，你只需要一个邮箱地址）。这确实赋予了一些能力来确定和阻止漏洞，但这往往是不够的。
缓解建议：消除一般来说，我建议将这类 DoS 漏洞——特别是无需身份验证的漏洞——视为高风险，并且予以消除。如果它被利用，这些漏洞就是灾难性的；它们能让单个攻击者就击溃你的应用程序。我会投入跟其它高风险安全漏洞（例如 XSS 和 CSRF）一样的精力来发现并消除这种 bug 。
一个高杠杆率漏洞示例：ReDoS最后一种资源匮乏的常见例子（并发量限制）是正则表达式拒绝服务（regular expression denial-of-service），又叫 ReDoS 。当特定类型的字符串会导致不恰当构建的正则表达式表现非常差时，ReDoS bug 就会发生。
不幸的是，这种漏洞在 Python 中很常见；内置的正则表达式模块 (re) 没有针对这种漏洞的内在保护（不像 re2 库，Go 内置的 regex 模块，因此让语言或多或少对这种攻击免疫）。（Django 本身多年来也存在一些这种漏洞；例如，CVE-2019-14232 和 CVE-2019-14233 都是 ReDoS 漏洞。）在 Django，这些漏洞通常出现在两个地方：基于正则表达式的 URL 解析和自定义验证器，以及应用程序使用正则表达式的其它地方。幸运的是，这种类型的漏洞很容易找到。请参阅以下 r2c 文章：

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

如果你用 Python，你可以在应用程序中使用 Semgrep 扫描 ReDoS，这个库从 Dlint 移植了 ReDoS 检测功能。检测需要一些使用 Semgrep 强大的 pattern-where-python 子句编写的额外逻辑，这些子句让规则能充分利用 Python 的全部功能，因此你必须使用--dangerously-allow-arbitrary-code-execution-from-rules 标志。
?复制代码
$ semgrep --config https://semgrep.dev/r/contrib.dlint.redos--dangerously-allow-arbitrary-code-execution-from-rules中杠杆率 DoS 风险：复杂的资源匮乏稍微深入研究风险案例，我们发现资源匮乏的一个不同类型：你的应用程序本身就比较慢或者资源比较紧张。例如：