Написание межсетевого экрана базы данных для блокировки атак SQL-инъекций

Question

Я изучаю и исследую различные методы SQL-инъекций и контрмер.

Проверка HackerOne Hacktivities показал мне, что веб-приложению недостаточно просто использовать WAF (например, Cloudfront, cloudflare, Akamai, ...), потому что хакеры используют и создают обходные нагрузки WAF для преодоленияэти технологии для успешной атаки.

В Интернете искали ключевое слово Брандмауэр базы данных , но большинство ссылок были связаны с брандмауэром Oracle Database.

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

Какие методы или методы в дополнениес языком программирования вы предлагаете мне написать такое приложение, и вы предлагаете мне начать исследование и написание низкоуровневого брандмауэра приложений (например, примеров, доступных в наборе драйверов Windows) или брандмауэров уровня приложений?

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

Заранее спасибо.

Answer 1

Я предлагаю этот ресурс на OWASP и презентации, на которые он ссылается.https://www.owasp.org/index.php/WASC_OWASP_Web_Application_Firewall_Evaluation_Criteria_Project

WAF может обрабатывать многие типы проблем безопасности, не ограничиваясь внедрением SQL.Например, XSS, CSRF, отравление cookie и т. Д. Они не обязательно имеют какое-либо отношение к базам данных.

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

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

Последние версии продукта Oracle сместили фокуск белому списку.То есть, признайте, что он слишком подвержен ошибкам для алгоритмического обнаружения плохого контента.Вместо этого обучите брандмауэр базы данных, какие запросы, как известно, являются законными для данного приложения.

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

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

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

ModSecurity является примером WAF с открытым исходным кодом, который включает некоторые функции обнаружения SQL-инъекций.Это модуль для сервера Apache http.

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

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