The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Универсальный способ DoS-атаки, затрагивающий PHP, Java, Rub..."
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Универсальный способ DoS-атаки, затрагивающий PHP, Java, Rub..."  +/
Сообщение от opennews on 30-Дек-11, 11:45 
На проходящей в Берлине конференции Chaos Communication Congress (28c3) обнародован (http://www.ocert.org/advisories/ocert-2011-003.html) новый способ нарушения работоспособности web-сервисов, основанный (https://cryptanalysis.eu/blog/2011/12/28/effective-dos-attac.../) на особенности реализации структур хэшей, используемых для организации хранения наборов данных в представлении ключ/значение, в широком спектре языков программирования. Манипулируя используемыми в качестве ключей данными, атакующий может затратив минимальные ресурсы инициировать возникновение предсказуемых коллизий в алгоритме хэширования, разрешение которых требует дополнительных значительных процессорных ресурсов.


Большинство web-фреймворков и web-приложений на этапе разбора HTTP POST-запроса автоматически размещают передаваемые пользователем параметры в хэше, что позволяет атакующему контролировать наполнение хэша. В зависимости от языка программирования для достижени...

URL: https://cryptanalysis.eu/blog/2011/12/28/effective-dos-attac.../
Новость: http://www.opennet.dev/opennews/art.shtml?num=32698

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Универсальный способ DoS-атаки, затрагивающий PHP, Java, Rub..."  +13 +/
Сообщение от Анонимоус on 30-Дек-11, 11:45 
хмм.. а в Германии, оказывается, куча спецов по компьютерной безопасности
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

5. "Универсальный способ DoS-атаки, затрагивающий PHP, Java, Rub..."  +3 +/
Сообщение от Аноним (??) on 30-Дек-11, 12:58 
http://en.wikipedia.org/wiki/Chaos_Computer_Club
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

16. "Универсальный способ DoS-атаки, затрагивающий PHP, Java, Rub..."  +3 +/
Сообщение от pavlinux (ok) on 30-Дек-11, 15:41 
4-й рейх? :)
Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

28. "Универсальный способ DoS-атаки, затрагивающий PHP, Java, Rub..."  +1 +/
Сообщение от Аноним (??) on 30-Дек-11, 20:42 
> 4-й рейх? :)

0xC3-й.

Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

45. "Универсальный способ DoS-атаки, затрагивающий PHP, Java, Rub..."  +1 +/
Сообщение от pavlinux (ok) on 31-Дек-11, 03:37 
>> 4-й рейх? :)
> 0xC3-й.

https://en.wikipedia.org/wiki/Chaos_Computer_Club
The CCC is based in Germany and other German-speaking countries.

Я вот так, навскидку, сразу и не вспомню "other German-speaking countries" :)
Австрия если только,...

Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

47. "Универсальный способ DoS-атаки, затрагивающий PHP, Java, Rub..."  +2 +/
Сообщение от лки Новый Год on 31-Дек-11, 06:22 
>""Я вот так, навскидку, сразу и не вспомню "other German-speaking countries" :)

Австрия если только,... ""

С википедии:

Germany
Austria
Switzerland
Liechtenstein

да и в соседних областях той же Чехии и Польши многие жители говорят/понимают по немецки

Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

65. "Универсальный способ DoS-атаки, затрагивающий PHP, Java, Rub..."  +1 +/
Сообщение от pavlinux (ok) on 31-Дек-11, 20:13 
> С википедии:

Ключевое слово "навскидку", то есть из мозга. :)

А как один из государственных, в Бельгии ещё.

Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

72. "Универсальный способ DoS-атаки, затрагивающий PHP, Java, Rub..."  +/
Сообщение от anonymous (??) on 02-Янв-12, 09:41 
бывшие германские колонии?
Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

73. "Универсальный способ DoS-атаки, затрагивающий PHP, Java, Rub..."  +/
Сообщение от Линуся on 02-Янв-12, 17:20 
бывшие немецкие территории, до мировых войн...
Ответить | Правка | ^ к родителю #72 | Наверх | Cообщить модератору

