Уязвимости online (журнал “Хакер”, #137)

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

Наиболее полную картину состояния защищенности той или иной инфраструктуры позволяют получить только комплексные методы анализа. Если говорить о веб-среде в общем и ее технологиях в частности, то подавляющее большинство распространенных уязвимостей представляют собой следствие некорректной работой того или иного алгоритма фильтрации входящих данных. И прошу не спешить бросать в автора камни, описывая причины появления и принципы обнаружения (эксплуатации) уязвимостей типа XSS/SQL-inj/PHP-including. Несомненно, техническая сторона атак подобного типа сильно отличается и направлена на разные объекты, но нас не интересует эксплуатация багов. Мы, как примерные аудиторы/пентестеры/администраторы, заинтересованы в их обнаружении, а методы обнаружения, в свою очередь, можно свести к принципу нахождения «нештатных» ситуаций в функционировании фильтров веб-приложения. Этого можно добиться только путем передачи фильтру различных входных данных. Кстати, именно так и поступают сканеры уязвимостей (да простят меня их разработчики), анализируя полученные результаты мощными эвристическими алгоритмами. Но имеется ряд ситуаций, когда использование этих инструментов не желательно для нас. Большинство серьезных коммерческих продуктов при сканировании целевого ресурса оставляют в логах веб-сервера записи, однозначно идентифицирующие факт сканирования, а иногда и узел, с которого оно проводилось. Вряд ли кто-то захочет лишней «популярности» в кругах администрации целевого сайта. К тому же процесс сканирования весьма ресурсоемок и требует временные затраты, которые, в некоторых случаях, эквивалентны денежным.

Думаю, самое время прекратить заниматься «болталогией» и приступить к созданию инструмента, который в силу своих особенностей, лишен вышеописанных недостатков и будет доступен для нас в виде веб-сервиса.

Глазами разработчика

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

Почему именно веб-сервис? Ну хотя бы потому, что аналогов его в русском сегменте интернета не имеется, а это значит, данная ниша будет интересна и разработчикам (деньги всегда были хорошим стимулом ;)) и пользователям, так как отсутствует необходимость устанавливать требовательные к ресурсам (и дорогие) продукты с целью просканировать свою домашнюю страничку для того, чтобы иметь приблизительное представление о ее состоянии защищенности. Другие причины можешь придумать сам, а я, с твоего позволения, перейду к теоретической части и непосредственно к кодингу.

И в первый день создал он…

Как я уже отмечал, наша разработка будет представлять собой веб-сервис. Попробуем дать более точное определение. Web-service – приложение, которое:

1. исполняется на web-сервере;
   
2. ожидает поступления HTTP-запросов и предоставляет web-методы для их обработки;
   
3. непосредственно исполняет web-методы и возвращает результаты.

У истоков данной технологии стоит Microsoft, которая реализовала ее в рамках Microsoft .NET. Кстати, именно веб-сервисы являются основной причиной, по которой .NET Framework вообще существует: максимально упростить разработку веб-сервисов и веб-клиентов. За примерами далеко ходить не надо – в предыдущем номере журнала мы рассмотрели, как с помощью технологии .NET Remoting можно быстро создать сеть распределенных вычислений.

И все же web-сервисы – не собственность MS, а являются промышленным стандартом на основе открытых протоколов HTTP и SOAP (Simple Object Access Protocol). Именно поэтому сервисы можно писать в любом текстовом редакторе, однако .NET Framework – несомненно, лучший вариант, упрощающий процесс кодинга. Кстати, кодить мы будем на языке C#, но ничто не мешает тебе писать приложение на любом другом языке, поддерживаемым ASP.NET – технологией создания веб-приложений от Майкрософт в рамках платформы .NET. С инструментами разобрались, теперь перейдем к проектированию логики приложения.

