[Из старого] WebScarab — инструмент для анализа защищённости веб-приложений

Автор: Кузьмин Антон

Дата: 18-02-2009

Официальная страница: http://www.owasp.org/index.php/Category:OWASP_WebScarab_Project

Последняя версия на момент написания статьи: 20070504-1631

Ограничения: Написан на Java. Для запуска требуется Java JRE/JDK версии 1.4.2 или выше.

ОС: Проект кросс-платформенный.

Все недоработки были обнаружены под ОС WinXP SP2. Возможно некоторые их них не проявляются в других ОС.

В этой статье я хотел бы рассказать о WebScarab (далее WS) - достаточно мощном и профессиональном инструменте, созданном для исследования веб-приложений. К сожалению, как и многие подбные проекты WS уже давно не развивается. Окончание его разработки датируется 4 мая 2007 года, тогда вышла последняя версия доступная и сегодня. История же у него похожа на множество остальных — сначала он создавался для личного пользования автором (Rogan Dawes), а потом было решено выложить его на общедоступные ресурсы для массового пользования. Кстати, при долгом использовании можно заметить все признаки того что сначала автор даже и не думал куда-либо выкладывать свой проект — много непонятных и известных одному ему функций, пунктво меню, кнопок и т.д. большинство из которых не описаны в справке. Конечно, много и недоработок. Очень часто вылазеет окошко исключения, после которого нужно перезагрузить WS, иначе оно буде появляться при каждом движении. Но не смотря на все минусы у WS огромное количество плюсов. WS даёт пользователю огромный функционал который, плюс ко всему, может расширяться с использованием встроенного скриптового языка. В отличие от других проектов подобного рода WS это не программа. Фактически это фреймворк к которому подключаются плагины составляющие его функционал. Его основой является прокси-сервер работающий по адресу 127.0.0.1:8008. При обращении к сайтам данные запросов и ответов сервера записываются в базу и становятся доступны для всех плагинов, что позволяет одному плагину использовать результаты работы другого. Так же, в основном наборе, имеется 2 вида интерфейса — облегчённый и полный. При разных интерфейсах WS доступен разный функционал, поэтому мы рассмотрим по очереди каждый из них.

1.0 Lite-интерфейс.

Этот интерфейс активизируется сразу после установки. В нём доступны только функции перехвата обращений к серверу и ответов от него. Так же доступен небольшой сторонний функционал. Начнём со строки меню которая в обоих вариантах интерфейсов содержит 4 пункта - «File», «View», «Tools» и «Help».

В меню «File» Вы можете начать новую, сохранить или загрузить сессию. При начале новой сессии Вас попросят указать директорию для её хранения. Здесь нужно отметить то что данные сессии хранятся не в одном файле, а в директории в виде множества файлов. Поэтому при сохранении нужно указывать не имя файла а путь к директории сохранения. Обратите внимание ещё и на то что данные сессии, которая начинается при запуске WS, нигде не сохраняются. Их можно сохранить только вручную.

Далее идёт меню «View», в котором содержится подменю «Content editors» содержащее пункт «Wrap text». Честно говоря я так и не смог понять что этот пункт делает. Затем следует меню «Tools». Оно содержит следующие пункты.

• Proxies — здесь Вы можете указать прокси-серверы для протоколов HTTP и HTTPS, а так же список хостов обращение к которым должно проходить без участия прокси-серверов.
• Credentials — в этом пункте Вы должны указать необходимые данные для авторизации, если таковые требуются. При включении галочки «Ask when required» WS будет запрашивать у Вас эти данные только когда они станут необходимы. При этом в таблицу данных авторизации можно ничего не добавлять. Если Вы здесь ничего не укажите то данные для авторизации будут запрашиваться как обычно через браузер.
• Transcoder — здесь Вы можете производить различные операции с обычным текстом, а именно — кодировать/декодировать URL-спецсимволы, кодировать/декодировать текст по алгоритму base64 и получать md5 и sha1 хэши введённого текста.
• Reveal hidden fields — при отметке галочкой этого пункта все скрытые поля, находящиеся в ответах сервера, будут заменены на аналогичные текстовые. Вот пример действия этой опции из редактирования профиля в phpNuke

• User full-featured interface — использование полного интерфейса. Об этом ниже.

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

Следующим шагом мы рассмотрим функциональную части интерфейса. Она состоит из двух закладок - «Summary» и «Intercept».

1.1 Закладка Summary.

На этой закладке располагается информация о запросах прошедших через прокси-сервер. В первой части окна находится древовидная структура запросов с их адресами, кодами ответов и т.д.

Последние 3 колонки этой таблицы помечаются галочкой при следующих условиях. Если в заголовке ответа сервера на определённый запрос имеется поле «Set-Cookie», то в одноимённой колонке ставится галочка. Если в теле ответа имеются какие-либо комментарии то галочкой помечается поле «Comments». Ну и последнее поле «Scripts» отмечается галочкой тогда когда в теле ответа WS обнаружит вставки скриптов.

