Локальный прокси – профессиональный инструмент специалиста по безопасности

Какие преимущества нам дает использование локального прокси-сервера? Прежде всего это полная свобода действий над входящими и исходящими пакетами, а также над web-контентом. Настроив свой браузер на работу с ним, Вы сможете блокировать баннеры, подозрительный javascript-код и опасные тэги. Другими словам, локальный веб-прокси с правильно настроенными фильтрами осуществляет полный контроль над web-содержимым. Однако поле применения данного средства намного шире, в частности локальные прокси могут быть полезны для обнаружения уязвимостей в web-интерфейсах и проведения тестов на проникновение.

Мне известны две подобные программы – это Proxomitron и Privoxy. Первая разрабатывалась еще для Windows 95; последняя версия – Naoko 4.5, релиз которой состоялся в 2003 году. К сожалению, в настоящее время программа не обновляется, однако ее возможностей мне вполне хватает и, уверен, хватит еще надолго. Privoxy – кросплатформенный аналог Proxomitron’а. Обычно его используют в связке с TOR’ом – сетью, обеспечивающей безопасность трафика. GUI-интерфейс у программы как таковой отсутствует. Все правила для фильтрации веб-контента необходимо вручную указывать в текстовых конфигурационных файлах. На лицо издержки кроссплатформенности, но если вы поклонник консоли и линукса, то эта программа будет Вам по душе. Я же предпочитаю Proxomitron, именно о нем в этом посте и пойдет речь.

Прежде чем начать работу с программой необходимо настроить свой браузер на взаимодействие с локальным прокси. По умолчанию Proxomitron занимает порт 8080, который можно изменить в настройках программы. Главное окно выглядит так:

Имеется две основные панели: Active filters и Edit filters. Во второй находятся кнопки Web page и Headers, нажав на любую из которых мы сможем добавлять и изменять фильтры.

Proxomitron – удивительно гибкий инструмент. Почему? Потому что самое главное его достоинство – это поддержка регулярных выражений, по которым можно проводить фильтрацию трафика. Если Вы еще не оценили мощь регулярок, то самое время начать изучение =)

Главное предназначение программы для меня – это обеспечение анонимности в Сети. Главным образом это достигается путем использования скрипта-анонимайзера на удаленном сервере; с помощью Proxomitron браузер прозрачно для пользователя посылает на него запрос и возвращает данные. Я использую анонимайзер собственного написания, который также сжимает трафик gzip’ом. Скрипт я выложу в одном из следующих постов, пока же разберемся как организовать редирект запросов на наш удаленный прокси.

Итак, открываем страницу с настройками фильтров для HTTP-заголовков. Находим фильтр URL: Alias Redirector (Out) и нажимаем кнопку Edit. В полях URL Match и Header Value Match указываем *, это означает, что программе необходимо фильровать все страницы с любыми хэдерами. В поле Replacement Text пишем следующее:
$RDIR(http://yourhost/compressor.php?url=\u)
$RDIR – это встроенный оператор Proxomitron’а, который перенаправляет запросы на указанный адрес; \u – это также встроенный метасимвол программы, который представляет собой запрашиваемый URL оригинальной страницы. Сохраняем фильтр и ставим галку в поле Out. Готово! Теперь все запросы будут идти на наш прокси:

GET http://yourhost/compressor.php?url=http://someotherhost.ru/index.php HTTP/1.1

Более подробно об этом способе можно почитать в этой сатье

Аналогичным способом можно не только изменять хэдеры, но и добавлять свои, которые будут дописываться к HTTP-запросу налету. В примере выше недостаток заключается в том, что URL передается в GET-параметре. Гораздо надежнее указывать URL запрашиваемой страницы в отдельном заголовке, особенно в том случае, когда наш анонимайзер расположен на стороннем сервере. Релизовать данный метод очень просто: в предыдущем фильтре убираем ?url=\u и создаем новый.

HTTP Header REQUESTURL
Replacement text \u

Анонимайзер естественно должен учитывать откуда ему следует брать URL:

<?php
$url = $_SERVER['HTTP_REQUESTURL'];
?>

При проведении аудита веб-приложений зачастую необходимо изменять HTTP-пакеты для анализа реакции на определенные специально сформированные заголовки. Как правило, это USER_AGENT, REFERER, X_FORWARDED_FOR, CLIENT_IP, VIA. Многие веб-приложения некорректно обрабатывают данные из этих заголовков, что приводит к разного рода атакам, чаще всего к SQL-инъекциям. При анализе различных CMS я использую Proxomitron со специальным набором фильтров, которые помогают при обнаружении уязвимостей. Например, однажды я натолкнулся на сайт, где были заметны признаки SQL-инъекции: при вводе кавычки после числа в параметре id меня перекидывало на главную страницу. Очевидно, что сервер возвращал HTTP-заголовок Location, где была указана главная страница сайта. Открыв Log Window, который позволяет в реальном времени следить за входящими и исходящими пакетами, и повторив запрос, я убедился, что сервер, действительно возвращал заголовок Location. Далее я добавил в Proxomitron следующий фильтр:

HTTP Header Location
URL Match *

Поля Header Value Match и Replacement Text оставил пустыми, т.е. данный фильтр затирает заголовок Location. Снова обратившись к серверу с кавычкой в параметре id, я получил ошибку MySQL. Моя интуиция меня не подвела, SQL-инъекция действительно имело место. Но почему так произошло? Дело в том, что некоторые разработчики не останавливают выполнение скрипта после вызова функции header(). Т.е. код имеет примерно такой вид:

<?php
if (isset($_GET[‘id’]) && !is_numeric($_GET[‘id’])) {
            header("Location: index.php");
}
$result = mysql_query("SELECT * FROM articles WHERE id=".$_GET[‘id’]);
?>

Аналогично в некоторых CMS допускаются ошибки при авторизации пользователей:

<?php
if (!isset($_SESSION["log"]) || !isset($_SESSION["pass"])) //unauthorized
{
	//show authorization form
	header("Location: access_admin.php");
}
?>

Такую уязвимость мне удалось обнаружить в Shop-Script

Изменять страницы налету также бывает очень удобно, например если нужно дописать какие-либо js-скрипты или модифицировать тэги. Распространенная трудность, связанная с ограничением количества вводимых символов в тэгах input, может быть легко решена с помощью Proxomitron. Автор вот этой статьи, недавно появившейся на сайте журнала “Хакер” явно не в курсе о существовании этого действительно полезного инструмента =) Итак, нам необходимо убрать maxlength – создаем новое правило на странице Web page:

Filter Name MaxLength
URL Match *
Bounds Match
Byte Limit 256
Matching Expression maxlength=”
Replacement Text nomaxlength=”

Вот и все! Активируем наш фильтр и забываем про ограничения! Таким же способом можно изменять определенные js-выражения. Например, если js-скрипт пытается отправить наш реферер, то заменим фильтром .referrer на .referrer.substr(0,0)+”\u”.

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