Хочу сразу сказать, что процесс создания онлайн-сканера будет рассмотрен на примере уязвимостей класса “Cross-Site Scripting” (также известного как XSS), так как на основу их поиска опираются методы обнаружения других багов (с точки зрения сканера, как автоматизированного инструмента). Тебе лишь, как программисту, нужно будет научить приложение передавать специальные данные и требуемым тобой образом обрабатывать полученные результаты. Моя же задача – продемонстрировать тебе особенности программирования веб-сервисов на концептуальном уровне, ну и, конечно, задать направление дальнейшего развития приложения и поделиться своими идеями. Но обо всем по порядку ;).

Рассмотрим логику работы сканера:

1. Переход по ссылке на целевой сайт.
   
2. Сбор всех скриптов на целевом сайте.
   
3. Определение всех параметров, принадлежащих конкретному скрипту.
   
4. Передача собранным параметрам специальных значений, характерных для данного вида уязвимостей.
   
5. Анализ полученного результата (произошло ли внедрение наших переданных значений в код страницы).

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

Напиши программу мышкой

Создается впечатление, что если Майкрософт продолжит развивать свои технологии, входящие в комплект .NET Framework, и среду программирования Visual Studio, то процесс создания программного обеспечения будет доступен для широких масс, исключительно владеющих мышкой и умеющих собирать конструкторы.

При создании проекта «ASP.NET Web Service Application» студия автоматически сформирует структуру каталогов, характерную для приложения данного типа и создаст все необходимые файлы для его корректного функционирования. Обычно структура проекта содержит в себе файлы одного или нескольких следующих типов:

• ASPX-файлы, содержащие web-формы;
  
• ASMX-файлы, которые, собственно, и реализуют web-сервисы;
  
• файлы Web.config, в которых описываются параметры конфигурации;
  
• файл Global.asax, который содержит глобальные элементы приложения;
  
• различные DLL, включающие в себя специфичные для приложения типы.

Файл ICholeScaner.asmx, находящийся в проекте (ищи его на нашем диске), демонстрирует несколько важных принципов программирования веб-сервисов с помощью .NET Framework. Вот содержание этого файла:

Директива @WebService содержит обязательный атрибут Class, задающий класс, из которого состоит веб-сервис, и атрибут CodeBehind, который содержит описание web-методов класса.

Web-методы объявляются в файле ICholeScaner.cs путем назначения открытым методам класса “ICholeScaner” атрибута [WebMethod]. Таким образом .NET Framework автоматически делает доступным этот метод для внешних вызовов.

В этом отражается вся суть веб-сервиса: предоставить функционал своих методов (то есть предоставить «сервис») для обработки данных, поступающих от клиента, который может являться как обычным пользователем, передающим информацию через какие-либо поля ввода, так и программой (сайтом), предоставляющим свои данные в автоматическом режиме средствами HTTP и SOAP. SOAP – это XML-язык для вызовов удаленных процедур по HTTP и другим протоколам.

Нашим веб-сервисом предоставляется метод StartScan, который принимает единственный строковой параметр – доменное имя целевого сайта и инициализирует процедуру сканирования. Если URL сервиса, например, www.site.com/icholescaner.asmx, то вот таким образом клиент может вызвать метод StartScan, переслав SOAP-конверт в HTTP-запросе.

Задача web-сервиса:

1. разобрать SOAP-конверт, содержащий входные данные;
   
2. выполнить сканирование;
   
3. сгенерировать SOAP-конверт, содержащий результат;
   
4. возвратить его клиенту в теле HTTP-отклика.

Также параметры сканирования можно задавать с помощью обычных HTTP-команд GET и POST, например:

GET /icholescaner.asmx/StartScan?domen=www.enemysite.com HTTP/1.1
Host: www.site.com

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

Да у вас жуки, батенька

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

Различают два «подтипа» XSS-уязвимостей: активные и пассивные (уязвимости, угу!). В двух словах: первые встраиваются непосредственно в код страницы и пользователю достаточно ее открыть, а вторые требуют активности со стороны компрометируемого (например, переход по специально сформированной ссылке). За подробностями атак этого типа я отправлю тебя (нет, не к гуглу) к сноскам в статье, где собран список полезных ресурсов, ждущих твоего внимания.

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

