HashMap漏洞

最新推荐文章于 2024-07-10 10:27:27 发布

最新推荐文章于 2024-07-10 10:27:27 发布 · 267 阅读

文章标签：

#php #java

本文探讨了Java中HashMap和Hashtable类使用String.hashCode()函数可能存在的安全隐患，特别是针对攻击者利用特定字符串构造来破坏缓存和强制重新哈希的情况。文章详细分析了不同Web应用程序如何解析POST数据，并指出最大POST大小的差异性。通过实例，揭示了攻击者如何利用这些漏洞，以及攻击的潜在影响。

== 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.