MySQL<5.0 и SQL Injection

Question

[eafanasov]

В MySQL версии 5.0 и выше появилась схема INFORMATION_SCHEMA.
При проведении атаки типа SQL Injection данные из этой схемы позволяют получить названия таблиц и колонок в других схемах со всеми вытекающими…
Возникает парадокс: web-приложение, использующее более древнюю версию MySQL, лучше защищено от атаки типа SQL Injection.

Насколько верно такое утверждение?

Answer 1

[FanatPHP]

Очень часто люди путают само понятие инъекции и эксплуатацию уже совершённой инъекции. Эти два понятия как бы «склеиваются» в голове, но на самом деле между ними практически нет ничего общего:
— атака типа «SQL инъекция» — это принципиальная возможность внедрить свой код в запрос.
— эксплуатация — это уже то, какой конкретно код внедрять.

И здесь сразу становится видно, что вопрос сформулирован некорректно: к атаке INFORMATION_SCHEMA отношения не имеет. А только к эксплуатации. Поэтому и парадокса никакого нет. От инъекций обе версии защищены одинаково — как правильно сказано в ответе выше — настолько, насколько защищено приложение.

Comments

[rozhik]

+1
Почти всегда чем новее (читать функциональнее) ПО — тем более просто эксплуатировать уязвимости и тем критичнее могут быть результаты.

[eafanasov]

«Принципиальная возможность» внедрить свой код в запрос называется уязвимостью.
Атака — это эксплуатация уязвимости.

Так что INFORMATION_SCHEMA имеет самое прямое отношение к атаке.
Наличие этой схемы повышает вероятность успешной реализации атаки.

Answer 2

[calg0n]

Утверждение неверно. От атак типа SQL Injection защищать должно веб-приложение, а не сама БД.

Answer 3

[rozhik]

Никто не мешает в самых древних версиях делать show databases; show tables; describe table… Итп.
База в принципе не может защищать от SQL Injections.
Но никто не мешает делать несколько SQL пользователей с разными правами. Хотя как по мне за строительство SQL с помощью конкатенаций нужно вырывать руки (за исключением случаев, где меняется структура самого запроса)

Comments

[rakot]

Я несколько отстал от современных тенденций SQL injection, но классический SQL Injection подразумевал union с подбором имен параметров, имени таблицы, кол-ва полей, сейчас разве не так?

[stan_jeremy]

show databases и тд и тп будут возможны только если разрешены так называемые stacked queries для данного драйвера мускула, обычно они как раз запрещены. Да и какой шанс того что инъекция будет такая, что позволит вам еще и вывести (на экран, в файл и тд) второй запрос?

rakot Вы правы. Частично. Кроме юниона есть error based, one char bruteforce и прочие техники — на одном юнионе мир не завязан. Некоторые из них, например, позволяют получить названия колонок в <5.0, все зависит от самой инъекции как минимум.

Answer 4

[eafanasov]

Спасибо всем за ответы.

Позволю себе уточнить: под атакой типа SQL Injection я имел в виду не потенциальную возможность внедрения SQL-кода в запрос, а уже сам факт получения конкретных данных (из конкретного столбца/строки таблицы).
И в этом случае очевидно, что использование INFORMATION_SCHEMA избавляет нас от ручного перебора названий таблиц/столбцов/строк.
Таким образом, наличие этой самой схемы предоставляет возможность с более высокой вероятностью завершить атаку успешно.

Разумеется, я понимаю, что защиту от SQL Injection должно реализовывать web-приложение, а не сама БД. Но мой вопрос как бы не об этом.

Comments

[FanatPHP]

Не нужно иметь в виду то, чего не существует. Атака — это внедрение.
Внедрить код INFORMATION_SCHEMA не помогает.
Остальное — софистика, которая путает причину со следствием.

Я не знаю, кто придумал этот вопрос, какого ответа он ждёт, и — главное — какие практические выводы собирается из него делать, но таких вопросов я ему могу насочинять миллион. В 5-й версии РНР была очень сильно повышена производительность. Значит, вирус, написанный на РНР, будет исполняться быстрее, и сможет заразить больше компьютеров. Получается, новая версия опаснее старой!

[eafanasov]

пожалуй, да.
причинно-следственная связь у меня странная получилась.
спасибо за хороший пример.

Answer 5

[akamajoris]

INFORMATION_SCHEMA не для защиты создавалась, поэтому говорить тут не о чем.

Comments

[eafanasov]

Я нигде не писал, что INFORMATION_SCHEMA создавалась для защиты.
Я писал про парадокс, заключающийся в том, что наличие этой схемы у более новых версий MySQL упрощает атаку типа SQL Injection.