2. "Универсальный способ DoS-атаки, затрагивающий PHP, Java, Rub..."  +/
Сообщение от Аноним (??) on 30-Дек-11, 11:51 
тоесть в чём суть исправления как я понимаю:

...при создании каждого Хэш-объекта (Хэш-словаря) -- в него должно записываться случайная переменная "R" (так её условно назовём)

затем при помещении/извлечении в каждый такой Хэш-Словарь Key/Value значений -- необходимо делать операцию "Real_Key = Key XOR R"

вродебы не сложно :-)

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

23. "Универсальный способ DoS-атаки, затрагивающий PHP, Java,..."  +/
Сообщение от arisu (ok) on 30-Дек-11, 19:24 
суть исправления в том, чтобы подсаливать хэш рандомными (но, натурально, постоянными для одного сеанса) значениями.
Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

3. "Универсальный способ DoS-атаки, затрагивающий PHP, Java, Rub..."  +3 +/
Сообщение от Oleksiy Kovyrin email on 30-Дек-11, 12:32 
Так как для Ruby EE патча еще нет, то мы портировали решение из последнего Ruby 1.8.7: http://kovyrin.net/2011/12/29/ree-hash-collision-patch/
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

4. "Универсальный способ DoS-атаки, затрагивающий PHP, Java, Rub..."  +2 +/
Сообщение от ЬТЛ on 30-Дек-11, 12:53 
приятно что такие решения "отдают" для фикса, а не используют.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

14. "Универсальный способ DoS-атаки, затрагивающий PHP, Java, Rub..."  +1 +/
Сообщение от const86 (ok) on 30-Дек-11, 15:29 
Точно не используют? Может, уже извлекли, так сказать, выгоду и настало время подумать о совести :) Да и после публикации вполне можно использовать, пока везде не пофиксят.
Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

20. "Универсальный способ DoS-атаки, затрагивающий PHP, Java, Rub..."  +/
Сообщение от oxyum (ok) on 30-Дек-11, 18:18 
...годика эдак 2... а кое-где и все 5 лет... :(
Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

25. "Универсальный способ DoS-атаки, затрагивающий PHP, Java, Rub..."  +2 +/
Сообщение от Аноним (??) on 30-Дек-11, 19:44 
В новости сказано, что в Perl проблема исправлена уже в 2003 г, т.е. проблема известна 9 лет, а то и больше. Все кому надо успели попользоваться )
Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

6. "Универсальный способ DoS-атаки, затрагивающий PHP, Java, Rub..."  +1 +/
Сообщение от YetAnotherOnanym on 30-Дек-11, 13:08 
Изящно и утончённо :)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

7. "Универсальный способ DoS-атаки, затрагивающий PHP, Java, Rub..."  +/
Сообщение от Анонимус 84705648 on 30-Дек-11, 13:15 
интересно, а те хеши, которые используются в iptables/conntrack, тоже уязвимы?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

9. "Универсальный способ DoS-атаки, затрагивающий PHP, Java, Rub..."  +1 +/
Сообщение от Аноним (??) on 30-Дек-11, 13:19 
> интересно, а те хеши, которые используются в iptables/conntrack, тоже уязвимы?

В хэш netfilter произвольное значение не передать, там жестко структурированные значения, типа ip и номера порта.

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

11. "Универсальный способ DoS-атаки, затрагивающий PHP, Java, Rub..."  +/
Сообщение от Анонимус 84705648 on 30-Дек-11, 13:56 
ну, можно, например, попробовать зафлудить целевой узел udp-пакетами с поддельными src_ip:src_port, причём src_ip:src_port выбирать так, чтобы хеш в netfilter получался всегда одинаковым
Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

66. "Универсальный способ DoS-атаки, затрагивающий PHP, Java, Rub..."  +/
Сообщение от XoRe (ok) on 01-Янв-12, 04:18 
> ну, можно, например, попробовать зафлудить целевой узел udp-пакетами с поддельными src_ip:src_port,
> причём src_ip:src_port выбирать так, чтобы хеш в netfilter получался всегда одинаковым

