SPIKE и BURP для использования в реальном мире компьютерной безопасности (часть 1)

Published on Февраль 5, 2009 by   ·   Комментариев нет

HTTP прокси – это широко используемый инструмент для профессиональной компьютерной безопасности. Однако они практически совершенно не известны для большого сегмента компьютерных энтузиастов. Эта серия статей демонстрирует, как использовать HTTP прокси.

Если вы хотите прочитать другие части из этой серии статей, то, пожалуйста, перейдите по ссылкам:

HTTP прокси и вы

Мир компьютерной безопасности постоянно развивается. Постоянно находятся новые уязвимости в различных программах. Практически невозможно быть компетентным во всех аспектах компьютерной безопасности. Благодаря натуре компьютерной безопасности и ее многим и многим аспектам, необходимо выбрать свою нишу и попытаться специализироваться в этой области. Одна из таких областей – это безопасность web приложений в различных формах. Почему я говорю в различных формах? Не все web приложения написаны на одном и том же языке программирования. И не все из них удовлетворяют единой конфигурации или поддерживают back end программы.

В действительности, безопасность Web приложений – это очень хорошая и интересная область. Эти приложения разработаны для того, чтобы потенциальный клиент мог их использовать и взаимодействовать с ними. Только потому, что лицо компании в интернет было создано профессиональными программистами не означает, что в нем нет ошибок. Как раз наоборот, как мы все хорошо знаем. Практически невозможно написать код без ошибок независимо от того, какой язык программирования вы используете.

Это приводит нас к другому аспекту безопасности web приложений. Достаточно большое количество web приложений пишется на дому. Программист компании очень часто спешит завершить проект вовремя, и поэтому часто очень мало времени уделяет проверке кода. Существуют некоторые инструменты для проверки кода, но многие из них не всегда реально проверяют код. А те, которые действительно хороши в деле, всегда очень дорого стоят.

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

Итак, программист, наконец, закончил написание web приложения, которое ему было поручено. Теперь пришло время протестировать его и найти некоторые уязвимости. Как лучше всего сделать это? Действительно, очень хороший вопрос. Это приводит нас снова к цели этой статьи. Тестирование новых web приложений лучше всего проводить с помощью HTTP прокси. Это действительно очень замечательный инструмент, который позволяет разработчику взаимодействовать с web приложением таким образом, каким типичная web сессия не может воссоздать. Разработчик может перехватывать запросы, поступающие с клиентской стороны, и изменять практически любое поле внутри запроса для того, чтобы протестировать приложение.

Получите их наконец!

Я надеюсь, что вы еще не уснули. Но всегда очень важно предоставить дополнительную информацию о субъекте обсуждения, для того чтобы лучше понять его. Два HTTP прокси, которые мы рассмотрим и будем использовать, называются SPIKE и BURP suite. Первый был написан очень талантливым разработчиком Dave Aitel из компании Immunitysec, а BURP suite, насколько я знаю, был написан различными людьми. К сожалению, я не смог найти их имен.