В нижней части окна находится таблица совершённых запросов. Она содержит те же самые поля что и древовидная структура за несколькими исключениями. По умолчанию в этой таблице содержатся все запросы сделанные в текущей сессии. Если Вы отметите поле «Tree selection filters conversation list», находящееся в самом верху закладки, то в этой таблице будет отображаться только тот запрос который выбран в древе. Так же здесь можно посмотреть все внутренности обращения, комментарии и скрипты обнаруженные в нём. Для этого нужно выбрать интересующий Вас запрос и кликнуть по нему правой кнопкой мыши. Вы увидите меню состоящее из трёх пунктов.

• Show conversation — просмотр внутренностей запроса и ответа на него
• Show scripts — просмотр скриптов обнаруженных в теле ответа. Этот пункт меню активен только если в соответствующем поле стоит галочка.
• Show comments — просмотр комментариев обнаруженных в теле ответа. Этот пункт тоже активен тогда когда соответствующее поле отмечено галочкой.

При выборе первого пункта откроется окно содержащее все данные о запросе. В самом его верху расположена панель навигации. В неё входят кнопки «Previous», «Next» (показ предыдущего и следующего запроса, соответственно) и выпадающий список содержащий все запросы текущей сессии для быстрой навигации между ними. Далее окно разделяется на 2 основные части. В первой его половине показывается информация запроса, а во второй — ответа сервера на этот запрос. В свою очередь каждая из частей делится так же надвое — заголовок и тело.

У части содержащей заголовок всегда имеется только 2 вкладки - «Parsed» и «Raw». При выборе первой из них Вы увидите данные в форме таблицы, как это показано на рисунке выше. При выборе закладки «Raw» содержимое заголовка будет показываться в виде обычного текста. Во той части, что содержит тело, количество закладок постоянно меняется в зависимости от передаваемых данных. Например так могут появится закладки:

• «Hex» - отображение данных в шестнадцатиричном виде.
• «XML» - отображение данных в виде XML-древа.
• «TEXT» - отображение данных в виде обычного текста.
• «HTML» - отображение данных в виде обработанного HTML-кода. Почти точно так же как этот код отобразит браузер.
• «image» - отображение данных в виде изображения.

Если WS не сможет распознать тип передаваемых данных то Вам будет доступна лишь одна закладка - «Hex».

При выборе пункта «Show scripts» открывается окно содержащее коды всех обнаруженных в теле ответа скриптов.

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

При нажатии на пункт «Show comments» Вы увидите окно со списком обнаруженных комментариев. Оно очень похоже на окно показа скриптов.

1.2 Закладка «Intercept»

Перейдём ко второй основной закладке - «Intercept». Здесь можно управлять перехватами запросов и ответов. Если Вы в самом верху окна активируйте галочку «Intercept requests» то WS начнёт перехватывать все запросы браузера проходящие через него. Так же разблокируется и несколько дополнительных полей. Первое поле - «Methods». Оно содержит методы запросов которые подлежат перехвату. По умолчанию в нём выделены 2 пункта - «GET» и «POST». Выделить сразу несколько методов Вы можете с помощью клика мышки с зажатым ctrl`ом. Справа находятся ещё 3 поля. Первое - «Case sensitive regular expression». При его активации начинают перехватываться только те запросы которые совпадают с регулярными выражениями введёнными ниже. Второе поле - «Include Paths matching», содержит регулярное выражение при совпадении с которым запрос должен быть перехвачен. По умолчанию в нём находится значение «.*» обозначающее перехват любых запросов. И третье поле - «Exclude Paths matching». Содержит регулярное выражение при совпадении с которым запрос не будет перехватываться. По умолчанию там уже находится значение «.*\.(gif|jpg|png|css|js|ico|swf|axd.*)$», что исключает перехват картинок, иконок, стилей и прочих, часто не нужных, файлов.

В самом низу данной закладки находится пункт «Intercept responses», при активации которого WS начинает перехватывать ответы сервера. Ниже этого пункта находится поле «Only MIME-Types matching», содержащее регулярное выражение в котором указывается какого MIME-типа (поле «Content-Type» заголовка) ответы должны быть перехвачены. По умолчанию в нём содержится вырежение «text/*» разрешающее перехват только текстовых данных.

Как только WS`у удастся перехватить какие-либо данные он сразу просигнализирует Вам об этом. На панели задач должно открыться новое окно с именем «Edit Request» или «Edit Response». Мы рассмотрим пример только с окном «Edit Request» так как оба эти окна не сильно друг от друга отличаются. В самом его верху находятся 2 поля для быстрой активации/деактивации перехвата запросов и ответов. Далее идёт уже знакомое Вам окно редактирования запроса. Но на этот раз поля не заблокированы для вмешательства.

В режиме таблицы Вы можете редактировать заголовки двойным щелчком мыши по их именам или содержимому. Если же Вы перейдёте на закладку «Raw» то сможете редактировать заголовок как в текстовом редакторе. Справа от заголовков, в табличном режиме, имеются кнопки «Insert» и «Delete» которые вставляют новый заголовок и удаляют выделенный соответственно. И в самом низу этого окна имеется 4 кнопки:

1. Accept changes — Принять все изменения. После нажатия этой кнопки отредактированные данные будут отправлены дальше.
2. Cancel changes — Отменить все изменения. После нажатия этой кнопки данные будут отправлены дальше без применения к ним изменений.
3. Abort Request — Оборвать запрос. После нажатия этой кнопки данные удаляются и до источника не доходят.
4. Cancel ALL Intercepts — закрыть все окна перехваченных запросов и отправить данные дальше без принятия изменений.

Нужно заметить что форма редактирования ответа сервера отличается от формы редактирования запроса только наличием второй части окна — содержимого ответа (которая просто убрана из первой формы за ненадобностью). Больше никаких отличий между ними нет.

Вот и вся суть Lite-интерфейса. Перейдём теперь к полному варианту. Сделать это можно активировав пункт «Use full-featured interface» в меню «Tools» и перезапустив WebScarab.

2.0 Интерфейс «Full-featured»

В данном виде интерфейса пользователю предоставляется полный функционал WS, точнее всех его плагинов. Для начала, как и выше, рассмотрим строку меню. В инструментах («Tools») появились новые пункты. Это

• Certificates
• Shared cookies
• Script manager
• Restart plugins

WS`ом поддерживаются клиентские SSL-сертификаты и пункт «Certificates» открывает их хранилище. В нём Вы можете производить с ними различные манипуляции, а именно — добавлять, удалять, редактировать и активировать сертификаты когда это потребуется. WS поддерживает 2 формата сертификатов — PKCS#11 и PKCS#12.

Пункт «Shared cookies» открывает хранилище общедоступных cookies которые могут использоваться различными плагинами. Вы можете добавлять туда данные как вручную, с помощью кнопки «Add», так и с помощью плагинов (описано ниже).

В верхней части окна («cookies») показывается основная информация о хранящихся здесь данных. В нижней («Previous values») - вторичная. Если устанавливаются cookies которые уже находятся в хранилище, то их данные заносятся второй строкой в нижнюю таблицу. В верхней же ничего не меняется.

Пункт «Script Manager» открывает утилиту управления скриптов. Здесь содержаться и управляются так называемые «хуки». При открытии этой утилиты в левой части окна Вы увидите древовидную структуру. Раскройте любое древо и кликните на под-пункт. В правой верхней части окна сразу же появится описание данного хука в котором говорится когда он вызывается и что использует. Так же, при выборе мышью хука, в верхнем меню станет доступна кнопка «Add» позволяющая добавить скриптовый код(на BeanShell или Jython) в выбранный хук. Соответственно, после добавления при вызове данного хука будет вызываться и Ваш код.

Пункт «Restart plugins» фактически ни для чего не предназначен. Он был очень давно создан разработчиком для того что бы отловить какую-то проблему (сам разработчик деталей уже не помнит), а после её решения он просто не стал удалять этот пункт. То же самое и с пунктом «Log level» в меню «Help». Этот пункт так же ничего не делает.

С меню всё. Перейдём к основному окну. В «Full-featured»-варианте главное окно содержит 14 закладок.

1. Summary
2. Messages
3. Proxy
4. Manual Request
5. WebServices
6. Spider
7. Extensions
8. XSS/CRLF
9. SessionID analysis
10. Scripted
11. Fragments
12. Fuzzer
13. Compare
14. Search

Рассмотрим подробно каждую из них.

2.1 Summary

Эта закладка Вам уже знакома, но в полной версии интерфейса в ней есть несколько дополнений. В древе запросов появились новые колонки, а именно «Posible injection» и «Injection». Первая колонка помечается галочкой тогда когда WS подозревает наличие инъективной уязвимости, а вторая — когда фактически определено её существование. Подробнее об этом написано ниже, в описании закладки «XSS/CRLF». Отмечу то что во время всех проведённых мною тестов я ни разу не видел галочки в поле «Injection». Возможно это просто одна из недоработок.

Вторым дополнением является вызов правой кнопкой мыши меню в древе запросов. Два его пункта - «Show comments» и «Show scripts» в объяснениях не нуждаются, так как были описаны выше, а вот на третьем пункте, «Spider tree», мы остановимся. Выбор этого пункта приведёт к сканированию модулем поискового паука выбранной части древа. То есть если в обычном режиме поисковый паук просканировал бы весь сайт то тут он обработает лишь указанный путь не выходя за его приделы. Подробнее эту процедуру я описал в соответствующем разделе.

В нижней таблице добавилось несколько новых полей относящихся к уязвимостям - «Posible injection», «XSS» и «CRLF» свидетельствующих о наличии/отсутствии возможной уязвимости, XSS и CRLF. Так же в меню, появляющемся при правом клике мышью, добавился пункт «Use as fuzz template», при нажатии на который выделенный запрос будет использоваться как шаблон для плагина «Fuzzer». Об этом так же написано ниже, в разделе этого плагина.

2.2 Messages

Данная закладка содержит отладочную информацию обо всех действиях WS и пользователя. Точно такие же данные Вы можете увидеть в командной строке которая открывается вторым окном при запуске WebScarab`a.

