Cross Site Scripting атаки через Flash-анимацию: угрозы и защита

21:57 / 5 мая, 2005

Подробный анализ уязвимостей Cross Site Scripting (XSS) в Flash-анимации, методы атак и способы защиты веб-приложений.

Внимание: Информация в этой статье предназначена для образовательных целей и повышения осведомленности о безопасности. Использование этих знаний для вредоносных действий незаконно и неэтично.

Содержание

Введение
Web-приложения и Cross Site Scripting
Предотвращение Cross Site Scripting атак
Flash! атака
Уязвимые ресурсы и примеры программ
Способы предотвращения
Демонстрационный пример на eyeonsecurity.org
Ссылки
Благодарности

Введение

В этом документе мы опишем уязвимость найденную на многих web-сайтах, которые позволяют вставлять пользователям Flash анимацию в HTML-код страницы или загружать её на сервер. Эта статья предпологает, что огромное количество web серферов имеют установленый Macromedia Flash/ActiveX плагин, позволяющий атакующему выполнять кросс-сайт скриптинг атаки. Мы не будем затрагивать общие вопросы атак класса кросс-сайт скриптинг; Однако мы надеемся, что эта статья объяснит, как Flash ролики могут быть использованы для выполнения произвольного JavaScript кода в приложениях тщательно фильтрующих JavaScript.

Web-приложения и Cross Site Scripting

Web-приложения состоящие не только из статической информации позволяют пользователям взаимодействовать с содержимым сайта[1]. Примерами таких сайтов могут служить Hotmail, Yahoo, MSN и огромный список других сайтов. В большинстве случаев, это обязывает пользователей к аутентификации для обеспечения многопользовательского взаимодействия. В интеренет сообществе таком как deviantART[2], каждый пользователь имеет собственную секцию и место на сайте, куда он или она могут размещать результаты своих творческих работ, таких как поэзия, графические работы (обычно в jpg формате), фоторгафии и конечно же Flash анимация. Зарегистрированные пользователи (и анонимные тоже) могут просматривать работы других людей. Это означает, что публикуемые материалы и файлы доступны другим пользователям. С точки зрения безопасности, это подразумевает доверие между владельцем файла и человеком просматривающим файл. Кросс-сайт скриптинг, или сокращенно XSS[3], является типичной атакой на уязвимость использующую доверие пользователя к просматриваемому содержимому. Проще говоря, XSS атака направлена на пользователя просматривающего содержимое (измененое атакующим), содержащее опасный код, например JavaScript, позволяющий перехватывать сессии аутентификации или персональные данные пользователя.

Предотвращение Cross Site Scripting атак

- методы используемые в настоящее время

Для обеспечения безопасности Web приложений разработчики используют любой из трех подходов для предотвращения XSS атак:

Отвергаются все HTLM коды введенные пользователем
Разрешаются только определенные теги. Это обычно достигается использованием специальных кодов, которые приложение заменяет на соответствующие кодам теги
Фильтруются или удаляются все элементы скриптов из HTML кода

Считается, что эти методы защищают от внедрения произвольных HTML тегов и скриптов. Web приложения такие как Hotmail и Yahoo Mail пытаются предотвратить все возможности внедрения JavaScript кода (и активного содержимого) используя тщательную фильтрацию. Различные компании «авторитеты» в области интернет технологий такие как CERT[4] и Microsoft[5] подробно описали методы фильтрации и возможную опасность атак класса XSS.

Существуют web приложения, позволяющие публиковать на сайте Flash анимацию, такие как deviantART, либо просто закачивать Flash ролики для хранения, подобно FTP сайтам.

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

Flash! Атака

Файлы Macromedia Flash имеют собственный встроеный язык скриптов. ActionScript[6] (язык сценариев) может показаться очень простым для программиста знающего JavaScript, т.к. имеет синтаксис схожий с Javascript, Си и PERL. Однако, этот простой язык может быть использован для программирования сложных сцен анимации, моделирования, создания игр и т.д. Для нас представляет интерес функция getURL()[7]. Эта функция позволяет нам переадресовать конечного пользователя к другой странице. В качестве входного параметра обычно используется URL; например «http://eyeonsecurity.net», в скрипте это выглядит так:

