Здравствуйте, дорогие друзья.

Теперь, когда Вы знаете основы внедрения SQL и уязвимостей XSS, давайте реализуем быстрый фаззер, для поиска потенциальных уязвимостей внедрения SQL или XSS, в параметрах строки запроса. Параметры строки запроса — это параметры в URL-адресе после знака ?, и далее идет знак в формате ключ = значение. Мы сосредоточимся на параметрах HTTP в запросе GET, но сначала разобьем URL-адрес, чтобы можно было пройти по любым параметрам строки HTTP-запроса, как показано в листинге 2-9.

В листинге 2-9 мы берем первый аргумент (args[0]), передаваемый основному приложению фаззинга, и предполагаем, что это URL [1] с некоторыми нечеткими параметрами HTTP в строке запроса. Чтобы превратить параметры во что-то, что мы можем перебирать, мы удаляем все символы до вопросительного знака (?) в URL-адресе и используем IndexOf(«?») [2], чтобы определить индекс первого вхождения параметра. Вопросительный знак означает, что URL-адрес закончился и за ним следуют параметры строки запроса; это параметры, которые мы можем проанализировать.

Вызов Remove(0, index+1) [3] возвращает строку, содержащую только параметры URL. Затем эта строка разделяется символом «&» [4], который отмечает начало нового параметра. Наконец, мы используем ключевое слово foreach, перебираем все строки в массиве parms и печатаем каждый параметр и его значение. Теперь мы изолировали параметры строки запроса и их значения от URL-адреса, чтобы мы могли начать изменять значения при выполнении HTTP-запросов, чтобы вызвать ошибки в веб-приложении.

Изменение параметров и тестирование на уязвимости

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

Чтобы проверить наличие уязвимостей, нам необходимо убедиться, что мы создаем URL-адреса, понятные нашему целевому сайту. Для этого мы сначала заменяем старый параметр в URL-адресе на испорченный, а затем печатаем новые URL-адреса, которые мы будем запрашивать. При выводе на экран, каждый параметр в URL-адресе должен содержать одну строку, включающую параметр, испорченный XSS [1], и одну строку, содержащую параметр с одним апострофом [2], как показано в листинге 2-11.

http://192.168.1.75/cgi-bin/badstore.cgi?searchquery=testfdsa&action=search http://192.168.1.75/cgi-bin/badstore.cgi?searchquery=testfd’sa&action=search —snip—

Создание HTTP-запросов

Далее мы программно создаем HTTP-запросы с использованием класса HttpWebRequest, а затем делаем HTTP-запросы с испорченными параметрами HTTP, чтобы проверить, возвращаются ли какие-либо ошибки (см. листинг 2.12).

В листинге 2-12 мы используем статический метод Create() [1] из класса WebRequest, чтобы сделать HTTP-запрос, передавая URL-адрес в переменной sqlUrl, испорченный одним апострофом, в качестве аргумента, и мы приводим результирующий экземпляр WebRequest, который возвращается в HttpWebRequest. (Статические методы доступны без создания экземпляра родительского класса.) Статический метод Create() использует шаблон для создания новых объектов на основе переданного URL-адреса, поэтому нам нужно привести возвращаемый объект к объекту HttpWebRequest. Если бы мы передали, например, URL-адрес с префиксом ftp:// или file://, то тип объекта, возвращаемого методом Create(), будет другим классом (FtpWebRequest или FileWebRequest соответственно). Затем мы устанавливаем для свойства Method HttpWebRequest значение GET (поэтому мы делаем запрос GET) [2] и сохраняем ответ на запрос в строке resp, используя класс StreamReader и метод ReadToEnd() [3]. Если ответ либо содержит неочищенную полезную нагрузку XSS, либо выдает ошибку синтаксиса SQL, мы знаем, что, возможно, обнаружили уязвимость.

Примечание. Обратите внимание, что здесь мы используем ключевое слово using по-новому. До этого мы использовали using для импорта классов из пространства имен (например, System.Net) в фаззер. По сути, созданные объекты (объекты, созданные с помощью нового ключевого слова) могут использоваться в контексте блока using таким образом, когда класс реализует интерфейс IDisposable (который требует, чтобы класс реализовал метод Dispose()). Когда область использования блока using заканчивается, метод Dispose() объекта вызывается автоматически. Это очень полезный способ управления областью ресурса, который может привести к утечке ресурсов, таких как сетевые ресурсы или файловые дескрипторы.

Тестирование кода фаззера

Давайте проверим наш код, с помощью поля поиска на главной странице BadStore. Открыв приложение BadStore в веб-браузере, щелкните пункт меню «Главная» в левой части страницы, а затем выполните быстрый поиск в поле поиска в верхнем левом углу. Вы должны увидеть в своем браузере URL-адрес, аналогичный показанному в листинге 2-13.

http://192.168.1.75/cgi-bin/badstore.cgi?searchquery=test&action=search

Передайте URL-адрес из листинга 2-13 (заменив IP-адрес на IP-адрес экземпляра BadStore в Вашей сети), программе, в качестве аргумента, в командной строке, как показано в листинге 2-14, и фаззинг должен начаться.

$ ./fuzzer.exe «http://192.168.1.75/cgi-bin/badstore.cgi?searchquery=test&action=search» SQL injection point found in parameter: searchquery=test
Possible XSS point found in parameter: searchquery=test
$

Запуск нашего фаззера должен обнаружить как SQL-инъекцию, так и XSS-уязвимость в BadStore, с выводом, аналогичным показанному в листинге 2-14.

На этом все. Всем хорошего дня!

Цикл статей по Gray Hat C#. Руководство для хакера по созданию и автоматизации инструментов безопасности.