装饰HashMap添加随机性以防止（D）DoS [英] Decorating a HashMap adding randomness to prevent (D)DoS
问题描述
鉴于最近发生的破坏性DDoS使用多个hashmap中的已知缺陷实现（已知影响Java Web服务器，但也影响PHP和其他），Apache Tomcat刚刚以修补程序的形式提供了一个修复，允许限制POST请求中允许的最大参数数量（修补（D）DoS显然基本上是使用这样一个事实，即可以制作字符串以便它们相互碰撞当散列，并且很多web服务器愚蠢地把键/值参数放入（破碎的）hashmaps中。
我想知道是否可以写一个装饰器一个HashMap {String，String}，以便每个String都添加一个随机数（从攻击的角度来看是随机的）值被添加到String中，如下所示：
... get（String s）{
return wrap pedBrokenMap.get（s + crunch（s）;
... put（String key，String value）{
wrappedBrokenMap.put（s + crunch（s），value） ;
这里有一个 crunch（...） （这只是一个例子，关键是：攻击者不知道实现）：
private static final int MY_MAGICAL_NUMBER = 0x42BABE; //攻击者不知道这个数字
private static String crunch（String s）{
return s.length ++ MY_MAGICAL_NUMBER;
如果有任何String s crunch（s）返回一个可重复使用的字符串，攻击者无法猜测，DDoS攻击已被有效阻止了吗？
这是否有效？
如果对于任何String s crunch（s）返回一个可重现的字符串，攻击者无法猜测，则DDoS攻击具有有效地被阻止了吗？
基本上，当你使用密码哈希（尽管原因略有不同）时，你会这样做。它并不完全防止碰撞攻击（如果你有一个散列函数将任意长度的输入映射到一个固定长度的输出，散列总是可以碰撞），但是使用秘密salt会使这种攻击更难。
quick'n'dirty的实现可能如下所示：
public class SaltedHashMap< V> {
private final Map< String，V> map = new HashMap<>（）;
private final String salt;
public SaltedHashMap（String salt）{
this.salt = salt;
}
public V get（String key）{
return map.get（key + salt）;
}
public void put（String key，V value）{
map.put（key + salt，value）;
以web服务器为例，我们可以使用一个 SecureRandom 来为每个传入的请求随机化一个新的salt，这意味着即使你设法找出一个请求的冲突生成输入，它也不太可能工作对于其他请求。
EDIT by the way the point of the workaround here is to reuse all the existing HashMap (like the ConcurrentHashMap etc.) instead of re-inventing entirely the wheel. Languages using randomized hash functions (like Perl) are protected against this attack.
In the light of the very recent and devastating DDoS using known flaw in several hashmap implementations (known to affect Java webservers, but also PHP and others), Apache Tomcat just came out with a "fix" in the form of a patch allowing to put a cap on the maximum allowed numbers of parameters in a POST request (patch your Tomcat to 6.0.35+ or 7.0.23+ btw).
The (D)DoS is apparently basically using the fact that strings can be crafted so that they do collide when hashed and that a lot of webservers "stupidly" put key/value parameters in (broken) hashmaps.
I was wondering if it would be possible to write a decorator around a HashMap{String,String} so that to every String added a random (random from the point of view of an attacked) value was added to the String, like this:
... get( String s ) {
return wrappedBrokenMap.get( s + crunch(s );
}
... put( String key, String value ) {
wrappedBrokenMap.put( s + crunch(s), value );
}
And here would be one implementation of crunch(...) (it is just an example, the point is: the attacker doesn't know the implementation):
private static final int MY_MAGICAL_NUMBER = 0x42BABE; // attacker doesn't know that number
private static String crunch( String s ) {
return s.length + "" + MY_MAGICAL_NUMBER;
}
If for any String s crunch(s) returns a reproducible String that the attacker cannot guess, the DDoS attack has effectively been prevented right?
Would that work?
If for any String s crunch(s) returns a reproducible String that the attacker cannot guess, the DDoS attack has effectively been prevented right?
Basically, this is what you do when you salt password hashes (although for slightly different reasons). It doesn't prevent collision attacks entirely (if you have a hash function mapping arbitrary-length input to a fixed-length output, hashes can always collide), but using a secret salt should make such attacks harder.
A quick'n'dirty implementation could look something like this:
public class SaltedHashMap<V> {
private final Map<String, V> map = new HashMap<>();
private final String salt;
public SaltedHashMap(String salt) {
this.salt = salt;
}
public V get(String key){
return map.get(key + salt);
}
public void put(String key, V value) {
map.put(key + salt, value);
}
}
Using a web server as an example, we could use a SecureRandom to randomize a new salt for every incoming request, meaning that even if you managed to figure out a collision-generating input for one request, it would be extremely unlikely to work for other requests.
这篇关于装饰HashMap添加随机性以防止（D）DoS的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