Боюсь, 95% трафика идет с одинаковыми параметрами "src_ip:src_port".
Как передаются файлы по ftp - договорились насчет src_port+dst_port и понеслась.
За одно соединение можно миллиарды пакетов передать.
По UDP тоже самое - nfs и netbios предполагают большое число пакетов с одинаковыми параметрами.
Ниже указали строчку из исходников nf_conntrack.
Я думаю, в ядре эту дырку закрыли ещё раньше, чем в perl.

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

13. "Универсальный способ DoS-атаки, затрагивающий PHP, Java, Rub..."  –2 +/
Сообщение от фклфт (ok) on 30-Дек-11, 15:29 
>> интересно, а те хеши, которые используются в iptables/conntrack, тоже уязвимы?
> В хэш netfilter произвольное значение не передать, там жестко структурированные значения,
> типа ip и номера порта.

Вы не поверите но я уже несколько раз за последние года 4 у себя в логах замечал попытку добавления правила на фаере, с тех пор как первый раз это заметил теперь стоит полный запрет на добавление изменение правил iptables - все идет только через конфиг во время загрузки
Конечно не удобно, что бы добавить или удалить правило на фаере приходится менять конфиг и ребутить сервак, за то надежно

Если у вас болье менее посещаемый сервер то сделайти полное логирование всего что происходит, не удивлюсь что у вас типа сами по себе добавляются/удаляются правила
Кстати не надо забывать про то что несколько месяцев назад нашли багу в апаче благодаря которой можно было через веб гулять по всей корпоративной сети, тут с iptables примерно тоже самое только в реализации nat_iptables

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

29. "Универсальный способ DoS-атаки, затрагивающий PHP, Java, Rub..."  +1 +/
Сообщение от Аноним (??) on 30-Дек-11, 20:45 
> у себя в логах замечал попытку добавления правила на фаере

Чувак, я не хочу тебя расстраивать, но у тебя кажется на серваке что-то идет не так. Понимаешь, правила сами по себе добавляться не могут. Добавить их может троянец, хакер, ну или ты сам. Ремотное добавление правил как-то не предусмотрено дизайном айпитаблеса само по себе.

Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

40. "Универсальный способ DoS-атаки, затрагивающий PHP, Java, Rub..."  +/
Сообщение от Аноним (??) on 30-Дек-11, 23:15 
> Чувак, я не хочу тебя расстраивать, но у тебя кажется на серваке
> что-то идет не так. Понимаешь, правила сами по себе добавляться не
> могут. Добавить их может троянец, хакер, ну или ты сам. Ремотное
> добавление правил как-то не предусмотрено дизайном айпитаблеса само по себе.

Есть такая штука - libvirt. Считает, что гораздо лучше админа знает, какие правила должны быть в iptables. Ее происки легко узнать по ключевым словам "192.168.122.0/24" и "virbr0".

Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

44. "Универсальный способ DoS-атаки, затрагивающий PHP, Java, Rub..."  +/
Сообщение от 12у34 on 31-Дек-11, 03:12 
поясните каким образом связаны библиотека для виртуализации и iptables.
Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

46. "Универсальный способ DoS-атаки, затрагивающий PHP, Java, Rub..."  +/
Сообщение от Аноним (??) on 31-Дек-11, 05:06 
Посмотрите на список правил до и после запуска libvirtd.
Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

17. "Универсальный способ DoS-атаки, затрагивающий PHP, Java, Rub..."  +/
Сообщение от Аноним (??) on 30-Дек-11, 16:34 
> интересно, а те хеши, которые используются в iptables/conntrack, тоже уязвимы?

Нет, там используются хеши Дженкинса.

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

24. "Универсальный способ DoS-атаки, затрагивающий PHP, Java,..."  –5 +/
Сообщение от arisu (ok) on 30-Дек-11, 19:36 
>> интересно, а те хеши, которые используются в iptables/conntrack, тоже уязвимы?
> Нет, там используются хеши Дженкинса.

я тебе сейчас секрет скажу, только ты присядь сначала: от типа хэш-функции наличие/отсутствие уязвимости не зависит.

Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

