Что такое SQL-инъекция? Как предотвратить атаки SQLi
Опубликовано: 2023-09-15Веб-приложения обеспечивают нашу работу в Интернете изо дня в день. Мы общаемся, взаимодействуем, делаем покупки и смотрим забавные видеоролики о кошках — и все это с помощью веб-приложений. Они предоставляют жизненно важные бизнес-услуги и хранят конфиденциальные данные, но чем больше мы что-то используем, тем более уязвимыми становятся атаки.
Одной из кибератак, на которые следует обратить внимание в приложениях, использующих уязвимости языка структурированных запросов (SQL), является распространенная и опасная SQL-инъекция.
Что такое SQL-инъекция?
SQL-инъекция (SQLi) — это вредоносная техника внедрения кода, которую киберзлоумышленники используют для использования уязвимостей в веб-приложениях. Они используют слабые места для получения несанкционированного доступа, добавляя строку вредоносного кода в запрос к базе данных.
Атаки с использованием SQL-инъекций приводят к неправомерному доступу к данным, манипуляциям, краже личных данных, финансовым потерям, ущербу репутации и юридическим последствиям. Разработчики и организации должны понимать риски и принимать полные меры безопасности. Такие инструменты, как программное обеспечение брандмауэров веб-приложений (WAF) и программное обеспечение цифровой криминалистики, предназначены для защиты от атак с внедрением SQL-кода. Компании также могут рассчитывать на комплексные пакеты безопасности веб-сайтов для защиты своих приложений.
Прочтите эту шпаргалку по внедрению SQL, чтобы узнать, как выполняются SQL-атаки с примерами, их вариантами и как предотвратить такие атаки.
Чем опасны атаки с использованием SQL-инъекций?
SQL-инъекция уже много лет входит в десятку крупнейших рисков безопасности веб-приложений по версии Open Worldwide Application Security Project (OWASP). Только в 2022 году OWASP обнаружил более 274 000 случаев внедрения той или иной формы в протестированных ими приложениях; Наиболее распространенными были SQL-инъекция и межсайтовый скриптинг (XSS).
Злоумышленники могут использовать SQL-инъекции, чтобы вызвать:
- Ошибки в веб-приложениях из-за изменения или удаления информации в базе данных.
- Нарушение данных, если хакеры получают несанкционированный доступ к конфиденциальным данным, хранящимся в базах данных, таким как личная информация, финансовые записи или пароли.
- Скомпрометированные системы путем доступа к дополнительным неавторизованным системам, использующим те же общие базы данных. Это позволяет злоумышленникам распространять свои атаки на другие системы в той же сети или выполнять распределенный отказ в обслуживании (DDoS).
Эти деструктивные действия наносят непоправимый ущерб бизнесу. Преступления ставят под угрозу конфиденциальность и целостность данных, что приводит к потере доверия клиентов и деловой репутации. Это также увеличивает финансовое бремя для компании, занимающейся устранением последствий.
Реальные примеры атак с использованием SQL-инъекций
Прошло более двух десятилетий с тех пор, как SQL-инъекция впервые появилась на сцене. Двадцать лет спустя это по-прежнему пользуется дурной славой, о чем свидетельствуют следующие известные инциденты с внедрением SQL-кода.
- Heartland Payments Systems: В 2008 году Heartland Payments Systems пострадала от одной из крупнейших утечек данных в истории: в результате атаки SQLi были раскрыты более 130 миллионов данных кредитных и дебетовых карт. Хартленд заплатил миллионы штрафов.
- Yahoo : В 2012 году в результате атаки SQL-инъекцией были скомпрометированы данные учетных записей почти 5 миллионов пользователей Yahoo, включая адреса электронной почты и пароли.
- Freepik: Хакеры украли электронные письма и пароли 8,3 миллиона пользователей Freepik и Flaticon в 2020 году во время атаки с помощью SQL-инъекций на веб-сайт Flaticon компании.
- WooCommerce: популярный плагин WordPress исправил уязвимость SQL-инъекции, которая подвергала 5 миллионов сайтов риску кражи данных.
- BillQuick: Киберпреступники использовали слепую уязвимость SQL в популярной биллинговой платформе для распространения программ-вымогателей.
- MOVEit: В мае 2023 года банда вымогателей Cl0p использовала уязвимость SQL-инъекции в программном инструменте управляемой передачи файлов MOVEit, затронув более 1000 организаций и по меньшей мере 60 миллионов человек, что сделало это крупнейшей утечкой данных за год.
Как работает атака с помощью SQL-инъекции?
Давайте рассмотрим основы баз данных и SQL-запросов, которые мы используем в современных веб-приложениях. Это поможет нам лучше понять внутреннюю работу SQL-инъекции.
Все веб-сайты используют реляционные базы данных, также называемые базами данных SQL, для хранения данных о своих пользователях и приложениях. Это может быть информация пользователя, учетные данные для входа, платежная информация или что-либо еще о компании. Возьмем, к примеру, веб-сайт электронной коммерции. Он хранит данные о продуктах, учетные записи пользователей, данные заказов и информацию о платежах в своей базе данных.
Затем веб-сайты берут данные из этих баз данных и предоставляют контент или услуги, специфичные для пользователей. Этот процесс происходит благодаря SQL — стандартизированному языку программирования, используемому для управления базами данных. Всякий раз, когда вам нужно получить что-то из приложения, скажем, историю покупок, вы фактически делаете запрос к базе данных с помощью SQL-запросов — команды, которая инструктирует базу данных выполнить определенное действие.
Пытаясь сделать веб-взаимодействие беспрепятственным, многие веб-сайты позволяют пользователям вводить данные для выполнения SQL-запросов. Это может включать в себя такие вещи, как условия поиска, имена пользователей или платежные реквизиты.
Рассмотрим пример веб-сайта электронной коммерции. Простой SQL-запрос для отображения истории ваших заказов из базы данных с таблицей «заказы» (o) и таблицей «продукты» (p) будет следующим:
ВЫБЕРИТЕ o.order_id, o.order_date, p.product_name, p.price
ИЗ заказов о
ПРИСОЕДИНЯЙТЕСЬ к продуктам p ON o.product_id = p.product_id
ГДЕ o.user_id = 12345;
Этот код SQL выбирает идентификатор и дату заказа из таблицы заказов, а также название продукта и цену из таблицы продуктов для USER ID 12345 из базы данных веб-сайта. Обычно идентификатор будет основан на вводе пользователя. Проблемы возникают, когда ввод не проверяется и не контролируется должным образом. Злоумышленники используют эту уязвимость для проведения атаки с помощью SQL-инъекции.
Вот как это обычно происходит.
- Выявление уязвимых полей ввода. Злоумышленники начинают с поиска полей ввода в веб-приложении, куда они потенциально могут внедрить вредоносный код. Они отправляют разные значения и смотрят, как реагирует приложение. чтобы узнать, есть ли. Если приложение не проверяет или не очищает вводимые пользователем данные должным образом, приложение обрабатывает вводимые данные как код SQL. Эта потенциальная уязвимость используется для внедрения кода.
- Внедрение кода посредством пользовательского ввода. Поняв, как приложение обрабатывает вводимые данные, злоумышленники создают полезную нагрузку, которая представляет собой фрагмент вредоносного кода SQL, использующий уязвимость. Сюда входит добавление управляющих символов SQL, таких как одинарная кавычка ('), двойная кавычка (") или равенство (=), для изменения структуры запроса SQL. Использование этих управляющих символов с распространенными командами SQL, такими как SELECT и FROM, позволяет злоумышленникам получить доступ к данным с сервера базы данных или получить их.
Затем они отправляют специально созданные входные данные вместе с законными запросами, обманывая приложение, заставляя его рассматривать сомнительный код как законную часть запроса. - Выполнение: база данных, не подозревая об атаке, обрабатывает запрос и выполняет внедренный код, как если бы это был законный запрос.
- Эксплуатация: в зависимости от намерений злоумышленника внедренный код SQL может получить конфиденциальные данные, изменить или удалить информацию или даже предоставить несанкционированный доступ. Это ставит под угрозу безопасность приложения и потенциально раскрывает конфиденциальную информацию.
Пример SQL-инъекции
Рассмотрим веб-приложение, которое использует параметр URL-адреса для получения сведений о продукте на основе идентификатора продукта, например:
http://example.com/products?id=1
Злоумышленник может попытаться внедрить вредоносный код SQL, чтобы вызвать ошибку и получить следующую информацию: http://example.com/products?id=1' ИЛИ 1=1; –
Если приложению не удается должным образом проверить и очистить вводимые пользователем данные, SQL-запросом можно манипулировать следующим образом:
ВЫБРАТЬ * ИЗ товаров ГДЕ ИЛИ 1=1; - - ';
В этом случае исходный запрос был разработан для получения продукта с идентификатором 1, но входные данные злоумышленника изменяют запрос, чтобы он возвращал все продукты, из-за добавления 1=1 и добавленного двойного дефиса (- -). Это аннулирует исходную закрывающую одинарную кавычку и приводит к отображению всех сведений о продукте или сообщениям об ошибках, которыми могут воспользоваться злоумышленники.
33%
критических уязвимостей веб-приложений в 2022 году были вызваны SQL-инъекциями.
Источник: Статистика
Широкое распространение уязвимостей SQL и привлекательность базы данных веб-приложений со всеми критически важными для бизнеса данными делают внедрение SQL-кода одной из самых устойчивых кибератак.
Источник: Spiceworks
Типы SQL-инъекций
Существует три основных типа атак с использованием SQL-инъекций в зависимости от того, как злоумышленники получают информацию или взаимодействуют с базой данных:
- Классический или внутриполосный SQLi
- Слепой или логический SQLi
- Внеполосный SQLi
1. Классический или внутриполосный SQLi.
Внутриполосная атака является наиболее распространенным типом SQL-инъекций. Классический хакер использует тот же канал связи (внутриполосный) для внедрения вредоносного кода SQL и получения результатов. Двумя основными вариантами внутриполосного SQLi являются:
Внутриполосный SQLi на основе объединения
Эта атака использует оператор UNION SQL, используемый для объединения данных из результата двух или более операторов SELECT. Сделав это, злоумышленники могут получить данные из таблиц, к которым у них нет прямого доступа.
Внутриполосный SQLi на основе ошибок
В этом методе злоумышленник намеренно вызывает ошибки в запросе SQL, чтобы использовать сообщения об ошибках, возвращаемые базой данных. Ошибки могут раскрыть ценную информацию о структуре базы данных, именах таблиц, имен столбцов, а иногда и самих данных. SQLi на основе ошибок также может выполняться как внеполосный SQLi.
2. Инференциальный (слепой) SQLi
При использовании слепого SQLi злоумышленник не может напрямую увидеть результаты своей атаки. Вместо этого они получают информацию, наблюдая за поведением приложений или сообщениями об ошибках, которые отвечают на их запросы. Этот тип атаки требует много времени, поскольку хакерам приходится выполнять серию SQL-запросов, чтобы найти потенциальные уязвимости для использования. Два варианта слепого SQLi:
Слепой SQLi на основе времени
Здесь злоумышленники задают запросы, которые заставляют базу данных задерживать ответ, прежде чем она отреагирует. Они получают информацию о базе данных, обращая внимание на время отклика.
Булев слепой SQLi
В случае с логическим слепым SQLi злоумышленники пользуются тем, как приложение реагирует на истинные или ложные условия в SQL-запросах. На основе ответов веб-приложения они выводят информацию о базе данных, даже если данные из базы данных не возвращаются.
3. Внеполосный SQLi
Внешняя атака SQLi заставляет приложение отправлять данные на удаленную конечную точку, контролируемую хакерами. Подобная атака требует, чтобы серверы SQL имели определенные функции, например, возможность инициировать запросы внешней сети, такие как запросы протокола передачи гипертекста (HTTP).
Как предотвратить атаки SQL-инъекцией: шпаргалка
Для предотвращения внедрения SQL-кода требуется многоуровневый подход, включающий практику безопасного кодирования и постоянный мониторинг. Вот шпаргалка с основными шагами, которые помогут защитить вас от атак с использованием SQL-инъекций.
Используйте подготовленные операторы
Основной защитой от атак SQL-инъекций являются подготовленные операторы с параметризованными запросами. Подготовленные операторы гарантируют, что вводимые пользователем данные обрабатываются как данные, а не как исполняемый код.
Разработчики заранее компилируют SQL-коды для запросов в виде шаблонов с заполнителями для вводимых пользователем значений. Во время выполнения запроса подготовленные операторы связывают фактические значения вместо заполнителей. Это останавливает выполнение вредоносного кода.
Подготовленные операторы предпочтительнее динамических операторов SQL. Они пишут SQL-запросы во время выполнения, что ослабляет их против атак путем внедрения.
Подготовленные операторы на популярных языках программирования:
Вот рекомендации для конкретного языка по использованию подготовленных операторов (параметризованных запросов) в популярном программировании баз данных:
- Корпоративная версия Java (EE): используйте класс ReadedStatement из пакета java.sql. Привяжите параметры, используя такие методы, как setString , setInt и т. д.
- Python (SQLite3) : используйте заполнители ( ? ) в запросах. Свяжите параметры с помощью кортежа или списка .
- PHP: используйте расширение объектов данных PHP (PDO) . Используйте подготовленные операторы с заполнителями (:). Привяжите параметры с помощью функции «bindValue» или «bindParam» .
- .NET : используйте объект MySqlCommand . Привяжите параметры с помощью Parameters.AddWithValue .
Еще один метод предотвращения SQL-инъекций — использование хранимых процедур или группы предварительно скомпилированных кодов SQL, которые можно использовать снова и снова.
Практика проверки ввода
Проверка ввода включает проверку ввода пользователя, чтобы убедиться, что он соответствует определенным критериям перед обработкой. Список разрешений, также известный как белый список, является ключевым аспектом проверки ввода. Здесь в качестве части SQL-запросов принимаются только предопределенные безопасные значения или шаблоны. Любые входные данные, не соответствующие установленным критериям, отклоняются. Это активно предотвращает попадание в систему вредоносных или неожиданных данных.
Используйте библиотеки объектно-реляционного сопоставления
Библиотеки объектно-реляционного сопоставления (ORM) — ценные инструменты для разработчиков, работающих с реляционными базами данных. Они позволяют разработчикам взаимодействовать с базами данных, используя язык программирования по своему выбору, тем самым уменьшая необходимость написания необработанных SQL-запросов. Библиотеки ORM обеспечивают встроенную защиту от атак SQL-инъекций.
Обучите разработчиков и ИТ-команды методам безопасного кодирования. Обязательно проводите регулярные проверки безопасности и тестирование на проникновение для обнаружения уязвимостей.
Совет. Помогите своим программистам и разработчикам быстрее освоить безопасное программирование с помощью инструментов обучения безопасному программированию.
Соблюдайте принцип наименьших привилегий
Принцип наименьших привилегий дает пользователям базы данных только минимальные разрешения, необходимые для выполнения их работы. Следование этому принципу снижает воздействие потенциальных атак с использованием SQL-кода или любых кибератак, если уж на то пошло. Кроме того, примените строгий контроль доступа к вашей базе данных.
Развертывание брандмауэра веб-приложений (WAF)
WAF отслеживает входящий сетевой трафик приложений и блокирует потенциально вредоносный трафик на основе списка известных сигнатур атак.
Пять лучших инструментов брандмауэра веб-приложений (WAF):
- Брандмауэр веб-приложений Azure
- АВС ВАФ
- Брандмауэр веб-приложений Imperva (WAF)
- Спектр облачных вспышек
- Брандмауэр веб-приложений Symantec и обратный прокси-сервер
* Выше приведены пять ведущих решений WAF из отчета G2 о летних таблицах 2023 года.
WAF использует предопределенные правила для обнаружения подозрительных шаблонов и аномалий во входящем трафике, таких как ключевые слова SQL и вредоносные полезные данные. Он очищает и проверяет вводимые пользователем данные, а также блокирует или отфильтровывает вредоносные запросы. Это помогает остановить опасные SQL-запросы при их поступлении в систему.
Современные WAF адаптируются к новым методам атак с использованием машинного обучения.
Другие инструменты безопасности для предотвращения атаки SQL-инъекцией
Помимо WAF, атакам с внедрением SQL-кода препятствуют несколько других платформ безопасности.
- Сканеры уязвимостей ищут известные и неизвестные уязвимости в веб-приложениях.
- Инструменты статического тестирования безопасности приложений (SAST) и программное обеспечение для статического анализа кода находят уязвимости безопасности без фактического выполнения кода.
- Программное обеспечение для динамического тестирования безопасности приложений имитирует атаки на работающие приложения и выявляет слабые места.
- Системы обнаружения и предотвращения вторжений, а также программное обеспечение для цифровой криминалистики расследуют аномалии и атаки на приложения в режиме реального времени.
Защитите свои крепости данных
Атаки с помощью SQL-инъекций представляют серьезную угрозу безопасности веб-приложений. В случае успеха атак компании рискуют потерять ценные данные, конфиденциальность пользователей и свою хорошую репутацию.
Хотя ни одно решение не гарантирует абсолютную безопасность от SQL-инъекций, сочетание профилактических мер, о которых мы здесь говорили, значительно снижает вероятность атак. Веб-разработчикам и администраторам баз данных следует применять строгие меры защиты и защищать свои веб-приложения от потенциальных атак.
Хотите комплексное решение для защиты вашего сайта? Узнайте о программном обеспечении веб-безопасности и о том, как оно помогает в борьбе с кибератаками, приводящими к утечке данных.