有人考虑过 netty 对 oCERT-2011-003 的敏感性吗？
通过哈希表多重冲突导致拒绝服务 (http://www.nruns.com/_downloads/advisory28122011.pdf)
我希望有人能找到 Netty 的 QueryStringDecoder 不易受此影响的原因攻击。
来自引用的.pdf
== Java == Java 提供了 HashMap 和 Hashtable 类，它们使用 String.hashCode() 哈希函数。它与 DJBX33A 非常相似（它使用乘法常数 31 代替 33，并且使用 0 代替起始值 5381）。因此它也容易受到等效子串攻击。当对字符串进行哈希处理时，Java 还会将哈希值缓存在哈希属性中，但前提是结果不为零。因此，目标值零对于攻击者来说特别有趣，因为它可以防止缓存并强制重新散列。
不同的 Web 应用程序对 POST 数据的解析方式不同，但测试的应用程序（Tomcat、Geronima、Jetty、Glassfish）都将 POST 表单数据放入 Hashtable 或 HashMap 对象中。最大 POST 大小也因服务器而异，最常见的是 2 MB。
Tomcat 6.0.32 服务器在大约 44 分钟的 i7 CPU 时间内解析 2 MB 的冲突密钥字符串，因此大约 6 kbit/s 的攻击者可以使一个 i7 核心持续忙碌。如果攻击者拥有千兆位连接，他可以让大约 100,000 个 i7 核心保持忙碌。
Denial of Service through hash table multi-collisions (http://www.nruns.com/_downloads/advisory28122011.pdf)
I'm hoping someone has a reason why Netty's QueryStringDecoder isn't susceptible to this attack.
From the referenced .pdf
== Java ==
Java offers the HashMap and Hashtable classes, which use the String.hashCode() hash function. It is very similar to DJBX33A (instead of 33, it uses the multiplication constant 31 and instead of the start value 5381 it uses 0). Thus it is also vulnerable to an equivalent substring attack. When hashing a string, Java also caches the hash value in the hash attribute, but only if the result is different from zero. Thus, the target value zero is particularly interesting for an attacker as it prevents caching and forces re-hashing.
Different web application parse the POST data differently, but the ones tested (Tomcat, Geronima, Jetty, Glassfish) all put the POST form data into either a Hashtable or HashMap object. The maximal POST sizes also differ from server to server, with 2 MB being the most common.
A Tomcat 6.0.32 server parses a 2 MB string of colliding keys in about 44 minutes of i7 CPU time, so an attacker with about 6 kbit/s can keep one i7 core constantly busy. If the attacker has a Gigabit connection, he can keep about 100.000 i7 cores busy.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
是的...
Netty 不受影响，因为我们已经限制了标头大小。有关更多详细信息，请参阅 [1]：
[1] https://github.com/netty/netty/问题/141
Yes...
Netty is not affected as we limit the header size already. See [1] for more details:
[1] https://github.com/netty/netty/issues/141
看来Trustin已经考虑到了这一点。
Looks like Trustin has already considered this.