27. "Универсальный способ DoS-атаки, затрагивающий PHP, Java,..."  +3 +/
Сообщение от Аноним (??) on 30-Дек-11, 20:37 
Если использовать криптографически стойкое хеширование да еще индивидуальной соли добавить - искать коллизии станет довольно утомительно, разве нет? Правда скорость будет заметно хуже.
Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

49. "Универсальный способ DoS-атаки, затрагивающий PHP, Java,..."  +/
Сообщение от Аноним (??) on 31-Дек-11, 13:45 
> Если использовать криптографически стойкое хеширование да еще индивидуальной соли добавить
> - искать коллизии станет довольно утомительно, разве нет? Правда скорость будет
> заметно хуже.

наверно в нашем случае достаточно всего лишь "индивидуальной соли добавить" :-)

ведь сложновато найти коллизию хэша, если даже само хэш-значение не отображается в наружу :-) :-)

Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

39. "Универсальный способ DoS-атаки, затрагивающий PHP, Java,..."  +/
Сообщение от Аноним (??) on 30-Дек-11, 23:12 
> я тебе сейчас секрет скажу, только ты присядь сначала: от типа хэш-функции наличие/отсутствие уязвимости не зависит.

Ну найдите мне хоть коллизию для conntrack tuple, а то языком трепать все горазды :D

Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

42. "Универсальный способ DoS-атаки, затрагивающий PHP, Java, Rub..."  +/
Сообщение от Аноним (??) on 30-Дек-11, 23:50 
> интересно, а те хеши, которые используются в iptables/conntrack, тоже уязвимы?

Судя по строчке из nf_conntrack_core.c
> return jhash2((u32 *)tuple, n, zone ^ nf_conntrack_hash_rnd ^ (((__force __u16)tuple->dst.u.all << 16) | tuple->dst.protonum));

там используется добавление случайной соли (nf_conntrack_hash_rnd), так что плакали все коллизии :)

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

18. "Универсальный способ DoS-атаки, затрагивающий PHP, Java, Rub..."  +2 +/
Сообщение от vasek on 30-Дек-11, 17:52 
оп, Perl и CRuby молодцом =)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

19. "Универсальный способ DoS-атаки, затрагивающий PHP, Java, Rub..."  –1 +/
Сообщение от Аноним (??) on 30-Дек-11, 18:11 
для asp.net пофиксили сразу
давно в винапдейтах
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

41. "Универсальный способ DoS-атаки, затрагивающий PHP, Java, Rub..."  +/
Сообщение от Аноним (??) on 30-Дек-11, 23:21 
> для asp.net пофиксили сразу

Не сразу, а с опозданием на 8 лет. Сразу - это в перле пофиксили.
Мелокософт, как обычно, "заботится" о безопасности.

Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

35. "Универсальный способ DoS-атаки, затрагивающий PHP, Java, Rub..."  +1 +/
Сообщение от evgeny_t (ok) on 30-Дек-11, 22:37 
c таким прогрммирование страно что мир ещё работает )
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

67. "Универсальный способ DoS-атаки, затрагивающий PHP, Java, Rub..."  +/
Сообщение от XoRe (ok) on 01-Янв-12, 04:20 
> c таким прогрммирование страно что мир ещё работает )

Тссс, никому не говорите)

Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

36. "Универсальный способ DoS-атаки, затрагивающий PHP, Java, Rub..."  +/
Сообщение от evgeny_t (ok) on 30-Дек-11, 22:39 
да проще взять дерево и всё будет ок )
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

43. "Универсальный способ DoS-атаки, затрагивающий PHP, Java, Rub..."  +2 +/
Сообщение от svn (??) on 31-Дек-11, 01:05 
Проще не дерево, а обрабатывать параметны по мере получения. А не так как делает пыхпых читая мегабайты, засовывая их в хешмап, даже если обработчик post запроса вообще не нуждается в параметрах.

В стандарт http добавить порядок параметров, чтобы авторизация шла первой.

Скрипты обязать регистрировать входные параметры ПЕРЕД началом обработки полученных от клиента данных, чтобы все не заявленные данные post запроса игнорировались. Ключи хеша определяются на стороне сервера - значит нет проблемы.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

