Мы переходим к технической части статей про тестирование на проникновение. И начнем как всегда с внешнего пути – с эксплуатации веб уязвимостей. И стартанем мы с 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 –инъекции.

Комментарии (7)


  1. Akina
    00.00.0000 00:00
    +6

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

    Тем более что описанное применимо далеко не к каждой СУБД.. например, в MySQL ни один из примеров не сработает - хоть вводи их в клиента прямо с инъекцией.

    И да - если в абзаце размещаете запрос, то не надо ставить в этом абзаце финальную точку. Запросу это неполезно.. значениям и ссылкам, впрочем, тоже.


    1. Evg3108
      00.00.0000 00:00

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

      В остальном лично для себя нашла пользу и в имеющейся информации)


      1. FanatPHP
        00.00.0000 00:00

        Уязвимость возникает ровно в одном случае — когда в SQL запрос попадают любые элементы, которые не прописаны явно в коде программы, выполняющей запрос.


  1. FanatPHP
    00.00.0000 00:00
    +2

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


    Потому что никаких "слепых уязвимостей" не бывает.
    Уязвимость всегда только одна — возможность модифицировать код SQL.
    А вот способов использовать, или эксплуатировать эту уязвимость — бесконечное количество.
    Важным следствием понимания этого факта является простое правило — что защищаться следует не от бесконечного количества разных вариантов эксплуатации, а от одной простой уязвимости, соблюдением двух простых правил:


    • любые данные попадают в запрос только через символы подстановки
    • любые другие элементы запроса — только после фильтрации через белый список разрешенных значений


    1. Yacudza
      00.00.0000 00:00

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


      1. FanatPHP
        00.00.0000 00:00
        -1

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


        Если уж говорить о том, как "должно быть", то я повторюсь — "слепых" инъекций не бывает. Уязвимость бывает только одна: это возможность манипулировать кодом SQL. Возможность сделать эту самую инъекцию. И она не может быть слепой или не слепой. Она может только быть или не быть.
        "Слепая инъекция" — это не отдельный тип инъекций, как можно подумать из названия. А просто набор техник, эксплуатирующих ту же самую уязвимость, просто в некотором ограниченном окружении. Частный случай, который на самом деле не стоит выделения в отдельную категорию.


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


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


  1. Yacudza
    00.00.0000 00:00
    +1

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