FlashPlayer10. Политика в опасности!

Коллизия с обновлением политики безопасности FlashPlayer10 принимает новый оборот: "Mail.ru просит откатиться на 9-й flash-плеер". Мало того, что нововведения сделанные Adobe сломали работу такого распространенного инструмента как  SWF Upload, переход на "десятку" большого количества пользователей сулит серьезные проблеммы ресурсам, использующим взаимодействие нескольких флэш-элементов или флэш клиент - сервер. Существует огромное количество готовых, давно и уверенно работающих проектов, написанных на AS1-2, где используются модули(здесь не всмысле Flex), созданные давно и разными разработчиками, исходники которых утеряны. Работают игры, да и работают, пока гром не грянет. И вот он грянул. 

Попробую разобраться в нововведениях, сделанных Adobe в отношении политики безопасности FlashPlayer, используя материалы сайта Adobe.com: http://www.adobe.com/devnet/flashplayer/articles/fplayer9_security.html

Ужесточение политики безопасности 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 text/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