2.3 Proxy

На этой закладке происходит управление функциями прокси-сервера. Здесь имеется 4 под-закладки. Первая - «Listenters». На ней располагается список запущенных прокси-серверов. По умолчанию там один прокси, запущенный на IP-адресе «127.0.0.1». Для того что бы запустить новый экземпляр заполните соответствующую форму в низу окна и нажмите кнопку «Start» в его правой части.

После этого будет запущен новый прокси-сервер на указанном Вами адресе и порту. Данная возможность может использоваться например для того чтобы принимать подключения через WS из вне или с виртуальной машины. Завершить работу какого-либо экземпляра прокси-сервера можно нажитием кнопки «Stop».

Следующая закладка «Manual Edit». Каких-то новшеств, по сравнению с облегчённой версией интерфейса здесь нет, поэтому перейдём сразу к закладке «Bean shell». Данный плагин позволяет с помощью одноимённого языка оказывать воздействие на запросы и ответы (их заголовки, тела и т.д.) проходящие через прокси-сервер. Это нечто похожее на макросы. Для выполнения какого-либо кода нужно выполнить несколько незамысловатых действий. Сначала отметьте галочкой поле «Enabled». Затем в открывшееся текстовом поле поместите нужный код. И активируйте его нажатием кнопки «Commit». Обратите внимание на то что любые изменения в выполняемом коде будут приняты только после нажатия этой кнопки. Основы этого скриптового языка я здесь приводить не буду, скажу лишь только что его синтаксис сильно похож на Java. А в качестве примера я приведу простой скрипт который записывает в текстовый файл данные о запросах и кодах ответов на них.

import org.owasp.webscarab.model.Request;

import org.owasp.webscarab.model.Response;

import org.owasp.webscarab.httpclient.HTTPClient;

import java.io.IOException;

public Response fetchResponse(HTTPClient nextPlugin, Request request) throws IOException {

response = nextPlugin.fetchResponse(request);

FileWriter fstream = new FileWriter("C:/WebScarab_log.txt", true);

BufferedWriter log = new BufferedWriter(fstream);

log.write("============================================\r\n");

log.write("URL: "+request.getURL().toString()+"\r\n");

log.write("Method: "+request.getMethod()+"\r\n");

log.write("Answer code: "+response.getStatus()+"\r\n");

log.close();

return response;

}

Подробное описание языка «Bean Shell» Вы можете получить на сайте разработчиков — http://www.beanshell.org в разделе документации. Информацию по внутренним объектам WS, которые могут быть задействованы в скриптах, можно получить по адресу [деркториия куда установлен WS]/doc/api/index.html.

Следующая закладка - «Miscellaneouse». Тут имеется всего 4 пункта.

