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

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了java-装饰HashMap添加随机性以防止(D)DoS，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含1986字，纯文字阅读大概需要3分钟。

内容图文

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

内容总结

以上是互联网集市为您收集整理的java-装饰HashMap添加随机性以防止(D)DoS全部内容，希望文章能够帮你解决java-装饰HashMap添加随机性以防止(D)DoS所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端