Атаки типа SQL-инъекции возникают, когда ненадежные пользовательские данные выполняются как часть SQL-запроса из-за опасных практик написания кода. В этой статье рассмотрена основная причина и сопутствующие факторы SQL-инъекций, а также объясняется, как DAST помогает выявлять и предотвращать эти уязвимости.
SQL-инъекция возможна только тогда, когда неочищенные пользовательские данные напрямую вставляются в динамически сформированные SQL-запросы. Эта уязвимость позволяет злоумышленникам изменить структуру запроса, получить несанкционированный доступ к данным или выполнить другие команды базы данных. Уязвимое приложение воспринимает входящие данные пользователя как исполняемый код. Это открывает путь к одной из самых распространенных и опасных проблем безопасности.
Пример SQL-инъекции
Пример приведен в учебных целях для лучшего понимания специалистов по безопасности, как предотвратить такие атаки. Эта статья не призывает к противоправным действиям.
Прежде чем перейти к причинам недочета, ниже приведен простой пример на PHP с уязвимым запросом в процессе входа. Можно предположить, что имя пользователя и пароль были взяты из отправленной формы входа и эти значения непосредственно вставлены в строку SQL-запроса следующим образом:
$username = $_POST['username'];
$password = $_POST['password'];
$query = "SELECT * FROM users WHERE username = '$username' AND password = '$password'";Обычно приложение пришлет такой запрос в базу данных, и если результат не пуст – учетные данные правильны. Чтобы обойти эту проверку, злоумышленник может вставить полезную нагрузку SQL-инъекции как имя пользователя, как в примере ниже (завершая символом комментария, чтобы обойти оставшуюся часть запроса после инъекции):
' OR 1=1;--В результате SQL-запрос будет выглядеть так:
SELECT * FROM users WHERE username = '' OR 1=1;-- AND password = ''Поскольку условие 1=1 всегда истинно, а проверка пароля прокомментирована, этот запрос обходит аутентификацию и может предоставить несанкционированный доступ. Добавление базовой проверки поможет усложнить атаку, но правильное решение – использование параметризованных запросов, которые четко отделяют входящие пользовательские данные от исполняемого кода.
Причины SQL-инъекций
Хотя основная причина SQL-инъекций – небезопасная обработка входящих данных от пользователя в SQL-запросах, существуют дополнительные факторы, способствующие возникновению этой уязвимости. Их понимание помогает выявить слабые места в ранних этапах разработки приложений.
Недостаточная проверка и очистка входящих данных
Если программа не проверяет или не очищает входящие данные пользователей, злоумышленник может вставить вредоносные SQL операторы в поля для обычных данных. Без валидации приложение не может отличить легитимные данные от вредных, что позволяет опасным командам попасть в базу данных.
Неправильное использование динамического SQL
Формирование SQL-запросов по конкатенации строк (соединение двух или более строк в одну) с входящими данными пользователя создает высокий риск. Построение запроса таким образом включает необработанные пользовательские данные в логику запроса, что дает возможность злоумышленникам ими манипулировать. Использование параметризованных запросов или подготовленных операторов является более безопасной альтернативой, обеспечивающей разделение кода и данных.
Кодирование, которое не учитывает контекст
Кодирование исходных данных должно соответствовать контексту их использования. К примеру, HTML-кодирование уместно для веб-страниц, но входящие данные SQL-запроса должны кодироваться как часть процесса параметризации, а не вручную. Неправильное использование или пропуск кодирования при построении опасного запроса значительно увеличивает риск инъекции, поскольку база данных или программа могут неправильно нейтрализовать вредные входящие данные.
Опасный устаревший код
Старые программы часто используют жестко закодированную логику SQL и устаревшие практики разработки. Они могут не проводить проверку входящих данных, применять опасные конструкты написания кода или даже использовать старые версии баз данных с известными уязвимостями. Без обновления такие программы становятся постоянным источником риска.
Чрезмерные привилегии базы данных
Если приложение подключается к базе данных с правами администратора или расширенным доступом, злоумышленник может получить доступ к системным таблицам, не предназначенным для использования. В такой ситуации любая успешная инъекция может привести к значительному ущербу. Ограничение привилегий базы данных только до того, что необходимо для каждой операции, является критически важным средством контроля, помогающим уменьшать влияние потенциальных эксплойтов. Это также включает в себя запуск самого процесса базы данных из ограниченной учетной записи, а не из root.
Неправильная обработка ошибок
Предоставление пользователям подробных сообщений об ошибках может дать злоумышленникам представление о структуре базы данных, что облегчает создание успешных полезных нагрузок SQL-инъекций. Правильная обработка ошибок гарантирует безопасное создание логов внутренних проблем, возвращая конечным пользователям только общие сообщения. В некоторых случаях злоумышленники могут обнаруживать ошибки косвенно на основе изменений времени реакции базы данных, что позволяет проводить слепые SQL-инъекции.
Недостаточное тестирование безопасности
Без регулярного тестирования безопасности SQL-инъекции легко пропустить. Статический анализ – это первый шаг, но проверка кода сама по себе не может предположить, как входящие данные пользователя попадут в запросы. Любые пробелы в динамическом тестировании безопасности как автоматизированном, так и ручном значительно увеличивают риск попадания невыявленных уязвимостей в продакшн.
Предотвращение SQL-инъекций благодаря DAST
Самый эффективный способ предотвратить SQL-инъекции – совместить безопасные практики написания кода с тестированием запущенных веб-сайтов. Именно здесь немаловажную роль играет DAST (динамическое тестирование безопасности приложений).
Подход DAST, поддерживаемый Invicti (ранее Netsparker), позволяет увидеть риски, которые можно эксплуатировать, благодаря тестированию приложений в реальных условиях. С помощью технологии Proof-based сканирования Invicti автоматически подтверждает найденные уязвимости, уменьшая количество ложноположительных срабатываний и ускоряя исправление.
Интегрируя DAST в процесс разработки, организации могут обнаруживать и устранять SQL-инъекции до того, как ими воспользуется злоумышленник. Это практическая и масштабируемая стратегия для борьбы с одной из давнейших, но до сих пор самых опасных угроз веб-безопасности.