1. «Reveal hidden fields in HTML pages». Этот пункт нам уже знаком из lite-интерфейса. При его активации все скрытые поля в ответах сервера модифицируются в текстовые.
2. «Prevent browser from caching content». При активации этого пункта прокси-сервер запрещает кэширование поступающего материала.
3. «Inject known cookies into request». Активация этого поля указывает WS`у что в каждый запрос нужно включать cookies из хранилища «Shared cookies»
4. «Get cookies from responses». Если этот пункт отмечен галочкой то все получаемые cookies будут помещаться в хранилище «Shared cookies»

2.4 Manual request

Этот плагин представляет из себя обычный конструктор запросов. Структура окна Вам уже знакома в основных чертах. В самом верху находится список «Previous requests». В нём Вы можете выбрать любой из запросов, прошедших через WS, в качестве шаблона. Ниже находится часть конструктора отвечающая за формирование самого запроса. Здесь Вы можете указать его метод, URL, версию протокола, а так же работать с заголовками. Как всегда работать можно и в ражиме «Parsed», и в обычном текстовом. Обратите внимание на то что в режиме «Parsed» Вы не можете заполнять тело запроса (например если формируется POST-запрос). Если Вам это необходимо то Вы можете либо взять другой POST-запрос в качестве шаблона, либо сформировать тело запроса в текстовом варианте.

Почти в самом низу находится часть окна работающая с ответом сервера. Думаю здесь объяснять ничего не нужно так как всё было описано ранее. А вот в самом низу есть 3 кнопки. Первая из них - «Get cookies». По документации при нажатии этой кнопки данные из хранилища «Shared cookies» должны помещаться в запрос, но она не работает. Вторая - «Fetch response». При нажатии на неё запрос отправляется по месту назначения и WS получает ответ, который сразу отобразится в соответствующей части. И третья кнопка - «Update CookieJar». Нажав на неё Вы поместите cookies из ответа сервера (если таковые там имеются) в хранилище «Shared cookies».

2.5 WebServices

На этой закладке находится инструмент для работы с SOAP-веб-сервисами. Данный плагин автоматически отлавливает все WSDL-обращения и они помещаются в самый верхний выпадающий список «WSDL». В поле «WSDL URI» Вы можете указать либо имя файла (путь указывается относительно директории WS), либо удалённый адрес (например по протоколу http) и при нажатии кнопки «Load» WS загрузит данные с указанного адреса.

В поле «Service» Вы можете выбрать используемый сервис если их несколько. Ну и в поле «Operation» пользователю предлагается выбрать операцию которую нужно вызвать. Ниже отображаются параметры, нужные для запроса, их тип и значение (поле значения Вы можете редактировать). Нажав в самом низу окна кнопку «Headers» Вы откроете окно добавления данных в заголовок запроса. Осуществить запрос можно нажатием кнопки «Execute». После этого ответ сервиса появится в нижней части окна.

Своим поведением плагин создаёт впечатление того что он недоработан. С большинством SOAP-сервисов, которые я ему «скармливал», он не желал работать из-за неизвестных ошибок. При загрузке же остальных он выдавал исключения. Всего 2 сервиса из 15 взятых наугад из Google нормально им обработались и он смог с ними взаимодействовать.

К сожалению я не сильно разбираюсь в SOAP-сервисах поэтому врятли смогу что-то ещё сказать об этом плагине.

2.6 Spider

Данный плагин представляет из себя эмуляцию поискового паука. Но и здесь WS отличается от большинства остальных разработок. Многие из нас привыкли к тому что подобные программы начинают сканирование с корня сайта и последовательно перебирают все ссылки. Здесь же всё немного по другому — плагин сканирует не всё под ряд, а только то что Вы ему укажите. Когда Вы будете браузером проходить по различным ссылкам то WS будет записывать все посещённые хосты в меню паука.

После этого, выбрав интересующий Вас хост, паук начнёт исследование. Обратите внимание на то что Вы можете выбрать не только хост, но и отдельную часть всего сайта, например директорию или скрипт.

Рассмотрим теперь строение окна этого плагина. В самой верхней его части имеется 2 поля. Первое из них, «Allowed domains», содержит регулярное выражение, указывающее какие домены можно затрагивать в процессе сканирования выбранного домена. То есть если паук заметит ссылки на домен, имя которого совпадает с регулярным выражением, то он будет по ним проходить. По умолчанию в нём содержится выражение «.*localhost.*», позволяющее «зацеплять» домены в имени которых есть соответствующее слово. Второе поле, «ForbiddenPaths», содержит регулярное выражение по которому паук определяет запрещённые к исследованию директории. Например это может быть директория форума или другого источника большого количества информации, на порверку которого уйдёт очень много времени. Далее идёт 2 поля для галочек. Если Вы отметите галочкой поле «Synchronise cookies» (по умолчанию оно отмечено), то получая cookies паук будет дальше их использовать создавая таким образом имитацию браузера. Поле «Fetch recursively» включает рекурсивное сканирование. То есть в этом случае паук будет проводить сканирование как можно глубже.

В середине окна находится аналог древа запросов содержащий результат сканирования. А в самом низу 4 кнопки. При нажатии первой кнопки, «Fetch tree», паук будет сканировать выбранное дерево или под-дерево. Нажатие второй кнопки, «Fetch Selection», приведёт к сканированию только выбранной части древа. Кнопка «Headers» открывает окно редактирования заголовков. Указанные тут заголовки будут помещаться в каждый запрос при осуществлении сканирования. Ну и кнопка «Stop» останавливает сканирование.

Нужно сказать что этот плагин достаточно глючный и порой ведёт себя непредсказуемо.

2.7 Extensions

Закладка «Extensions» достаточно проста. Этот плагин производит поиск резервных копий файлов и директорий. В верхней части окна Вам предлагается выбрать проверяемый хост или его часть. В нижней будут показываться обнаруженные результаты. И в самом низу есть 2 кнопки. Первая из них - «Edit Extensions». Она открывает список проверяемых расширений. Здесь Вы увидите закладки «Files» и «Directory». Обе из них содержат список расширений применяемых при поиске. Вы можете в ручную редактировать этот список, либо загрузить его из файла кнопкой «Load». Для этого файл должен иметь следующий формат:

.расширение_1

.расширение_2

.расширение_3

.расширение_4

....

.расширение_n

Обратите внимане на то что при сканиорвании старое расширение файла сохраняется. То есть если был осуществлён запрос к файлу test.php, то при поиске его архивных копий будут запрашиваться не такие файлы -

«test.bak», «test.old» и т.д., а такие - «test.php.bak» и «test.php.old».

2.8 XSS/CRLF

Этот плагин работает с обнаружением одноимённых уязвимостей. Он же отвечает за колонки типа «posible injection» на закладке «Summary». Здесь хочу обратить Ваше внимание вот на что. Под инъекциями(injection) здесь подразумеваются инъективные уязвимости к которым относятся XSS и CRLF. Ни с какими другими инъекциями этот модуль не работает. Так же Вам нужно знать что CRLF-уязвимости могут быть обнаружены только если они есть в частях приложения работающих с заголовками. То есть если уязвимость будет существовать при работе с телом ответа (например что-то пишется в файл и тут же выводится) то она обнаружена не будет.

Рассмотрим сам метод обнаружения уязвимостей. Большинство программ подобного рода осуществляют проверку на наличие уязвимостей следующим образом. Программа получает ссылку и подставляет в её параметры какие-то опасные данные. После этого на сайт отправляется запрос с этими изменениями. В зависимости от содержимого ответа программа рапортует о наличие уязвимости или о её отсутствии. WS же, при обращении пользователя к сайту, смотрит какие данные переданы в параметрах запроса и проверяет их наличие на полученной странице. То есть он не делает дополнительных запросов к сайту, он анализирует ссылки по которым проходит пользователь и полученные ответы. Если данные из ссылки имеются в коде страницы то WS считает что есть возможность проведения инъективных атак. Например он поставит галочку в поле «Posible injections» когда Вы обратитесь по ссылке http://site/script.php?a=4654646 к скрипту с кодом

<?php

print intval($_GET['a']);

?>

То есть на практике вероятность того что инъекция действительно есть очень мала.

Но вернёмся к закладке плагина. Она разделена на 2 таблицы. В первой содержатся запросы в которых подозревается наличие инъекций, а во второй должны содержаться запросы у которых проверка на наличие уязвимости дала положительный результат. Но, как сказал автор, это всё в теории. Какие бы действия я не проводил — в нижней таблице ничего не появлялось. В низу находятся 2 кнопки. При нажатии на первую, «Edit test string», Вы откроете окошко для редактирования проверочных данных. Они добавляются к параметрам ссылки при проведении проверок «вручную». Для такой проверки нужно в верхней таблице выделить интересующий Вас запрос и нажать «Check». После нажатия этой кнопки к веб-серверу уходит запрос с изменёнными параметрами.

Теоретически WS должен сообщить о том есть уязвимость или нет, но ничего не происходит.

Согласитесь, такой механизм обнаружения очень хорош. Вам даётся список наиболее вероятных уязвимых мест, а Вы потом отдельно проверяете те которые посчитаете нужным. При этом никаких лишних обращений к сайту с XSS/CRLF-кодом в ссылках. Но, к сожалению, из-за того что фактическую проверку наличия уязвимости в WS не успели реализовать, данный плагин приносит минимальную пользу.

2.9 SessionID analysis

Этот плагин изначально предназначен для анализа идентификаторов сессий с целью разгадки алгоритма их генерации. То есть в идеальном варианте плагин предоставлял атакующему информацию, благодаря которой можно было угадать идентификаторы чужих сессий. Всё это морально устарело как только качестве идентификаторов разработчики стали использовать md5-хэши или подобные способы генерации уникальных строк. К тому же сейчас всё больше и больше распространяются методы привязки сессии к IP-адресу, браузеру или другим пользовательским данным, что сильно затрудняет её перехват. Но всё же встречаются случаи в которых этот плагин был бы полезен. Да и зачем останавливатсья на сессиях? Его можно использовать по отношению к любым данным, алгоритм генерации которых Вам было бы полезно узнать. Это могут быть различные токены, уникальные ползовательские номера и т.д. Вообщем, люди с умом в голове найдут этому плагину полезное приминение. Ниже я опишу все возможности данного плагина, а Вы уж сами разберётесь как их использовать.

Основное окно состоит из трёх закладок. Начнём с самой первой. Она разделена надвое — панель для работы с сессиями и уже знакомое Вам окно запросов. На этой закладке осуществляется сбор данных и их обработка. В самом верху, в поле «Previous requests» Вы должны выбрать запрос из которого можно извлечь идентификатор сессии. После него идёт галочка «From message body», активация которой сообщается WS`у что данные нужно получать из тела ответа (в этом случае заголовок проверяться не будет вообще). Тут же находится поле «Name». В нём должно находиться имя нужного параметра. И последняя строка - «Regex». Она содержит регулярное выражение по которому будет обнаружен идентификатор сессии. Как написано в справке — регулярное выражение должно быть обрамлено символами «.*» потому что поиск информации происходит среди текста. Итак. Допустим Вы выбрали запрос и ввели все данные. Дальше нужно просто нажать кнопку «Test». Если всё нормально то Вы увидите сообщение о том что идентификатор найден. А если нет — сообщение об ошибке.

