Восстановление из инъекции SQL

Question

Давай не будем говорить, что я параноик, но я час за часом изучал, как предотвратить SQL-инъекции (и XSS для этого).

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

Answer 1

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

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

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

Answer 2

Это очень опасный способ мышления. Да, атаки с использованием SQL-инъекций обычно разрушают базу данных и, таким образом, мгновенно разрушают ваше веб-приложение, после чего вы (несколько) весело восстанавливаете данные из резервной копии и продолжаете свой (несколько) веселый путь.

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

Хуже того, атака с использованием SQL-инъекции может быть предназначена для кражи данных, а не для их повреждения. Злоумышленник может выяснить, как заставить ваш веб-сайт доставлять несколько номеров кредитных карт в ответ на номинальный запрос на изменение своего профиля.

Answer 3

Другие люди отметили, что вы частично решили проблему с данными потеря (восстановление из, возможно, последнего резервного копирования), но пропустили проблему с данными кража .

Есть еще одна потенциальная проблема. Многие SQL-серверы позволяют выполнять произвольные системные команды (например, MS SQL ). Другие (например, MySQL ) позволяют писать произвольные файлы (см. Также эту статью по использованию инъекций MySQL). Суть в том, что атака с использованием SQL-инъекции может поставить под угрозу всю систему, а затем и далее. Конечно, есть варианты конфигурации, позволяющие отключить некоторые из них, но они действительно беспокоят.

Если вам нужны рекомендации, я предлагаю PDO с подготовленными заявлениями .

Answer 4

Да, если таблица не содержит данных, чувствительных к пользователю и / или введенных XSS. Тогда вам нужно решить еще одну проблему. Всегда обрабатывать для инъекций SQL при построении запросов SQL и всегда очищать для инъекций XSS при отображении управляемых клиентом данных в выводе HTML.