Поиск XSS уязвимостей во Flash приложениях


Cross Site Scripting во Flash приложениях

Тщательно проанализировав N-нное количество веб сайтов, и обнаружив на них присутствие XSS уязвимости во Flash приложениях,

flash based xss
складывается впечатление, что многие веб разработчики просто не хотят знать знают о таком типе атак, или с трудом себе представляют, как от них защитится.

Part.1 Вводная и подводные

Если вы являетесь постоянным читателем моего блога, то вы знаете  вы наверняка прочитали мою статью о хранимой XSS во Flash приложениях. Во всяком случае, ссылка на материал уже полгода как висит в хедера этого блога, и все неравнодушные к IT безопасности читатели, думаю обратили на нее внимание.

Для эксплуатации хранимой XSS в ActionScript может быть использован метод loadMovie(javascript:evilcode), который вешается на объектный символ клип, и выполняется при загрузке флеш ролика. В то время, как объектный символ кнопка может быть использован по прямому назначению.

На многих популярных сайтах, например вконтакте, стоит защита от загрузки исполняемых файлов, следовательно, нужно жестко контролировать все, что пользователь может загрузить на сервер (фото, аватары, подписи и т. д.)

Но в контексте данной статьи, я бы не стал исключать и более абсурдные методы атаки, когда некий партнер, предлагает вам разместить на своем сайте рекламный баннер, причем на о_Очень выгодных условиях, например с оплатой за показ и т. д.

В таких случаях достаточно посмотреть исходный код ActionScript и сделать правильные выводы.

Для декомпилирования Flash роликов можно использовать Flash Decompiler Trillix (отлично экспортирует swf в fla, который можно переделать и скомпилировать обратно в swf), SwfScan и т. д.

На этом вялая часть о хранимых XSS заканчивается и начинается бодрая о Cross Site Flashing.

Cross Site Flashing или Flash Based XSS

Как говорит один мой друг и коллега: DOM Based XSS очень интересная уязвимость, а Flash XSS еще интереснее. 😀

Когда я писал статью о XSS атаке с помощью Flash приложений, то немного слукавил о том, что Flash анимация сегодня не так популярна, на самом деле она популярна еще и не так.

Flash баннеры присутствуют повсеместно на популярных сайтах и порталах.  Вопрос в том, уязвим ли код ActionScript к XSS атакам или нет?

OWASP выделяет 13 методов используемых в ActionScript, которые могут быть подвержены XSS уязвимостям.

getURL();
loadMovie();
loadMovieNum();
loadVariables();
FScrollPane.loadScrollContent();
LoadVars.load; 
LoadVars.send; 
XML.load('url');
LoadVars.load('url'); 
Sound.loadSound('url',isStreaming); 
NetStream.play('url');
flash.external.ExternalInterface.call(_root.callback);
htmlText.

 

Да простят меня поисковые гиганты Яндекс и Google за копипаст (это база, ее никак не отрерайтить) этих 13 строк, дальше только своими словами. 😀

Метод getUrl() — используется практически во всех флеш баннерах, собственно они и размещаются для тех целей, чтобы юзер кликая по баннеру переходил на сторонний (рекламируемый) ресурс.

Пожалуй на нем я и остановлюсь.

Метод getURL() имеет три параметра: getURL(URL, window, method)

Обязательным из этих трех параметров является URL, который загружает адрес во фрейм или окно браузера, но также может выполнять JavaScript код в браузере клиента.

Веб разработчики очень часто допускают ошибку при работе с этим методом. Дальше будет простой пример XSS уязвимости в обнаруженном сегодня флеш ролике на одном достаточно популярном сайте.

getUrl ActionScript XSS

Содержание HTML кода страницы:

<param name="movie" value="/images/8AQA.swf?mrlink=/redirect.php?bid=127895">

ActionScript код декомпилированного Flash приложения

//ActionScript код баннера конечно огромный, вот первый уязвимый участок
//Button 2
//On release
on (release)
{
getURL(_root.mrlink, "_blank");
}

Нажатием на объектный символ кнопка (Button 2) вызывается метод getUrl();

Повторение мать учения переменная _root.mrlink получает значение из параметра:

<object><param value="/images/0295BAD_2.swf?mrlink="/reflink.php"></object>

который находится в Html коде веб страницы.

Следовательно, если ссылка будет сформирована таким образом:

0295BAD_2.swf?mrlink=javascript:evilscript=alert(document.cookie)

То по нажатию на кнопку, будет выполнен JavaScript. Название флеш баннера (0295BAD_2.swf) в данном случае полностью себя оправдывает.

Проверить наличие XSS можно через урл.

Flash XSS

 Это всего лишь самый банальный простой пример XSS уязвимости в Flash приложении, который можно найти в исходном коде Html страницы. 😉

Для анализа объемного ActionScript кода лучше использовать сканер HP SwfScan, который покажет не только найденные уязвимости, но и предложит Fix.

Надеюсь из статьи вам стало немного понятно, откуда ноги растут для XSS в флеш приложениях.

Главное: чтобы верхние конечности росли не отсюда из другого места. 😀

Но т. к. это все таки не урок биологии, то пожелаю лучше своим читателям бдительности и бодрого настроения!

P.S. Возможно о подробном описании XSS и последующей защите Flash приложений можно написать книгу (и вероятнее всего даже не одну) но о тестировании «других» методов ActionScript будут написаны «другие» статьи, которые сейчас находятся в активной одной из приоритетных разработок. 😉

з.ы.В общем, вот такая получилась вводная статейка.. при декомпилировании не один флеш баннер не пострадал. 😀