Таким образом, меняя данные в реглярном выражении и нажимая кнопку «Test» Вы сможете быстро настроить WS на отлов данных. Теперь нужно собрать как можно больше идентификаторов. Для этого после кнопки тестового запроса имеется числовое поле “Samples” и кнопка «Fetch». В числовое поле нужно ввести количество запросов, необходимых для сбора, и по нажатию кнопки «Fetch» WS начнёт отсылать запросы и извлекать из ответов идентификаторы. Подразумевается что при каждом новом запросе приложение выдаёт новый идентификатор.

Для наглядного примера возьмём простейший код который выводит надпись «sess_num=число» и при каждом обращении увеличивает его на единицу.

<?php

$num = intval(file_get_contents('C:/test'));

print 'sess_num='.$num;

$num++;

$f = fopen('C:/test','w');

fwrite($f,$num);

fclose($f);

?>

Сначала скрипт берёт информацию из файла ”C:/test”, затем выводит её и увеличивает на единицу для следующего вывода.

Обратимся через браузер к нашем скрипту. В «Previous requests» выберем осуществлённый запрос. Поставим галочку в поле «From message body» и в открывшемся поле “Name” введём «sess_num». В «Regex» поместим выражение «.*sess_num=(.).*», отлавливающее одно число после «sess_num=». Если всё сделано правильно то при нажатии кнопки «Test» появится табличка со значением параметра «sess_num». 