50. "Универсальный способ DoS-атаки, затрагивающий PHP, Java, Rub..."  +/
Сообщение от Аноним (??) on 31-Дек-11, 13:50 
> Проще не дерево, а обрабатывать параметны по мере получения. А не так
> как делает пыхпых читая мегабайты, засовывая их в хешмап, даже если
> обработчик post запроса вообще не нуждается в параметрах.
> В стандарт http добавить порядок параметров, чтобы авторизация шла первой.
> Скрипты обязать регистрировать входные параметры ПЕРЕД началом обработки полученных от
> клиента данных, чтобы все не заявленные данные post запроса игнорировались. Ключи
> хеша определяются на стороне сервера - значит нет проблемы.

всё это предложенное -- замечательно :-) .. но если предположить что уязвимость в хэш-словарях не будет исправлена -- то сёравно найдётся какойто другой (НЕ унивирсальный для каждого сайта) способ её заэксплуатировать!

Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

51. "Универсальный способ DoS-атаки, затрагивающий PHP, Java, Rub..."  +/
Сообщение от Аноним (??) on 31-Дек-11, 13:58 
> В стандарт http добавить порядок параметров, чтобы авторизация шла первой.

а она первой и идёт там...

...там header-поле "WWW-Authenticate: ..." (а уж только потом ниже передаётся тело POST-запроса)

нужно просто поголовно ВЕЗДЕ использовать AJAX на WWW-страницах. доступ к полю "WWW-Authenticate: ..." у XMLHttpRequest-объекта вполне себе есть, например. а также надо забить на MsIE (для которого AJAX пришлось бы делать индивидуально) и забить на нытиков, которые используют NoScript :)

получилибы вообще от  AJAX сполшные плюсы! шаблонизировать страницу сайта (на стороне сервера) при каждом запросе не пришлосьбы.. HTTP-данные лишнии при каждом запросе пересылать не пришлосьбы тоже. скорость интернета увеличилась бы, и былобы щастье :-)

Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

52. "Универсальный способ DoS-атаки, затрагивающий PHP, Java, Rub..."  +/
Сообщение от Аноним (??) on 31-Дек-11, 14:02 
поясню немного глубже...

header-поле "WWW-Authenticate: ..." не обязательно использовать только для BASIC аудентификации. туда можно (и это НЕ хак!) запихнуть любой вид значения, которое программист щитает что необходим для аудентификации пользователя для авторизации действия.... например можно указать:

WWW-Authenticate: SESSION_ID 1234abc124acb123abc123abc

Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

69. "Универсальный способ DoS-атаки, затрагивающий PHP, Java, Rub..."  +/
Сообщение от terr0rist (ok) on 01-Янв-12, 16:36 
Не пишите ересь. Чем AJAX HTTP-запрос отличается от обычного? вам не приходит в голову, что AJAX - это не протокол, и даже не модификация протокола, а всего лишь способ послать запрос из браузера без перезагрузки страницы? Объект XMLHttpRequest не имеет никакого отношения к методам хеширования, авторизации, разбора заголовков или распития спиртных напитков на сервере.
> скорость интернета увеличилась бы

да, конечно, в 100 раз. По 100-мбитной сети сразу до 10Гб. Вы даже не знаете, что интернет - это не только НТТР и "лишние НТТР-данные" (НТТР-заголовки) - это наверно одна квинтиллионная всего трафика. Хотя что говорить, аноним такой аноним.

Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

76. "Универсальный способ DoS-атаки, затрагивающий PHP, Java, Rub..."  –1 +/
Сообщение от Аноним (??) on 03-Янв-12, 14:46 
> Чем AJAX HTTP-запрос отличается от обычного?

всмысле если "обычный" -- это <form ...>...</form> -- то отличия весьма очевидны. одно из отличий -- например в том что AJAX (XMLHttpRequest) более гибко может работать с HTTP-headers, а вот <form ...>...</form> никакой гибкости не предоставляет :-D

> вам не приходит в голову, что AJAX - это не протокол, и даже не модификация протокола, а всего лишь способ послать запрос из браузера без перезагрузки страницы

