Я унаследовал очень небезопасное веб-приложение на php с историей внедрения sql. Я не могу исправить сценарии сразу, мне нужно, чтобы они работали, чтобы веб-сайт работал, а слишком много сценариев php, с которыми нужно работать сначала с конца php. Однако у меня есть полный контроль над сервером и программным обеспечением на сервере, включая полный контроль над базой данных mysql и ее пользователями.
Давайте оценим это примерно в 300 скриптов в целом, 40 получастных скриптов и 20 частных / безопасных скриптов.
Итак, мой вопрос: как лучше всего защитить данные с неявным предположением, что внедрение sql со стороны php (например, где-то в этом списке из 300 скриптов) неизбежно?
Мой первый черновой план состоит в том, чтобы создать в базе данных mysql несколько уровней разных пользователей с правами доступа. Таким образом, я могу защитить данные и сценарии, которые больше всего нуждаются в защите (категория «частные / безопасные»), затем второй уровень таблиц и сценариев базы данных («получастные») и, наконец, заняться безопасностью остальная часть приложения php в целом (с результатом окончательной защиты таблиц базы данных, которые по существу имеют дело с «общедоступной» информацией, например, с вещами, которые требуются даже при простом просмотре домашней страницы).
Итак, 3 пользователя базы данных (общедоступные, получастные и безопасные) с разными пользователями, подключающимися для каждой из трех разных групп сценариев (безопасные сценарии, получастные сценарии и общедоступные сценарии). Таким образом, я могу предотвратить любой доступ к «защищенному» из «общедоступного» или «получастного», а также к «получастному» из «общедоступного». Есть ли другие альтернативы, которые мне следует изучить? Если использовать многоуровневую систему доступа, какие подходы лучше всего?
Ответ прост: «На уровне базы данных невозможно защитить себя от SQL-инъекций». Как только они подключатся к базе данных с запросом на руках, ваша БД будет его выполнять - если кто-то привнес в этот SQL неприятности, лучшее, на что вы можете надеяться, - это уменьшить ущерб, который они могут нанести.
С точки зрения смягчения ущерба то, что вы уже описали, является отличным подходом: ограничьте каждый сценарий использованием учетной записи пользователя базы данных, которая ограничена минимальным доступом, который требуется для сценария (выбор, вставка, обновление, удаление и только определенное подмножество таблиц, которые сценарий должен прикоснуться).
Это не защищает вашу базу данных от SQL-инъекций - это просто ограничивает количество данных, которые кто-то может украсть (или уничтожить) на основе скомпрометированного сценария. Решительный злоумышленник, вероятно, первым нападет на «интересные» скрипты, которые в первую очередь содержат нужные им данные.
Что касается непредвиденных проблем, разделение на роли пользователей может обеспечить лишь минимальный выигрыш в безопасности (если у вас есть много сложных межтаблических запросов и сценариев, которые выполняют несколько задач) с риском поломки сервера (особенно если у вас много сложных кросс-табличных запросов сценариев, которые выполняют несколько задач).
Стоит отметить, что аудит вашей базы данных на этом уровне, вероятно, займет столько же времени (если не больше), чем замена всех ваших текущих вызовов правильными параметризованными запросами, которые делают атаки SQL-инъекций трудными или невозможными.
Я бы порекомендовал вам взглянуть на PHP-IDS http://phpids.org/ . Он не заменит защиты скриптов и не предотвратит все атаки, но это действительно фантастическая повязка, если вы должны применить защитную повязку. Это расстроит хакеров и заставит их перейти к следующей цели. Это никого не остановит.
Лучше всего угадать:
В сочетании с mod_security это очень поможет.
Ваша стратегия разбиения на разделы верна на 100%. Однако не ограничивайтесь SQL-инъекциями, потому что, если они есть, вероятно, есть и другие классы атак. Повышение привилегий, например, или захват сеанса? Вы можете обнаружить, что разбиение на разделы сложнее, чем предполагалось вначале, в зависимости от характера дизайна сайта.
В конце концов, нужно перекусить и просто перекодировать его.
Тебе нужно GreenSQL. Я никогда не использовал его сам - во всяком случае, в производственной среде, но он действует как запрос для MySQL и отфильтровывает опасные запросы, указывающие на внедрение SQL.
mod_security для apache или IDS / IPS модули аппаратного брандмауэра будут анализировать запросы, блокируя потенциальные SQL-инъекции. Но я уверен, что другие комментаторы подробно объяснят риски.
Вы можете (если у вас есть талант, время или ресурсы) написать прокси-сервер базы данных, который будет находиться между базой данных и сценариями PHP и отфильтровывать сомнительные запросы SQL. Если все или большинство сценариев PHP вызывают одни и те же библиотеки API базы данных, я бы рекомендовал реализовать там фильтры. Обязательно создайте файлы патчей (используя diff), чтобы при обновлении API БД PHP вы могли повторно применить свои изменения.
Вы могли бы использовать Прокси MySQL для проверки / изменения всех запросов на лету. Может быть трудно предотвратить интеллектуальный анализ данных D, но вы могли бы хотя бы удалить все DROP, например.