SQL-Инъекции

Всех приветствую! На связи админ канала Falcon Bytes!

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

База данных — это как огромный электронный шкаф, в котором можно хранить информацию. Она помогает организовать данные так, чтобы их было легко найти, изменить или удалить. Такие данные могут быть о людях, продуктах, заказах и многом другом. Когда вы, например, регистрируете свои данные на сайте или делаете покупку онлайн, эти сведения обычно сохраняются в базе данных для последующего доступа и обработки.

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

Используя SQL-Инъекцию злоумышленник может получить возможность:

Получение конфиденциальной информации пользователей, например пароли, логины и прочее
Изменение данных
Выполнение произвольных команд
Полное удаление всех записей из базы данных
Логин от имени другого пользователя без пароля

И это даже не полный список возможностей. Согласитесь, это достаточно опасная уязвимость.

Примеры SQL-инъекций

Существует широкий спектр уязвимостей, атак и методов SQL-инъекций, которые возникают в различных ситуациях.

Некоторые распространенные примеры инъекций SQL включают:

Получение скрытых данных, когда вы можете изменить SQL-запрос, чтобы вернуть дополнительные результаты.
Подрыв логики приложения, когда можно изменить запрос, чтобы вмешаться в логику приложения.
Атаки UNION, когда можно получить данные из разных таблиц базы данных.
Изучение базы данных, когда можно получить информацию о версии и структуре базы данных.
Слепая SQL-инъекция (Blind sqli), когда результаты контролируемого вами запроса не возвращаются в ответах приложения.

Извлечение скрытых данных

Рассмотрим приложение для покупок, которое отображает товары в различных категориях. Когда пользователь нажимает на категорию "Подарки", его браузер запрашивает URL-адрес:

https://falcon-bytes.github.io/?category=Gifts

Это заставляет приложение выполнить SQL-запрос для получения информации о соответствующих товарах из базы данных:

SELECT * FROM products WHERE category = 'Gifts' AND released = 1

Этот SQL-запрос просит базу данных вернуть:

все данные (*) из таблицы продуктов где категория - "Gifts" released = 1.

Ограничение released = 1 используется для скрытия продуктов, которые не выпущены. Для невыпущенных продуктов, предположительно, released = 0.

В приложении не реализована защита от атак SQL-инъекций, поэтому злоумышленник может построить атаку типа:

https://falcon-bytes.github.io/products?category=Gifts'--.

В результате получится SQL-запрос:

SELECT * FROM products WHERE category = 'Gifts'--' AND released = 1

Ключевым моментом здесь является то, что последовательность двойных тире -- является индикатором комментария в SQL и означает, что остальная часть запроса интерпретируется как комментарий.

Комментарии, если вы не были в курсе нужны для программистов, для того, чтобы делать различные заметки/пометки в коде, при этом, чтобы они не воспринимались средой как настоящий код. В python, например эквивалентом двойного тире будет "#"

Это эффективно удаляет остаток запроса, так что он больше не включает AND released = 1. Это означает, что отображаются все продукты, включая еще не выпущенные.

Если пойти дальше, злоумышленник может заставить приложение отобразить все продукты в любой категории, включая категории, о которых он не знает:

https://falcon-bytes.github.io/products?category=Gifts'+OR+1=1--.

В результате получается SQL-запрос:

SELECT * FROM products WHERE category = 'Gifts' OR 1=1--' AND released = 1

В результате такого способа системой будет воспринят запрос:

SELECT * FROM products WHERE category = 'Gifts' OR 1=1

При этом все, что идет после -- будет игнорироваться

Модифицированный запрос вернет все товары, где
либо категория - Gifts, либо 1 равна 1. Поскольку 1=1 всегда истинно, запрос
вернет все товары.

Кроме того, вместо того, чтобы получить какие-то элементы базы данных злоумышленник может пойти еще дальше, и удалить вообще все элементы в таблице, вот пример:

Здесь сайтом предложено окно ввода ID товара, а злоумышленник помимо айди товара вставляет дополнительный запрос, который удаляет всю таблицу.

Подрыв логики приложения

Рассмотрим приложение, которое позволяет пользователям входить в систему с помощью имени пользователя и пароля. Если пользователь вводит имя пользователя falcon и пароль bytes, приложение проверяет учетные данные, выполняя следующий SQL-запрос:

SELECT * FROM users WHERE username = 'falcon' AND password = 'bytes'

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

Здесь злоумышленник может войти в систему как любой пользователь без пароля, просто используя последовательность комментариев SQL -- для удаления проверки пароля из пункта WHERE запроса. Например, если ввести имя пользователя administrator'-- и пустой пароль, то получится следующий запрос:

SELECT * FROM users WHERE username = 'administrator'--' AND password = ''

Этот запрос возвращает пользователя, чье имя пользователя - administrator, и успешно регистрирует атакующего как этого пользователя.

Получение данных из других таблиц базы данных

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

Например, если приложение выполняет следующий запрос, содержащий пользовательский ввод "Gifts":

SELECT name, description FROM products WHERE category = 'Gifts'

то злоумышленник может отправить ввод:

' UNION SELECT username, password FROM users--.

Это заставит приложение вернуть все имена пользователей и пароли вместе с названиями и описаниями товаров.

Слепые уязвимости SQL-инъекции

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

В зависимости от характера уязвимости и используемой базы данных, для эксплуатации слепых уязвимостей SQL-инъекций можно использовать следующие техники:

Можно изменить логику запроса, чтобы вызвать заметную разницу в реакции приложения в зависимости от истинности одного условия. Это может включать в себя введение нового условия в некоторую булеву логику или условное срабатывание ошибки, такой как деление на ноль.
Можно условно вызвать временную задержку в обработке запроса, что позволяет сделать вывод об истинности условия на основе времени, которое требуется приложению для ответа.
Можно вызвать внеполосное сетевое взаимодействие, используя технику OAST. Эта техника является чрезвычайно мощной и работает в ситуациях, когда другие техники не работают. Часто вы можете напрямую передать данные по внеполосному каналу, например, поместив данные в DNS-поиск для домена, который вы контролируете.

В следующих постах я попробую на практике показать, как работают конкретно разные типы SQL-инъекций. Ну а пока на этом все!

На связи был админ канала Falcon Bytes, надеюсь вы узнали что-нибудь новое.