Flash и безопасность
В качестве вялых воскресных препирательств, на «Хабре»
Между тем, правил для защиты от таких «уязвимостей» всего два: выдавать при обращении к заливаемым пользователем Flash заголовки для скачивания (а то и вообще отдавать все пользовательские ролики с другого домена, порта или протокола) и указывать правильные параметры для проигрываемых роликов, залитых пользователем. Последнее — нехитрая наука, таких параметров всего три: allowScriptAccess, allowNetworking и allowFullScreen.
Их назначение легко расшифровывается по названию.
Параметр allowScriptAccess (введен во Flash 6.0.40.0) управляет доступом к JavaScript/DOM браузера и имеет три возможных значения: always, sameDomain и never. Пояснения, на мой взгляд, требует только значение sameDomain. Если выбрано это значение, то доступ предоставляется только скриптам, которые загружены с того же домена, что и страница, куда они подключены.
Следующий параметр, allowNetworking (работает, начиная с Flash 9.0) разрешает или запрещает обращение Flash к собственным сетевым функциям и сетевым функциям браузера. Имеет значения all, internal (запрещает использование сетевых функций браузера) и none.
Параметр allowFullScreen (Flash 9 и выше) принимает два возможных значения — false (выставлено по умолчанию) или true, которые (соотвественно) запрещают или разрешают использование полноэкранного режима.
Очевидно, что наиболее безопасные параметры — allowScriptAccess="never", allowNetworking="none" и allowFullScreen="false":
<object height="400" width="500">
<param name="allowScriptAccess" value="never" />
<param name="allowNetworking" value="none" />
<param name="movie" value="ролик.swf" />
<embed type="application/x-shockwave-flash"
allowScriptAccess="never" allowNetworking="none" src="ролик.swf" height="400" width="500" />
</object>Очень жаль, но значение «never» для параметра для параметра «allowScriptAccess» сейчас является deprecated, так же как и использование параметра allowNetworking, когда страница, на которой подключен ролик и сам ролик загружаются с одного и того же домена.
Насколько я понимаю, это связано с тем, что фирма Adobe, текущий владелец технологии Flash, не хочет брать на себя ответственно за утечку критичных данных через Flash-ролики. Вместо использования этих значений параметров рекомендуется загружать Flash-ролики с другого домена и не допускать того, чтобы критичные данные и ролики были доступны с одного домена.
Комментарии 12
Задолго до «Хабра» ( http://habrahabr.ru/blogs/infosecurity/75145/ ) и тех
Кстати, с помощью
В общем, должно совпасть несколько условий для внедрения и метод имеет смысл когда используются httpOnly cookie, если нет, то можно использовать сотни более простых способов.
Но исследование более чем любопытное. Я, кстати, никогда не исследовал «сертификаты» Flash. Правильно ли я понимаю, что ролик сам задаёт URL (прямо из своего
2. Да. Но в
3. И ещё одна хитромудрая мысль: без вникания в подробности, кроссдоменные сертификаты во флеш и в ява 6 — это «две больших разницы»…
Пункт 2 меня сильно беспокоит. Если allowNetworking="none" и allowScriptAccess="never" разве не защищают от атак полностью (при условии, что нет
Если не защищают, то какую атаку можно осуществить в этом случае? (Java меня слабо беспокоит, у меня есть доступ к очень хорошему санитайзеру, но Flash пользователи должны использовать).
Эти два атрибута полностью защищают, если мы имеем в виду размещение чужого ролика на своем сайте (т.е. там, где мы сами можем формировать теги object и embed).
Угроза безопасности наших данных в таком случае возникает только в том случае, если браузер, находясь на чужом сайте, где мы не имеем возможности определять атрибуты названных тегов, подрубает сам ролик или сертификат с нашего сайта, куда нам его предварительно подгрузили. Это очевидно.
Для исключения и этой угрозы нужен (а) контроль контента или разделение доменов (и все такое, о чем ты написал с самого начала), (б) в корне нашего сайта должен быть расположен сертификат c нужными нам настройками в тегах в
Естественно, последнее относится только к тем сайтам, которые разрешают пользователю
Санитайзер — вещь, конечно, хорошая, но Я могу тебе, например, сказать, что на твоем сайте этот вид атак возможен, поскольку во всем, что написано выше и традиционно говорится, когда обсуждается эта тема, есть одно «НО», которое знаю только Я, поэтому особо беспокоиться не стоит.
Ага, твой текст полностью подтверждает мои догадки :)
Про санитайзер я говорил в контексте проектов внутри «Яндекса», на моём сайте все эти атаки невозможны, если не подобрать пароля (а у меня есть всякие защиты, вроде обнаружения перебора, когда на любой пароль сайт будет говорить, что он не верный и пустит только с того IP, с которого был заход на определённый и известный только мне URL).
У меня просто пользователи файлы не заливают и сами HTML не формируют.
Ну, конечно… а Я и не заметил :)
Ты, типа, таинственно намекаешь на