Коллизия с обновлением политики безопасности FlashPlayer10 принимает новый оборот: "Mail.ru просит откатиться на 9-й flash-плеер". Мало того, что нововведения сделанные Adobe сломали работу такого распространенного инструмента как SWF Upload, переход на "десятку" большого количества пользователей сулит серьезные проблеммы ресурсам, использующим взаимодействие нескольких флэш-элементов или флэш клиент - сервер. Существует огромное количество готовых, давно и уверенно работающих проектов, написанных на AS1-2, где используются модули(здесь не всмысле Flex), созданные давно и разными разработчиками, исходники которых утеряны. Работают игры, да и работают, пока гром не грянет. И вот он грянул.
Ужесточение политики безопасности Flash Player было вызвано повсеместными воплями юзеров и разработчиков о тотальной уязвимости плеера. Два примера:
1 . Предположим вы администратор флэш-сайта. Возможно вы разрешаете пользователям загрузку файлов на сервер средствами Flash Player, но не хотите, чтобы пользователи Вашего сайта имели возможность использовать ресурсы сайта. В этом случае отсутствие разрешения в файле кроссдоменной политики вашего сайта не может быть припятствием для злоумышленника. Он может такой файл закачать к вам на сайт сам используя ваш-же интерфейс. При этом совершенно не важно как этот файл будет называться и какое расширение иметь. Зловредная флэшка хакера воспримит его как файл политики.
2. Предположим злой хаккер является администратором собственного DNS-сервера. В файле кросс-доменной политики, на своем серваке он, подлый, может (мог) прописать разрешение доступа к ресурсам стороннего сервера, и все бы работало.
Что придумали в Adobe:
1. Теперь для организации сокетного соединения всегда требуется разрешение от файла политики, даже если флэшка и серверный сценарий находятся в области одного домена.
2. Опять же в теме сокетных соединений, теперь разрешение файла политики базируется на IP-адресе, а не только на имени домена.
3. Для сокетных соединений применяется фиксированый адрес мастер-файла политики порт 843 пример файла политики:
<cross-domain-policy>
<site-control permitted-cross-domain-policies="master-only"/>
<allow-access-from domain="mysite.com" to-ports="999,8080-8082"/>
</cross-domain-policy> 4. Программы, использующие сокетные соединения с localhost, должны получать разрешение от файла политики, аналогичное разрешению на взаимодействие по протоколу HTTPS т.е. использовать атрибут secure="true";
5. Введено понятие мета-политики. теперь администратор сервера может разрешить доступ к ресурсам где-либо, неразрешить нигде или разрешить везде...
Мета-политика может быть разной в отношении следующих взаимодействий :
- HTTP и HTTPS сервером. Каждый сервер делает свои собственные мета-политические декларации, которая не влияет на другие серверы. Например, мета-политики HTTP-сервер на 80 порту влияет только на этом сервере, а не HTTP-сервер на порту 8080 на том же хосте. Кроме того, мета-политики HTTP-сервера не влияет на HTTPS-сервер на одном хосте, или наоборот.
- FTP-серверы. Опять же, каждый сервер делает свои собственные мета-политические декларации.
- Любой из хостов может объявить метаполитику сокетного соединения низкого уровня, с использованием ActionScript
Socket и XMLSocket классов, высшего уровня подключения к HTTP и FTP серверам, используя любые ActionScript API, помимоSocket и XMLSocket, при этом взаимодействия с объектами этих типов будут требовать разных мета-политик(тут возможно я чего-то недопонял,если надо - кто может поправьте). Для получения дополнительной информации см. раздел, посвященный политике сокетных соединений.
Мета-политические заявления могут содержать следующие значения:- all - разрешено взаимодействие с любыми файлами политики расположенными где угодно;
- by-content-type- разрешено взаимодействие с ресурсами, которые в HTTP заголовке возвращают Content-Type t
ext/x-cross-domain-policy . Это значение мета-политики доступно только для HTTP и HTTPS серверов. Большинство HTTP-серверов предусматривают гибкие способы решить, каким образом присвоить Content-Type так что это самый полезный вариант, когда это желательно, чтобы некоторые файлы были доступны, а другие нет. Общие стратегии для присвоения text/x-cross-domain-policy типа указать его для отдельных мест, что требует одобрения администратором для каждого файла политики, или выделить text/x-cross-domain-policy в какой-то файл, имя которого crossdomain.xml, тем самым позволяя файлу политики существовать в любом месте.
- by-ftp-filename - используется только для FTP - серверов. Смысл заключается в том, что можно получить только файл crossdomain.xml(что-угодно/crossdomain.xml).И в дальнейшем применять политику определенную этим файлом (типа Security.loadPolicyFile(что-угодно/crossdomain.xml))
- master-only - в качестве файла политики воспринимается только файл / crossdomain.xml (расположенный в корневой директории). И только...
- none - никакое взаимодействие с ресурсами сервера не допускается.
- none-this-response -специальный вид мета-политики, который может быть указан только в заголовке HTTP- ответа сервера. Означает, что именно по этому запросу никакого взаимодействия у вас не получится, при этом, в отличие от других мета-политик, эта может сосуществовать с метаполитиками, объявленными др. способом.
При наличие нескольких объявлений политики, в отношении одной и той же сущности приоритет имеет та, что передается в заголовке.
Для сокетных соединений применимы только 3 вида мета-политики(all,master-only,none), причем в случае с master-only это только port:843.
Засада в том, что до FlashPlayer10.0, по у молчанию, мета-политика воспринималась как all(если иного не прописано в crosdomain.xml), теперь же начиная с FlashPlayer10.0 это значение трактуется как master-only(!).
Пример объявления мета-политики:
<cross-domain-policy>
<site-control permitted-cross-domain-policies="by-content-type"/>
</cross-domain-policy>
6. В отношении взаимодействий с использованием безопасных соединений применяется атрибут secure Пример файла политики в отношении HTTPS:
<cross-domain-policy>
<allow-access-from domain="my.com" secure="true" to-ports="3050"/>
</cross-domain-policy>7. Теперь плеер отвергает файлы кроссдоменной политики неверно отформатированные. Требования, по форматированию файла включают в себя следующее:
Первый и последний теги XML документа не должны содержать ничего кроме объявления (допускаются XML комментарии), при этом Adobe признает и обращает наше внимание,на то что это делает XML документ не вполне валидным.
8. Чтоб мы несильно ругались, в дебаг-версии плеера, ведется подробное логирование операций, связанных с политикой безопасности (как использовать лог можно прочитать здесь )
Понимая, какое количество интернет ресурсов создано на базе технологии Flash с использованием кроссдоменного взаимодействия, компания Adobe проводила ужесточение политики безопасности в 3 этапа (а мы и не туда, работает, да и работает прим.автора):
1. Начиная с версии Flash Player 9,0115 несоблюдение "строгих правил" приводило лишь к предупреждениям, видимым счастливым обладателям дебаг-версии плеера, при этом взаимодействие программы со сторонними ресурсами исполнялось в полной мере.
2. Начиная с версии Flash Player 9,0124,0 несоблюдение "строгих правил" приводило к ошибкам лишь при использовании сокетных соединений.
3. И наконец, начиная с версии Flash Player 10,0, грянул гром и несоблюдение "строгих правил" вывело из строя некоторое количество "беспечных". Теперь это ошибка времени исполнения.
P.S. Это не подробный перевод адоббиного дока, а мое личное понимание вопроса, возможно где-то я заблуждаюсь, возможно где-то допущены ошибки в восприятии аглицкого текста, вобщем буду рад Вашим комментариям. Для получения более точной информации обращайтесь http://www.adobe.com/devnet/flashplayer/articles/fplayer9_security.html
