Как скомпрометировать веб-приложение? История атаки (часть 2)

14.03.2014 | Ровнов Павел
Want create site? Find Free WordPress Themes and plugins.

В предыдущей части блога был рассмотрен один из возможных сценариев атаки на target.by. В качестве возможного вектора атаки на веб-приложение выбран open source «движок» для управления рекламой, размещенный в домене *.target.by.
Вообще говоря, в домене *.target.by мог бы размещаться любой «движок» – важно, что это не уникальная разработка, а коробочное решение. Поскольку информация об уязвимостях коробочных веб-приложений публична, злоумышленник, скорее всего, первым делом проверит, может ли какая-либо из известных уязвимостей служить целям атаки.
В общем и целом, для того, чтобы выяснить перечень известных уязвимостей, необходимо знать тип и версию приложения. Как правило, приложения не скрывают информацию о себе: достаточно внимательно просмотреть содержимое заглавной страницы или же заглянуть в её исходный код.

После того как версия рекламного «движка» будет выяснена, злоумышленник мог бы воспользоваться любым из общедоступных сайтов, размещающих информацию об известных уязвимостях, как к примеру, securityfocus.com.

Информация об уязвимости наряду с описанием часто включает и exploit – инструмент, с помощью которого описанную уязвимость можно реализовать. В случае «Multiple Products banner.swf XSS» описание уязвимости (оно же – exploit) умещается в одну строку:

httр://www.example.com/path/banner.swf?clickTAG=javascript:alert(‘XSS’)

«Banner.swf» – рекламный баннер, разработанный на технологии Adobe Flash. Параметр «clickTAG», передаваемый в баннер, должен по задумке указывать на URL, по которому перейдет пользователь после клика на баннер. Однако, в случае, если в качестве параметра «clickTAG» вместо URL передан скрипт, после клика на баннер этот скрипт будет выполнен на стороне клиента. Используемая уязвимость находится, как ни странно, в коде ActionScript баннера (разработчики баннеров, по всей видимости, далеки от написания «безопасного» кода). Подробнее об истоках уязвимости – читайте Designer’s Guide на Adobe.
Для злоумышленника описанная выше уязвимость дает возможность выполнить вредоносный скрипт в браузере пользователя. Общие условия для выполнения скрипта: пользователь переходит на веб-страницу с баннером, в который передан код скрипта, и кликает на баннер. Дополнительное техническое условие накладывается на домен размещения баннера (и вместе с ним скрипта в параметре «clickTAG»). Домен должен принадлежать target.by: только в этом случае скрипт будет иметь доступ к cookie target.by. Иначе сработает механизм браузера «same origin policy», который запрещает скриптам, размещенным в доменах, отличных от target.by, получать доступ к объектам домена target.by.
Скорее всего, далее злоумышленник будет рассматривать всевозможные варианты размещения контента в target.by. Часто можно увидеть, что в составе веб-приложения имеется или форум, или блог, или просто существует возможность оставлять комментарии. По одному из этих путей, вероятнее всего, пойдет злоумышленник для размещения баннера и вредоносного скрипта.
Остается лишь один вопрос: как сможет злоумышленник «заставить» пользователя кликнуть на рекламный баннер? Ответ простой – заинтересовать пользователя, к примеру, оставив следующий комментарий: «Ну, вот что можно на это сказать?! <ссылка на баннер>». Невозможно не поинтересоваться, что скрывается за ссылкой, правда?
После того, как сценарий атаки известен, злоумышленнику остается лишь разработать скрипт на JavaScript, который будет выполняться в тот момент, когда пользователь кликает на баннер. Скрипт будет отправлять cookie на сервер злоумышленника и для того, чтобы не вызвать подозрений со стороны пользователя, выполнять перенаправление браузера пользователя на сайт в соответствии с содержанием рекламного баннера (точно так же, как это делает «обычный» клик на рекламном баннере). Поскольку в сети хватает примеров реализации вредоносных скриптов для кражи cookie, здесь они приводиться не будут.
Итак, подведем итоги. В рассмотренном сценарии, злоумышленник мог бы заполучить полномочия пользователя веб-приложения, используя при этом лишь известные уязвимости и типовые атаки. Можно было ли предотвратить атаку? Как и говорилось ранее — можно, предприняв верные шаги по защите веб-приложения. Но это уже совсем другая история.

Did you find apk for android? You can find new Free Android Games and apps.
Комментариев пока нет
Добавить комментарий