Теперь пришло время установить прокси SPIKE, который вам необходимо загрузить по ссылке в предыдущем параграфе. Вы должны заметить, что для работы SPIKE, вы должны установить интерпретатор Python. Пожалуйста, зайдите на сайт CPAN и загрузите Python оттуда. Все что вам для этого понадобится – это всего лишь указать свой адрес электронной почты. Теперь, после того как вы загрузили и установили Python, вы должны также поместить SPIKE в корневую директорию диска c:\. Откройте командную строку DOS и зайдите в директорию, в которой установлен SPIKE. Вы должны прочитать файл README.txt, для того чтобы правильно настроить ваш web браузер. Рисунок 1 Рисунок 2 Последнее, что от вас потребуется – это просто напечатать в командной строке “runme.bat”. После того, как вы сделаете это, просто наберите в строке браузера строку http://spike/, и вы увидите SPIKE. Теперь мы готовы! Поздравляю, вы теперь установили и настроили HTTP прокси. Что с ним теперь делать? На этот вопрос достаточно легко ответить. Давайте немного поиграем с web сервером. В этом случае я просто установил Apache web сервер на другом образе VMware для тестирования. Это позволит нам разобрать работу SPIKE в контролируемой тестовой среде. Наконец, я установил урезанную версию моего собственного web сайта на сервер для тестирования. Время повеселиться! Если вы выполняете какую-либо профессиональную работу, вы всегда должны пользоваться каким-нибудь снифером (sniffer). Это необходимо для того, чтобы вы могли проверить выходные данные в случае получения странных результатов. Этот случай не исключение. Я использую tcpdump от компании MicroOLAP, который прекрасно работает на Windows XP SP2. Он бесплатен для домашнего использования. Об установке этого инструмента я уже несколько раз рассказывал в моих предыдущих статьях, поэтому здесь я пропущу ее описание. Проще говоря, распакуйте файл и установите его в вашу корневую директорию C, т.е.: c:\. Теперь, когда у нас есть снифер, мы просто укажем ему заносить в журнал информацию о пакетах, которые проходят от компьютера, на котором установлен SPIKE, и компьютером, на котором установлен наш Apache web сервер. В дальнейшем, вы можете уточнить это, настроив tcpdump записывать в журнал пакеты с портом 80. Пример того, как это можно сделать с помощью tcpdump, вы можете увидеть ниже на рисунке 3. Рисунок 3 Вы можете увидеть, что за секунду я собрал 945 пакетов, а затем закрыл сессию работы с tcpdump. Это другой тип деятельности, которую я произвожу параллельно на моем компьютере. Это наглядно показывает, для чего нужно фильтровать пакеты при тестировании в тестовом окружении или при реальной работе. Теперь, мы видим, что есть достаточно большое количество вещей, о которых необходимо помнить, перед тем как двинуться дальше изучать работу HTTP прокси. Всегда приходится выполнять некоторую подготовительную работу перед тем, как попытать изучить что-то новое. Иначе, вы легко можете запутаться сами, а что еще хуже – вы можете разочароваться и прекратить изучение определенного инструмента. На этом мы прерываем нашу статью, но учтите, что очень скоро появится вторая часть нашей статьи, посвященной использованию HTTP прокси. Скоро увидимся!

Источник www.windowsecurity.com


Смотрите также:

Tags: , , ,

Readers Comments (Комментариев нет)




Да человек я, человек! =)




Exchange 2007

Проведение мониторинга Exchange 2007 с помощью диспетчера System Center Operations Manager 2007 (часть 3)

Если вы хотите прочитать предыдущие части этой серии статей, перейдите по ссылкам: Проведение мониторинга Exchange 2007 с помощью диспетчера System ... [+]

Практическое рассмотрение перехода с Exchange 2003 на Exchange 2007 (часть 1)

Введение В этой статье из нескольких частей я хочу показать вам процесс, который недавно использовал для перехода с существующей среды Exchange 2003 ... [+]

Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (часть 2)

Если вы пропустили первую часть этой серии, пожалуйста, прочтите ее по ссылке Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (Часть ... [+]

Мониторинг Exchange 2007 с помощью диспетчера System Center Operations Manager 2007 (часть 2)

Если вы пропустили предыдущую часть этой серии статей, перейдите по ссылке Мониторинг Exchange 2007 с помощью диспетчера System Center Operations ... [+]

Подробное рассмотрение подготовки Active Directory для Exchange 2007 (часть 5)

Если вы пропустили предыдущие части этой серии статей, перейдите по ссылкам: Подробное рассмотрение подготовки Active Directory для Exchange 2007 (часть 1) ... [+]

Установка и настройка Exchange 2007 из командной строки (Часть 3)

If you missed the previous parts in this article series please read: Exchange 2007 Install and Configuration from the command line (Part ... [+]

Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (часть 1)

Инструмент ExRCA Текущий выпуск инструмента предоставляется только в целях тестирования и оснащен 5 опциями: Тест подключения Outlook 2007 Autodiscover Тест подключения Outlook 2003 RPC ... [+]

Развертывание сервера Exchange 2007 Edge Transport (часть 5)

Если вы хотите прочитать предыдущие части этой серии статей, перейдите по ссылкам: Развертывание сервера Exchange 2007 Edge Transport (часть 1) Развертывание ... [+]

Установка и настройка Exchange 2007 из командной строки (часть 2)

Если вы пропустили первую статью данного цикла, пожалуйста, перейдите по ссылке: Exchange 2007 Install and Configuration from the command line (Part ... [+]

Использование интегрированных сценариев Using Exchange Server 2007 – часть 2: генерирование отчетов агента Transport AntiSpam Agent

Если вы пропустили предыдущую часть этой серии статей, перейдите по ссылке Использование интегрированных сценариев Using Exchange Server 2007 – часть ... [+]