Теперь в поле «Samples» вводим число 7 и нажатием соответствующей кнопки запускаем анализатор. Будет произведено 7 запросов и извлечённая информация будет записана. Результаты всей это работы Вы можете обнаружить на второй вкладке «Analysis». В списке «Session identifier» выберите «Sess_num 1» и в таблице, находящейся чуть ниже появится интересующая нас информация. Думаю имена колонок в объяснениях не нуждаются. Находящиеся в самом низу поля «Minimum»,«Maximum» и «Range» видимо не доработаны. Ну и 2 нижние кнопки интуитивно понятны - “Clear” очищает таблицу данных, а «Export» сохраняет данные в файл.

На третьей закладке, «Visualization», располагается график изменения идентификаторов. Про него и говорить ничего не нужно — всё подписано.

2.10 Scripted

На этой странице Вы можете писать скрипты на языке Bean Shell (по умолчанию). Суть этого плагина в том что бы пользователи могли писать скрипты с использованием внутренних возможностей WS. Список объектов и методов можно взять в документации ссылку на которую я давал выше.

2.11 Fragments

На этой закладке производится работа с фрагментамим ответов которые отлавливаются с самого начала — скриптами и комментариями. Интерфейс очень простой. В верхней части имеется выпадающий список содержащий всего 2 пункта - «scripts» и «comments». В нём Вы должны выбрать то что хотите посмотреть. В средней части окна, открываются все обнаруженные скрипты или комментарии. Если Вы кликните на какой ни будь из них мышью то в самой нижней части закладки появится список запросов в ответах на которые этот фрагмент присутствовал.

2.12 Fuzzer

Fuzzer представляет из себя инструмент для генерации запросов по определённому шаблону который можно составить двумя путями — в ручную или на основе уже осуществлённого запроса. В ручную запрос составляется так же как и в закладке «Manual Request». А взять за основу какой-либо запрос, прошедший через WS, можно на закладке «Summary». Как я уже писал ранее, в нижней её части нужно выбрать интересующий Вас запрос и в меню, появляющемся при щелчке правой кнопкой, выбрать «Use as fuzz template».

Обратите внимание на то что запрос делится на 2 части — часть с заголовками и часть с параметрами («Parameters»). Работая с запросом в таком виде Вы быстро можете изменять значения каких-либо параметров и тут же производить запросы с ними, что увеличивает скорость и эффективность ручных проверок на часто-встречающиеся уязвимости типа XSS или SQL-injection. Параметры добавляются и удаляются кнопками «Add» и «Delete», находящимися в правой части окна, и могут быть пяти типов.

1. Path — путь к запрашиваемому документу.
2. Fragment — данный тип параметров ничего не делает, его не успели доработать.
3. Query — патаметры запроса
4. Cookies — Cookies запроса
5. Body — тело запроса

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

• Name — имя параметрам
• Type — тип параметра. Здесь постоянно должно быть указано значение «String». Видимо автор планировал добавить сюда ещё что-то, но этого так и не свершилось.
• Value — значение параметра по умолчанию.
• Priority — приоритет параметра. С этим параметром я так и не смог разобраться. Похоже что он просто остался недоработанным.
• Fuzz source — источник данных для параметра. Если это поле не указано то используются данные из поля «Value».

Рассмотрим подробнее последний параметр «Fuzz Source». С самого начала он представляет из себя пустой выпадающий список. Что бы в этот список добавить данные нажмите кнопку «Source». Перед Вами появится окно работы с источниками.

