Как устроить DoS атаку на сервер баз данных одной строчкой

[TravisBickle]

> Возможно если бы мы использовали True FastCGI, то у нас бы не было это проблемы, но php стал готов к этому всего несколько месяцев назад, а проблема существует уже около 6 лет.

Да, хотя бы потому что в phpDaemon есть свой независимый драйвер постгреса, написанный прямыми руками :-) Никаких левых запросов там не делается.

[kid]

PostgreSQLClient в phpDaemon несколько урезанный, например там не поддерживается биндинг переменных. Меньше функционала — меньше глюков :)

[TravisBickle]

Вы правы. Спасибо что обратили на это внимание. Спецификация протокола реализована полностью. Всё поддерживается, но не всё вынесено в отдельные методы. Если кому-нибудь понадобится биндинг, надеюсь напишут с чем его подают в PHP, я никогда не использовал.

[king2]

Его подают с PDO, например.

Без биндинга сразу же возникает куча проблем c SQL injects, поэтому как можно жить без него — вообще не представляю. Workarounds типа mysql_real_escape_string на каждый чих иначе, как извращенством, не назовешь…

Да и вообще, это же так удобно — скормить переменную запросу, будучи точно уверенным в том, что она всегда останентся «просто данными» и никогда не будет перемешана с самим запросом!

[AlienZzzz]

Используйте джангу)

[micle]

Не умеете? :)

[habraname]

занятная багофича :)

насколько я помню, из пхп убрали отдельные библиотеки драйверов мускуля и постгри, заменили их пдошными, а пдо встроили в «ядро»

[Chvanikoff]

Вы ошибаетесь — расширения для «простых» mysql и pgsql (php_mysql, php_pgsql) присутствуют в php 5.3.4. Равно как и PDO. Другое дело, что все наперебой кричат «истиный Дао в PDO» — это да…

[drunken]

А еще у кодеров принято делать запросы SELECT… LIKE '%something%'. Особенно замечательно это работает в MySQL при, скажем, 10 миллионах строк, когда вырастает база. Такие конструкции не задействуют индексы.

[bit]

Даже если в WHERE стоит ограничение по ключевым полям?
Но в главном вы правы — неразумное увлечение разными вкусными фенечками в запросах может дать весьма неприятный побочный результат в виде приличных тормозов.

[drunken]

Верно. А вот запрос вида SELECT… LIKE 'something%' уже будет работать с индексами.
Мне для одного из проприетарных продуктов пришлось использовать mysql-proxy и скрипт к нему на lua, чтобы реврайтить запросы, поскольку «чудо индийской школы программирования» умирало уже на 10.000 строках в базе, с прокси же удалось выжать все соки из БД, хотя и немного пожертвовав скоростью обработки.

[blacknot]

Или даже SELECT… LIKE '%something' если индекс построить в обратном порядке, есть такая фича

[king2]

Просто добавь OR и получи индексный LIKE в подарок!

[kid]

Тут вы не правы:

field like '%text' or field like 'text%'

это не то же самое что и

field like '%text%'

, например 'маша мыла раму' like '%мыла%'

[king2]

Да это шутка была :)

[kid]

:) но на первый взгляд счастье было так близко!

[bolk]

Время начала всплеска аномально высокого трафика подозрительно точно совпадало с временем выкладывания одного крупного релиза, что и навело на мысль о том что мы DDOS`им себя сами.

Вы себя DoS'или, а не DDoS'или.

[kid]

Точно! Спасибо сейчас поправлю.

[LionAlex]

Теперь знаю как тестировать PostgreSQL на нагрузку :)

[AlexTikhonov]

Ух, и все-таки с утра немного тяжело воспринимать DOS как DoS… а то прочитав заголовок задумался о том, как можно из-под DOS-а атаковать сервер баз данных одной строчкой… сразу в голове мысль о
:while
echo "...some..sql" > mysql
goto while

но это не одна строчка…

Но, возможно, это просто утреннее занудство от недосыпа :)

[kid]

:) спасибо, поправил для тех кто читает хабр по утрам

[DmitryKoterov]

Кстати говоря, с PDO есть такая проблема, что в нем пара prepare()+execute() вызывает 2 запроса к PostgreSQL-базе (первый — PREPARE, второй, соответственно, EXECUTE). Это означает и удвоение времени на мелких запросах (двойной пинг), и «подвисшие в воздухе» PREPARE в случае, если почему-либо до execute() дело не дошло, а соединение не успело открыться. Кроме того, опять же для PostgreSQL, PDO-шная пара prepare()+execute() убивает оптимизацию запроса на основе значений параметров (план запроса строится на этапе PREPARE, когда о реальных значениях параметров еще ничего не известно), так что ее еще и поэтому не стоит применять.

Так что для PostgreSQL единственный путь — это руками заменять placeholder-ы на заквоченные значения и посылать запрос в один прием. В этом отношении, получается, PDO теряет всю свою привлекательность по сравнению с pg_* функциями.

[VolCh]

Отнаследоваться от PDO изменив реализацию prepare/execute?