java-装饰HashMap添加随机性以防止(D)DoS

顺便说一下,这里的解决方法是重新使用所有现有的HashMap(例如ConcurrentHashMap等),而不是完全重新发明轮子.使用随机哈希函数的语言(如Perl)可以防止这种攻击.

鉴于最近在多个hashmap实现中使用已知缺陷的DDoS(具有破坏性)(已知会影响Java Web服务器,但也影响PHP和其他),Apache Tomcat刚刚以补丁的形式发布了一个“修复程序”,允许放置限制POST请求中允许的最大参数数量(将Tomcat修补为6.0.35或7.0.23 btw).

(D)DoS显然基本上是基于这样的事实,即可以对字符串进行精心设计,使它们在散列时发生冲突,并且许多Web服务器“愚蠢地”将键/值参数放入(断开)散列图中.

我想知道是否有可能在HashMap {String,String}周围编写装饰器,以便向每个String添加一个随机值(从受攻击的角度来看是随机的),就像这样：

... get( String s ) {
    return wrappedBrokenMap.get( s + crunch(s );
}

... put( String key, String value ) {


  wrappedBrokenMap.put( s + crunch(s), value );
}

这将是crunch(…)的一个实现(这只是一个示例,重点是：攻击者不知道实现)：

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;
}

如果对于任何String,紧急情况都返回了攻击者无法猜测的可复制String,那么DDoS攻击已被有效阻止了吗？

那行得通吗？

解决方法:

If for any String s crunch(s) returns a reproducible String that the attacker cannot guess, the DDoS attack has effectively been prevented right?

基本上,这是在对密码哈希加盐时执行的操作(尽管出于稍微不同的原因).它不能完全防止碰撞攻击(如果您具有将任意长度的输入映射到固定长度的输出的哈希函数,则哈希值始终会发生冲突),但是使用秘密盐会使此类攻击更加困难.

一个快速的’肮脏的实现可能看起来像这样：

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为每个传入请求随机分配一个新的盐,这意味着即使您设法为一个请求找出了产生冲突的输入,对于其他请求也不大可能起作用要求.

标签：hashmap,denial-of-service,java,php
来源： https://codeday.me/bug/20191101/1986887.html