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 код:
<?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 код:
<?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» поочерёдно начнут отправляться запросы со значениями из источника.
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 продолжает лидировать. Удачи!
WebScarab - профессиональный инструмент для анализа защищённости веб-приложений
![Аватар для [Raz0r]](/avatars/avatar33548.gif){kind=avatar}
![Отправить сообщение для [Raz0r] с помощью ICQ](fusion/misc/im_icq.gif)
Похожие темы
Линейный вид
