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-ролики с другого домена и не допускать того, чтобы критичные данные и ролики были доступны с одного домена.
И не забудем про кроссдоменные сертификаты... Так что правил три, как минимум.
Задолго до «Хабра» ( http://habrahabr.ru/blogs/infosecurity/75145/ ) и тех горе-специалистов по безопасности эта возможность была описана здесь: http://www.securitylab.ru/contest/300506.php. В последствии от многих проектов последовала даже реакция. А в англоязычном интернете идея появлялась еще раньше.
Кстати, с помощью java-апплетов можно сделать то же и намного больше: http://forum.antichat.ru/showthread.php?p=1387662 . Учитывая изложенное, гениальных тем про фундаментальные баги в java осталось ждать недолго — всего года два.
Комментарий для olo-olo-lo.ya.ru:
Гм, а я-то думал, что чтобы получить доступ к cookie из Java-апплета потребуется либо сертификат, либо запрос полномочий у пользователя.
Комментарий для olo-olo-lo.ya.ru:
Прочитал про апплет и не понял что это. Это для случая, когда можно внедрить фильтруемый HTML, в котором разрешено использование APPLET?
Это для всех случаев. В том числе для тех, когда можно загрузить апплет на целевой (читай «уязвимый») сайт. В последнем случае, ты получаешь cookie от базы кода и здесь-то проявляются преимущества ява перед флэш. В статье ВСЕ написано.
Комментарий для olo-olo-lo.ya.ru:
В общем, должно совпасть несколько условий для внедрения и метод имеет смысл когда используются httpOnly cookie, если нет, то можно использовать сотни более простых способов.
Но исследование более чем любопытное. Я, кстати, никогда не исследовал «сертификаты» Flash. Правильно ли я понимаю, что ролик сам задаёт URL (прямо из своего AS-кода) из которого он этот сертификат хочет получить?
Комментарий для olo-olo-lo.ya.ru:
Пункт 2 меня сильно беспокоит. Если allowNetworking=«none» и allowScriptAccess=«never» разве не защищают от атак полностью (при условии, что нет каких-то ошибок в самом flash-плеере)?
Если не защищают, то какую атаку можно осуществить в этом случае? (Java меня слабо беспокоит, у меня есть доступ к очень хорошему санитайзеру, но Flash пользователи должны использовать).
Комментарий для Евгения Степанищева:
Эти два атрибута полностью защищают, если мы имеем в виду размещение чужого ролика на своем сайте (т. е. там, где мы сами можем формировать теги object и embed).
Угроза безопасности наших данных в таком случае возникает только в том случае, если браузер, находясь на чужом сайте, где мы не имеем возможности определять атрибуты названных тегов, подрубает сам ролик или сертификат с нашего сайта, куда нам его предварительно подгрузили. Это очевидно.
Для исключения и этой угрозы нужен (а) контроль контента или разделение доменов (и все такое, о чем ты написал с самого начала), (б) в корне нашего сайта должен быть расположен сертификат c нужными нам настройками в тегах в site-control и allow-access-from.
Естественно, последнее относится только к тем сайтам, которые разрешают пользователю что-то на них грузить.
Санитайзер — вещь, конечно, хорошая, но Я могу тебе, например, сказать, что на твоем сайте этот вид атак возможен, поскольку во всем, что написано выше и традиционно говорится, когда обсуждается эта тема, есть одно «НО», которое знаю только Я, поэтому особо беспокоиться не стоит.
Комментарий для olo-olo-lo.ya.ru:
Ага, твой текст полностью подтверждает мои догадки :)
Про санитайзер я говорил в контексте проектов внутри «Яндекса», на моём сайте все эти атаки невозможны, если не подобрать пароля (а у меня есть всякие защиты, вроде обнаружения перебора, когда на любой пароль сайт будет говорить, что он не верный и пустит только с того IP, с которого был заход на определённый и известный только мне URL).
Комментарий для olo-olo-lo.ya.ru:
У меня просто пользователи файлы не заливают и сами HTML не формируют.
Комментарий для Евгения Степанищева:
Ну, конечно... а Я и не заметил :)
Комментарий для olo-olo-lo.ya.ru:
Ты, типа, таинственно намекаешь на какую-то дыру в моём сайте? :) Очень и очень маловероятно :)