Отказ в обслуживании из-за множественных коллизий хеш-таблицы (http://www.nruns.com/_downloads/advisory28122011.pdf)
Я надеюсь, что у кого-то есть причина, по которой Netery QueryStringDecoder не подвержен этой атаке.
Из упомянутого .pdf
== Java == Java предлагает классы HashMap и Hashtable, которые используют хеш-функцию String.hashCode (). Она очень похожа на DJBX33A (вместо 33 она использует умножениеконстанта 31 и вместо начального значения 5381 используется 0). Таким образом, она также уязвима для эквивалентной атаки на подстроку. При хешировании строки Java также кэширует значение хеш-функции в атрибуте хеш-функции, но только если результат отличается от нуляТаким образом, целевое значение ноль особенно интересно для злоумышленника, так как оно предотвращает кэширование и вызывает повторное хэширование.
Различные веб-приложения анализируют данные POST по-разному, но проверенные (Tomcat, Geronima, Jetty, Glassfish).) все помещают данные формы POST в объект Hashtable или HashMap. Максимальные размеры POST такжеотличаются от сервера к серверу, причем 2 МБ являются наиболее распространенными.
Сервер Tomcat 6.0.32 анализирует строку 2 МБ конфликтующих ключей примерно за 44 минуты процессорного времени i7, поэтому злоумышленник с около 6 Кбит/ s может держать одно ядро i7 постоянно занятым.Если у злоумышленника есть гигабитное соединение, он может поддерживать около 100 000 ядер i7.