getURL("http://eyeonsecurity.net")

Попробуем передать JavaScript, вместо значения URL:

getURL("javascript:alert(document.cookie)")

Результатом выполнения этой функции будет вывод окна со значениями cookies пользователя, установленными браузером для сервера со страницы которого был показан Flash файл. Это означает, что мы успешно внедрили JavaScript код используя возможности браузера и Flash. В демонстрационном примере Flash файла мы использовали вышеприведенный скрипт как показано в скриншоте.

Уязвимые ресурсы и примеры программ

Ezboard (http://ezboard.com/) является, вероятно, одной из самых лучших бесплатных скриптов досок объявления. В этой системе досок объявлений взамодействие с пользователями происходит через web интерфейс и позволяет вставлять в подписи пользователей Flash (используя тег EMBED). В наших испытаниях мы отредактируем настройки подписи следующим образом:

<embed
 src="http://eyeonsecurity.net/download/example.swf"
 pluginspage=
 "http://www.macromedia.com/shockwave/download/
 index.cgi?P1_Prod_Version=ShockwaveFlash"
 type="application/x-shockwave-flash"
 width="0"
 height="0"
 >
 </embed>

Ниже приведен скриншот, иллюстрирующий эту идею:

Этот код будет добавлен к каждому посту атакующего. Любой из посетителей сайта просмотревший этот пост будет подвержен атаке, в результате которой будут похищены cookies.

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

Сообщество MSN[8] — это сайт который позволяет пользователям загружать файлы на сервер. SWF файлы (содержащие JavaScript код) — один из форматов фалов разрешенных к загрузке. Это очень серьезный недостаток в безопасности. В предыдущей статье[9] EyeonSecurity, которая называется «Атака на аккаунт Microsoft Passport», мы акцентируем внимание на том, как единственная уязвимость в технологии Passport создаёт существенную проблему в безопасности.

Анонимные сервисы типа Anonymizer[10] и The-Cloack[11], также уязвимы к этой атаке. Эти сервисы фильтруют любой JavaScript код на HTML страницах, но не в состояние противостоять атакам описанным в этой статье.

Популярные движки форумов Ikonboard и YaBB[12] особенно уязвимы к этой атаке. Эти форумы позволяют использовать специфические теги [flash], преобразуемые приложением в корректные теги <Object>.

Пример

[flash]http://eyeonsecurity.net/download/example.swf[/flash]

Эта строка преобразуется приложением в следующий код:

<object
       classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" 
       width=200
       height=200>
<param
       name=movie
       value=http://eyeonsecurity.net/download/example.swf>
<param
       name=play
       value=true>
<param
       name=loop 
       value=true>
<param name=quality
       value=high>
<embed
       src=http://eyeonsecurity.net/download/example.swf
       width=200 
       height=200 
       play=true 
       loop=true 
       quality=high>
</embed>
</object>

Конечно же число уязвимых приложений не ограничивается этими примерами. Любой онлайн сервис позволяющий размещать Flash анимацию уязвим к XSS атакам. Представители сайтов описанных в этой секции были уведомлены относительно этой уязвимости прежде, чем этот документ был опубликован. Это означает, что многие примеры в настоящий момент уже не работают.

Способы предотвращения

Простое решение: запретите размещение Flash файлов на Вашем сайте.

Однако, в большинстве случаев, не всё так просто. Например рассмотрим случай с DeviantART. Для этого ресурса Flash анимация неотъемлемая часть контента. Они не могут просто отказаться от использования Flash.

Возможные решения от:

Macromedia (разработчики Flash плеера)

Macromedia и EyeonSecurity вели совместные работы для того чтобы найти решения для web разработчиков. Было предложено разрешить web- дизайнерам изменять поведение помещенного в html страницу Flash-контента. Это решение подходит для публикаций в форумах и подобным сайтам, но разработано не для того, чтобы искажать/ломать какие-либо из существующих анимационных Flash роликов.

Тем не менее, это решение не адресовано таким web сайтам, как MSN Communities и DeviantART. Эти сайты позволяют пользователям размещать файлы SWF, что предпочтительнее, чем ссылаться на них. Macromedia (так же как и EoS) активно препятствует разработке web-приложений, позволяющих пользователям размещать непроверенный Flash-контент.

Нужно заметить, что взаимодействие между HTML страницей (и JavaScript или другим активным содержимым) и Flash файлом поддерживается несколькими функциями[13], и метод, описанный в этом документе это скорее метод взлома, а не поддерживаемая функция. Тем не менее, достаточно известное приложение для создания Flash-роликов под названием Swish[14], использует JavaScript метод для того, чтобы дать возможность web-дизайнерам включать их собственный код на JavaScript. Macromedia выпустила статью-описание по этому поводу 13 июня 2002: http://www.macromedia.com/v1/handlers/index.cfm?ID=23051

Web-дизайнеры и web-разработчики

Хорошим решением было бы «пропарсить» flash анимацию и отфильтровать опасные параметры в getURL(). Это касается случая, когда web-приложения позволяют закачивать SWF файлы на сервер. Web-мастера всегда особенно стараются проанализировать и отфильтровать Flash-контент, если они разрешают пользователям закачку. Web-мастера могут блокировать любой Flash-контент, содержащий getURL(). Другое решение — сделать так, чтобы все действия getURL() выполнялись в новом окне. Это может быть достигнуто, если в качестве параметра target задать значение «_blank». Если применить вышеописанные изменения, то JavaScript URLы не будут исполняться с привилегиями домена. Однако, как замечено Bertrand Saint-Guillain[15], это решение не является безупречным в связи с тем фактом, что ActionScript — это мощьный скриптовый язык и в нем есть функция eval(). Эта функция позволяет более искушенным перцам игнорировать «парсинг» ActionScript.

Пример:

a="get";
b="URL"; 
c="javascript:"; 
d="alert('bypassed');void(0);";

eval(a+b)(c+d);

Код этого примера обойдет любую защиту, предлагаемую выше, т.к. нет getURL('javascipt:whatever'). Кроме того, есть еще одно, пожалуй более подходящее, решение — использовать разные домены для хранения и отображения Flash-роликов. Этот способ также может быть использован, чтобы сделать доступным активный контент и в других документах, таких как файлы HTML. Это значит, что если ваш домен securewebapplication.com, то вы могли бы хранить потенциально опасный контент на securewebapplication.net. Конечно это означает, что контент securewebapplication.net не требут аутентификации при помощи сессий, таким образом он доступен анонимным пользователям. Важно, чтобы потенциально опасный контент отображался только из «обезвреженного домена», это значит, что если флэш документ включен в файл HTML, то и этот HTML файл также должен быть отображен из «обезвреженного» домена.

Web-разработчики также могут воспользоваться IFRAME, который ссылается непосредственно на Flash-анимацию, находящуюся на ином домене вместо использования тегов EMBED или OBJECT. В таком случае Flash-анимация работает точно так же, но подгружается из дочернего фрейма, исключая таким образом возможность использования JavaScript для кражи cookies и других XSS-атак. Впервые этот способ описали на форуме Neworder[16], а потом об этом распространилась[17] и Macromedia. Хотя это решение и является качественным, оно, тем не менее, ведет к меньшей совместимости с браузерами, которые не поддерживают IFRAME[18].

Демонстрационный пример на eyeonsecurity.org

Демонстрационный пример, проблемы описанной в этой статье, доступен по этому адресу: http://eyeonsecurity.org/advisories/flash-demo/

Ссылки