May 4

Практика SQLi

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

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

Также в будущем мы будем использовать программу Burp Suite, она, к сожалению, платная, однако я планирую выложить кряк версию на канал, которой сам пользуюсь иногда. Вы также можете сами найти в интернете решения, использовать аналоги или просто спиратить купить софт.

Регистрация

В первую очередь зарегистрируемся на сайте https://portswigger.net для этого можете использовать любую электронную почту (даже можно на одноразовую почту зарегистрировать, но тут не уверен) и любой пароль. Тут у вас не должно возникнуть никаких проблем, так что не буду уделять этому моменту много времени.

Поиск уязвимости

У Portswigger есть очень много материалов посвященных пентестингу на английском, так что вы можете и сами почитать интересующие вас материалы.

Перейдем по ссылке на ресурс с сервером и нажмем кнопку "ACCESS THE LAB":

Эта лаборатория содержит уязвимость внедрения SQLi в фильтре категорий продуктов. Когда пользователь выбирает категорию, приложение выполняет SQL-запрос, подобный следующему:

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

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

Перейдя в лабораторию нас поприветствует такая веб-страница:

Для начала немного потыкаем на кнопки и посмотрим, что происходит в строке URL. Для примера я нажму на категорию "Pets":

Смотрим что происходит в URL параметрах нашей лаборатории:

Как можно предположить из этого параметра, категории напрямую берутся из URL параметра, а значит, они могут необработанные отправляться прямо в запрос в БД. Проверим нашу гипотезу!

Как я упомянал ранее, SQL запрос выглядит примерно так:

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

В нем выбираются все элементы базы (*) в таблице "products" где категория это "Pets" и параметр "released" равен 1. Но это значит, что параметры в URL строке можно вводить абсолютно любые, и они будут без какой-либо обработки отправлятьяс в нашу БД!

Попробуем оставить категорию пустой, и посмотрим что произойдет:

Как видим, сервер нам ничего не вернул, и не удивительно, ведь пустых параметров нету в базе данных, это еще раз подтвердило нашу теорию о том, что параметры передаваемые пользователем идут напрямую в БД без каких-либо обработок.

Теперь попробуем в параметрах категорий указать одинарную кавычку и посмотрим что произойдет. Одинарные кавычки часто используются при поиске SQL уязвимостей.

Что же произошло? Рассмотрим как выглядит SQL-запрос при таком случае:

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

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

' AND released = 1

Такой запрос не соответствует синтаксису SQL-запросов и сервер возвращает ошибку. Система просто не понимает, что от нее хотят.

Теперь перейдем к использованию Эксплоита!

Введем в параметры вот такой запрос:

Запрос в базу данных выглядит так:

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

Данный запрос ищет соответствие, есть ли категория 'falcon-bytes' в базе данных ИЛИ, если категории нет, тоесть False, то выполнить выражение 1=1, это выражение нам нужно для того, чтобы просто заставить базу данных выполнить

Как я упоминал в предыдущем посте, двойное тире воспринимается синтаксисом как комментарий, и все, что идет после этого выражения не выполняестя системой. А выражение 1=1 - это всегда истиннное выражение.

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

Также мы получаем поздравление от лаборатории, что мы решили этот уровень

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

Таким образом мы выбираем параметр released (выпущенные) 0 - значит те, которые не выпущены и получим такой результат:

Если выбрать просто категорию Pets, то такого продукта у нас не будет, а значит, наша шалость удалась.

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

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

filter?category=Pets' AND DROP TABLE products --

При реальных условиях, приложение с удовольствием выполнит наш запрос и сама снесет все продукты XD

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

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