Мы переходим к технической части статей про тестирование на проникновение. И начнем как всегда с внешнего пути – с эксплуатации веб уязвимостей. И стартанем мы с SQL – инъекций.

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

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

Каковы последствия успешной атаки SQL-инъекции?

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

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

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

• Получение скрытых данных, когда вы можете изменить SQL-запрос, чтобы вернуть дополнительные результаты.

• Подрыв логики приложения, когда можно изменить запрос, чтобы вмешаться в логику приложения.

• Атаки UNION, когда можно получить данные из разных таблиц базы данных.

• Изучение базы данных, когда можно получить информацию о версии и структуре базы данных.

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

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

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

https://uhahatbltv.com/?category=Gifts

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

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

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

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

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

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

https://uhahatbltv.com/products?category=Gifts'--.

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

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

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

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

https://uhahatbltv.com/products?category=Gifts'+OR+1=1--.

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

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

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

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

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

SELECT * FROM users WHERE username = 'wiener' AND password = 'bluecheese'

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

Здесь злоумышленник может войти в систему как любой пользователь без пароля, просто используя последовательность комментариев 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-инъекции обычно полезно получить некоторую информацию о самой базе данных. Эта информация часто может проложить путь для дальнейшей эксплуатации.

Вы можете запросить информацию о версии базы данных. Способ, которым это делается, зависит от типа базы данных, поэтому вы можете определить тип базы данных по тому, какая техника работает. Например, в Oracle вы можете выполнить:

SELECT * FROM v$version

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

SELECT * FROM information_schema.tables

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

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

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

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

• Можно условно вызвать временную задержку в обработке запроса, что позволяет сделать вывод об истинности условия на основе времени, которое требуется приложению для ответа.

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

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