我正在研究算法构建和资源消耗的弱点。一个真正引起我注意的漏洞是Apache Range Header DoS Vulnerability。以下引用来自 Apache 开发人员讨论该漏洞：
通过查看代码，我认为问题在于存储桶结构。
使用 N 请求范围的数量，初始旅
最多被划分为 2*N 个桶。然后将这些桶
复制到输出旅 N 次，这意味着
创建了 O(N^2) 个桶。数据没有被复制，并且只
从池中分配了 N 个“AB”字符串。
是否还有其他人知道有关构建抵抗资源耗尽攻击的算法的其他资源？有没有关于算法分析和资源枯竭敏感性的有趣论文？您是否知道由有缺陷的算法导致的其他资源消耗漏洞？
这种攻击被称为哈希 DoS，或更一般地称为算法复杂性攻击。
有几种方法可以实现查找表：
避免 Hash DoS 的常见策略有两种：您可以切换到树，或者您可以使用键控哈希。
对于密钥哈希，服务器选择一个随机密钥。根据具体情况，这个密钥可以是每个进程、每个表、每个请求……更长的生命周期可以允许对多个请求进行自适应攻击，但我不确定这在实践中有多大的问题。
然后它使用键控散列来确定存储桶，而不是使用非键控散列函数。如果键控散列是好的，这可以防止攻击者快速产生冲突。早期的键控散列经常遭受键独立冲突，因此一旦发现它们就无法阻止攻击。目前SipHash越来越受欢迎，因为它速度快，但仍然是加密安全的。
我的建议是使用 SipHash 并尽可能避免跨请求重用密钥。
Breaking Murmur: Hash-flooding DoS Reloaded（在 Martin Boßlet 的博客上）
攻击
与 Martin Boßlet 联合，我们展示了 MurmurHash（用于 Ruby、Java 等）、CityHash（用于 Google）和 Python 哈希的弱点。一些受影响的技术已转向 SipHash。请参阅此 oCERT 公告和以下资源：
- 2012 年瑞士西部应用安全论坛（Aumasson，Boßlet）上的演示文稿“重载哈希泛洪 DoS：攻击和防御”的幻灯片
许多编程语言目前正在升级其标准库以避免 Hash DoS。这些攻击对动态类型语言的打击很大，因为它们通常几乎在任何地方都使用哈希表（成员名称到值等）
一些升级哈希表的大项目：
特定的资源耗尽错误是由每个请求的块的复制传输缓冲区引起的。因此，如果发送 64 个全长范围，则具有 16kB 发送缓冲区的配置实际上将消耗 1MB 内存，如果发送 640 个范围标头，则实际消耗 10MB。只要连接保持打开状态，未发送的缓冲区就会保留在内存中。显然，这可以用来执行有效的 DoS，因为只有 10 个打开的连接和 640 个范围标头，每个可能会占用 100MB。您的里程可能会因不同的配置设置而异。
我不知道任何关于算法安全分析的论文，但是寻找资源耗尽错误的最佳方法之一是识别算法中不受限制的输入可以改变分配的内存量的任何点，或者客户端有做的工作比服务器少得多。