Пишу, по большей части, про историю, свою жизнь и немного про программирование.

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-ролики с другого домена и не допускать того, чтобы критичные данные и ролики были доступны с одного домена.

12 комментариев
olo-olo-lo (olo-olo-lo.ya.ru) 2009

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

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

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

Евгений Степанищев (bolknote.ru) 2009

Комментарий для olo-olo-lo.ya.ru:

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

Евгений Степанищев (bolknote.ru) 2009

Комментарий для olo-olo-lo.ya.ru:

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

olo-olo-lo (olo-olo-lo.ya.ru) 2009

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

Евгений Степанищев (bolknote.ru) 2009

Комментарий для olo-olo-lo.ya.ru:

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

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

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

Комментарий для olo-olo-lo.ya.ru:

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

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

olo-olo-lo (olo-olo-lo.ya.ru) 2009

Комментарий для Евгения Степанищева:

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

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

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

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

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

Евгений Степанищев (bolknote.ru) 2009

Комментарий для olo-olo-lo.ya.ru:

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

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

Евгений Степанищев (bolknote.ru) 2009

Комментарий для olo-olo-lo.ya.ru:

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

olo-olo-lo (olo-olo-lo.ya.ru) 2009

Комментарий для Евгения Степанищева:

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

Евгений Степанищев (bolknote.ru) 2009

Комментарий для olo-olo-lo.ya.ru:

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