Добавление происходит следующим образом. В поле «Description» Вы должны ввести название источника (это может быть краткое описание), в поле «RegEx» вводится выражение которое будет помещено в значение параметра. В поле «File» можно выбрать файл с таким выражением, при этом поле «RegEx» не заполняется. Для примера создадим шаблон для простейшего XSS-тестирования. В поле описания введём «Simple XSS test.», а в поле выражения поместим JS-код «<script>alert('XSS test');</script>». После этого жмём кнопку «Add» и в колонке «Fuzz Sources» появляется новая запись - «Simple XSS test.». При клике на неё мышкой в поле «Items» появится содержимое записи. Теперь вернёмся на закладку «Fuzzer». В качестве шаблона выберите любой запрос со страницы «Summary» в котором есть хотя бы один GET-параметр. Если Вы сейчас нажмёте кнопку «Start» то запрос выполнится в таком виде в каком был добавлен. И в самой нижней части окна Вы увидите что запрос произошёл. Далее у любого GET-параметра выберите в качестве источника наш шаблон «Simple XSS test.» и нажав на кнопку «Start» Вы сможете убедиться что значение выбранного параметра изменилось на содержимое нашего источника. Результат отправки запроса Вы можете посмотреть если дважды кликните по нему левой кнопкой мыши.

Есть и другой вариант использования источников — указание в них регулярного выражения. Вы наверное уже поняли это по самому названию поля - «RegEx». Смысл здесь в следующем. Вы вводите выражение, и под него в источнике генерируется не одна строка, а множество строк совпадающих с ним. То есть если в первом примере у нас в источнике была одна строка, то с помощью выражений их можно генерировать хоть сотнями. Регулярное выражение должно относится к разряду «ограниченных», то есть не включающих в себя такие выражения типа «.*», которые подразумевают любой возможный символ и могут приваести к генерации большого количества значений. Например, это будут выражения «[0-9]{2}» (сгенерируются все двузначные числа), или «[a-z]{2}» (сгенерируются множество английских двухсимвольных строк). Попробуйте вкачестве небольшого примера создать источник с выражением «[0-9]{3}». После нажатия кнопки «Add» выделите его в левой колонке и Вы увидите сгенирированные значения.

Вернёмся к основному окну. Если Вы выберите такой источник у какого-либо параметра то сразу же изменится поле «Total requests», находящееся над таблицей результатов и содержащее общее количество запросов. Для вышепривидённого выражения это 1000. Соответственно, после нажатия кнопки «Start» поочерёдно начнут отправляться запросы со значениями из источника.

Для остановки этого процесса нужно лишь нажать кнопку «Stop». Обратите внимание на то что лучше хранить свои выражения, для источников, в файлах, так как после закрытия программы они все пропадают.

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

2.13 Compare

Данный плагин предназначен для поиска отличий в ответах двух разных запросов. Такая возможность может пригодиться при проверках на различные уязвимости, когда Вы визуально не можете определить что именно изменилось на странице и изменилось ли вообще. Сравнение происходит по формуле Левинштейна, что само по себе является ресурсоёмкой операцией (и, помоему, не только в Java). Из-за этого результатов сравнения иногда приходится ждать по нескольку минут.

Окно этого плагина состоит из нескольких частей. В самом верху находится выпадающий список содержащий все запросы прошедшие через WS. В нём нужно выбрать первый запрос для сравнения. После того как Вы сделаете выбор в средней, самой большой части окна, появится список запросов которые так или иначе связаны с выбранным или похожи на него. Найдя в этом списке интересующую Вас запись выберите её и ждите пока в нижней части окна не появится результат сравнения.

В результатах сравнения выделяются 3 типа данных — удалённые, изменённые, добавленные. Цвета, которыми выделены куски текста, имеют следующее значение. Зелёным выделяются вставленные данные, жёлтым — изменённые и розовым — удалённые.

2.14 Search

Как Вы уже догадались — это плагин поиска данных в запросах. Но есть одно «но» - поиск тут производится не по ключевым словам, а по BeanShell-выражениям. Звучит странно, но давайте попытаемся разобраться. В верхней части окна имеется панель выражений поиска. Слева, в колонке «Searches», имеется список поисковых выражений. В правой же части происходит их добавление. Поисковое выражение состоит из 2-х частей — описания («Description» - именно оно отображается в «Searches») и самого выражения(“Search Expression”). После заполнения обоих полей нужно нажать кнопку «Add» и выражение добавится в левую часть панели. Как видите — ничего сложного. Сам выбор выражения, результаты поиска по которому Вам нужно увидеть, осуществляется в выподающем списк идущем сразу под панелью добавления.

Теперь рассмотрим то что нужно вводить в поле выражения. Как я уже говорит — для поиска используются логические выражения на языке BeanShell. Например если Вы введёте

response.getContent() != null

то показаны будут запросы у которых в теле есть какое-либо содержимое. Вот так используя объекты «request» и «response», и все их доступные методы (ищите их описание в документации) пользователь может производить поиск по совершённым запросам. Я, например, такой метод поиска вижу впервые.

Вот и всё. Надеюсь что WebScarab понравился Вам и Вы найдёте ему приминения в своих исследовательских операциях. С помощью автора я постарался описать каждый неизвестный или неточный момент в программе, который не описан в справке и мог вызвать вопросы. Если бы в 2007 году разработка не остановилась то мы бы сейчас имели, пожалуй, самый лучший инструмент для pen-тестинга. Хотя, по сравнению с аналогами даже сегодня WS продолжает лидировать. Удачи!