Flash и безопасность

В качестве вялых воскресных препирательств, на «Хабре» как-то неожиданно вылезла мнимая проблема Flash — что загрузив ролик, можно попытаться получить доступ к cookie сайта или сделать какие-то другие интересные недобрые вещи.

Между тем, правил для защиты от таких «уязвимостей» всего два: выдавать при обращении к заливаемым пользователем 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-ролики с другого домена и не допускать того, чтобы критичные данные и ролики были доступны с одного домена.
15 ноября 2009 14:17

olo-olo-lo (olo-olo-lo.ya.ru)
15 ноября 2009, 18:18

И не забудем про кроссдоменные сертификаты... Так что правил три, как минимум.

Задолго до "Хабра" (http://habrahabr.ru/blogs/infosecurity/75145/) и тех горе-специалистов по безопасности эта возможность была описана здесь: http://www.securitylab.ru/contest/300506.php. В последствии от многих проектов последовала даже реакция. А в англоязычном интернете идея появлялась еще раньше.

Кстати, с помощью java-апплетов можно сделать то же и намного больше: http://forum.antichat.ru/showthread.php?p=1387662 . Учитывая изложенное, гениальных тем про фундаментальные баги в java осталось ждать недолго - всего года два.

bolk (bolknote.ru)
15 ноября 2009, 18:51, ответ предназначен olo-olo-lo (olo-olo-lo.ya.ru):

Гм, а я-то думал, что чтобы получить доступ к cookie из Java-апплета потребуется либо сертификат, либо запрос полномочий у пользователя.

bolk (bolknote.ru)
15 ноября 2009, 18:54, ответ предназначен olo-olo-lo (olo-olo-lo.ya.ru):

Прочитал про апплет и не понял что это. Это для случая, когда можно внедрить фильтруемый HTML, в котором разрешено использование APPLET?

olo-olo-lo (olo-olo-lo.ya.ru)
15 ноября 2009, 19:20

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

bolk (bolknote.ru)
15 ноября 2009, 19:24, ответ предназначен olo-olo-lo (olo-olo-lo.ya.ru):

В общем, должно совпасть несколько условий для внедрения и метод имеет смысл когда используются httpOnly cookie, если нет, то можно использовать сотни более простых способов.

Но исследование более чем любопытное. Я, кстати, никогда не исследовал «сертификаты» Flash. Правильно ли я понимаю, что ролик сам задаёт URL (прямо из своего AS-кода) из которого он этот сертификат хочет получить?

olo-olo-lo (olo-olo-lo.ya.ru)
15 ноября 2009, 19:39

1. Конечно, есть ограничения. Основное же преимущество в том, что в большинстве случаев можно получить cookie, даже если у пользователя выключен js.
2. Да. Но в 10-й версии есть ограничения: сначала ролик проверяет корень сайта и ищет сертификат там. Когда находит, смотрит метаполитику в нем. Если метаполитикой разрешено, он может использовать альтернативное место расположения, указаное пользователем. Есть ограничения специально для роликов, использующих сокеты. Подробнее на русском: http://flexconstructor.blogspot.com/2008/11/flashplayer10.html.
3. И ещё одна хитромудрая мысль: без вникания в подробности, кроссдоменные сертификаты во флеш и в ява 6 - это "две больших разницы"...

bolk (bolknote.ru)
15 ноября 2009, 20:52, ответ предназначен olo-olo-lo (olo-olo-lo.ya.ru):

Пункт 2 меня сильно беспокоит. Если allowNetworking="none" и allowScriptAccess="never" разве не защищают от атак полностью (при условии, что нет каких-то ошибок в самом flash-плеере)?

Если не защищают, то какую атаку можно осуществить в этом случае? (Java меня слабо беспокоит, у меня есть доступ к очень хорошему санитайзеру, но Flash пользователи должны использовать).

olo-olo-lo (olo-olo-lo.ya.ru)
15 ноября 2009, 22:01, ответ предназначен bolk (bolknote.ru):

Эти два атрибута полностью защищают, если мы имеем в виду размещение чужого ролика на своем сайте (т.е. там, где мы сами можем формировать теги object и embed).

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

Для исключения и этой угрозы нужен (а) контроль контента или разделение доменов (и все такое, о чем ты написал с самого начала), (б) в корне нашего сайта должен быть расположен сертификат c нужными нам настройками в тегах в site-control и allow-access-from.

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

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

bolk (bolknote.ru)
15 ноября 2009, 22:08, ответ предназначен olo-olo-lo (olo-olo-lo.ya.ru):

Ага, твой текст полностью подтверждает мои догадки :)

Про санитайзер я говорил в контексте проектов внутри «Яндекса», на моём сайте все эти атаки невозможны, если не подобрать пароля (а у меня есть всякие защиты, вроде обнаружения перебора, когда на любой пароль сайт будет говорить, что он не верный и пустит только с того IP, с которого был заход на определённый и известный только мне URL).

bolk (bolknote.ru)
15 ноября 2009, 22:08, ответ предназначен olo-olo-lo (olo-olo-lo.ya.ru):

У меня просто пользователи файлы не заливают и сами HTML не формируют.

olo-olo-lo (olo-olo-lo.ya.ru)
15 ноября 2009, 22:16, ответ предназначен bolk (bolknote.ru):

Ну, конечно... а Я и не заметил :)

bolk (bolknote.ru)
15 ноября 2009, 22:56, ответ предназначен olo-olo-lo (olo-olo-lo.ya.ru):

Ты, типа, таинственно намекаешь на какую-то дыру в моём сайте? :) Очень и очень маловероятно :)

Ваше имя или адрес блога (можно OpenID):

Текст вашего комментария, не HTML:

Кому бы вы хотели ответить (или кликните на его аватару)