а вам в голову не приходит что какимбы словом вы это не обозвалибы "протокол" или "не протокол" или "способ" -- суть это не поменяет. AJAX это набор определённых действий. а уж называйте (классифицируйте) эти "действия" словом каким хотите :-)

> способ послать запрос из браузера без перезагрузки страницы

при этом заметьте что с сервера перекладываются часть работы на клиента. например серверу (в наиболее качественной реализации принципа AJAX) -- не придётся заниматься шаблонизированием www-странички ВООБЩЕ, это будет делатсья при помощщи шаблонизатора на клиентской стороне. а ещё серверу не придётся заниматься маршрутизацией URL`ов. функциональная нагрузка с сервера уходит -- значит сложность за DDoS`ить сервер возрастает.

> Объект XMLHttpRequest не имеет никакого отношения к методам хеширования, авторизации, разбора заголовков или распития спиртных напитков на сервере.

уже выше было написанно что Объект XMLHttpRequest имеет доступ к HTTP-заголовкам, в том числе к заголовку связанной с аудентификацией. и хотите сказать что аудентификация не связанна с авторизацией клиента на сервере? :-) ну этоже нонсенс. например, пока сервер не получил верных аудентифицирующих данных, он не станет разбирать тело HTTP-запроса.

> да, конечно, в 100 раз. По 100-мбитной сети сразу до 10Гб.

к сожелению нет :-( :-( . не такие цыфры.

> Вы даже не знаете, что интернет - это не только НТТР ...

ну да.. интернет это ещё и Jabber например.. и даже SMTP и IMAP... а кроме HTTP есть ещё например и HTTPS (и с ним ТОЖЕ XMLHttpRequest вполне работает, кстате).. ну и много там всяких разных использований интернета, но причём тут всё это?

Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

64. "Универсальный способ DoS-атаки, затрагивающий PHP, Java, Rub..."  +/
Сообщение от Аноним (??) on 31-Дек-11, 20:05 
Вот всегда находится какой-нибудь <вырезано цензурой>, который предлагает ошибки реализации исправлять переделывая протокол.
Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

71. "Универсальный способ DoS-атаки, затрагивающий PHP, Java, Rub..."  +1 +/
Сообщение от Аноним (??) on 02-Янв-12, 04:27 
Вот всегда находится какой-нибудь <вырезано цензурой>, который путает ошибки реализации с ошибками архитектуры.
Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

59. "Универсальный способ DoS-атаки, затрагивающий PHP, Java, Rub..."  +1 +/
Сообщение от Денис (??) on 31-Дек-11, 17:17 
Для php 5.2 тоже патчи вышли
https://github.com/laruence/laruence.github.com/tree/master/...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

74. "Универсальный способ DoS-атаки, затрагивающий PHP, Java, Rub..."  +/
Сообщение от Аноним (??) on 02-Янв-12, 21:18 
Уйдет в порты FreeBSD в 5.2.17_5 http://www.freebsd.org/cgi/query-pr.cgi?pr=163782 и в centos.alt.ru уже есть http://centos.alt.ru/?p=647
Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

75. "Универсальный способ DoS-атаки, затрагивающий PHP, Java, Rub..."  +/
Сообщение от Аноним (??) on 03-Янв-12, 10:20 
Я все жду когда в PHP появиться поддержка распарсить параметер по требованию. Что-то вроде $_POST->getParam. А распарсеные параметры уже закешировать в этих ваших HASH и хранить.

P.S. Кстати проблема только на ключах HASH я так понимаю?!

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

79. "Универсальный способ DoS-атаки, затрагивающий PHP, Java, Rub..."  +/
Сообщение от Аноним (??) on 03-Янв-12, 19:53 
> Я все жду когда в PHP появиться поддержка распарсить параметер по требованию.
> Что-то вроде $_POST->getParam. А распарсеные параметры уже закешировать в этих ваших
> HASH и хранить.

Какая хакеру разница, заткнется сервак сам по себе или по твоему требованию :)

Ответить | Правка | ^ к родителю #75 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру