Loader vs FP security. Мат в два хода.
Сделать хотел утюг, -
Слон получился вдруг
Из популярной песенки.
Немного соглашения о терминах.
Host application - загрузчик, недоступен для модифицирования.
Loadee - загружаемое приложение, которое полностью контролируется разработчиком, т.е. нами.
Весь представленный ниже код находится в loadee.
Пусть вас не смущает желтоватое название статьи - описанный ниже прием решается ровно в два хода.
Предыстория.
Данный результат был получен как побочный в экспериментах по загрузке в домен, содержащий необходимые классы.
Суть задачи сводилась к обеспечению типизацией и compile time проверок по классам, входящих в состав API, предоставляемым host application.
Для этого была сделана полная параллельная структура классов, идентичная структуре классов host application, но не содержащая реализации. Предполагалось, что в случае загрузки в ApplicationDomain, содержащий такие же классы, вновь загруженные классы будут игнорироваться. Собственно, в справке по ActionScript так и написано.
Итак,
мы выяснили, что экземпляры класса Loader возможно использовать для повторной загрузки swf-файлов.
Давайте рассмотрим пример, когда загрузчик (host application), расположенный в домене example.com загружает ваше приложение из домена mydomain.com. При этом перед разработчиками загрузчика стояли следующие цели:
а) предоставить доступ к DOM из host application;
б) ограничить доступ к DOM из loadee набором функций API через вызов методов host application;
в) запрет прямого доступа к DOM из loadee.
Так иногда предоставляется доступ к RESTful JavaScript API.
Для этого праметр allowScriptAccess оставляют дефолтным или устанавливают явно в значение "sameDomain".
После загрузки loadee располагается в SecurityDomain mydomain.com. И любые попытки получить из него доступ к example.com пресекаются политиками безопасности FP.
Проверим
trace(new LocalConnection().domain); // mydomain.com ExternalInterface.call(null)// SecurityError
Свойство parent у загруженного loadee ссылается на экземпляр класса Loader, инстанцированного от класса, принадлежащего домену example.com. Нам лишь необходимо попросить его повторно загрузить наше приложение, но уже в его SecurityDomain. Как ни странно, но такая конструкция срабатывает.
var loader:Loader = super.parent as Loader; if (loader) { var request: URLRequest = new URLRequest(super.loaderInfo.url); var context:LoaderContext = new LoaderContext(true, null, SecurityDomain.currentDomain); loader.load(request, context); }
Проверим. Пусть Document class загрузчика называется Main.
trace(new LocalConnection().domain); // example.com trace( getDefinitionByName("Main") ); // [class Main]
Да что ж такое!
А давайте загрузим loadee в ApplicationDomain, в котором находится Main.
var context:LoaderContext = new LoaderContext(true, super.stage.loaderInfo.applicationDomain, SecurityDomain.currentDomain); loader.load(request, context);// SecurityError
Пробуем загрузиться в дочерний домен по отношению к ApplicationDomain, в котором находится Main.
var context:LoaderContext = new LoaderContext(true, new ApplicationDomain(super.stage.loaderInfo.applicationDomain), SecurityDomain.currentDomain); loader.load(request, context);
Пробуем
И тут все тихо. Ну что ж, финальный аккорд!
Проверено на FP 10 и 10.1.
Вероятно, стоит заявить об уязвимости в adobe, но у меня не получается выпросить у них доступ в jira.
UPD 05 апреля 2011. А дырочку нашу прикрыли.
Всего комментариев 13
Комментарии
24.06.2010 14:11 | |
Хаха, супер)
Мне только непонятно, как ты это всё находишь. У меня методом тыка не получилось бы |
24.06.2010 14:27 | |
Psycho Tiger, обычно люди приходят к этому при помощи логики
|
25.06.2010 01:50 | |
Очень хитрая резьба!
|
25.06.2010 03:36 | |
>> Вероятно, стоит заявить об уязвимости в adobe, но у меня не получается выпросить у них доступ в jira.
Мы этим пользуемся. Может не нужно? |
25.06.2010 03:52 | |
а просто loadBytes сделать низя? там SecurityDomain указывать не надо =) да и запроса лишнего не будет.
|
25.06.2010 10:47 | |
Просто loadBytes у меня не получилось. А запроса к серверу и так не будет. Я уже обсуждал с тобой проявления механизма кеширования FP.
|
25.06.2010 10:59 | |
f[ да. жаль что loadBytes не прокатил.и кстати почему? чего он говорит?
|
25.06.2010 13:16 | |
Для context в loadBytes нельзя указывать SecurityDomain.
|
25.06.2010 13:22 | |
dimarik, спасибо кэп =) а зачем? ты хелп читал?
|
25.06.2010 14:36 | |
http://help.adobe.com/ru_RU/AS3LCR/F...oadBytes%28%29
Цитата:
Если параметр context не задан или ссылается на несуществующий объект, содержимое загружается в текущий домен защиты – процесс, обозначенный как «загрузка-импорт» в документации о безопасности проигрывателя Flash Player. В частности, если загружаемый SWF-файл установил отношения доверия с удаленным SWF-файлом, встроив удаленный SWF-файл в свой код, то загружаемый SWF-файл может импортировать удаленный файл непосредственно в собственный домен защиты.
|
02.04.2011 01:17 | |
спаасибаа
|
Последние записи от dimarik
- Memory allocation на Vector.<IInterface> (07.05.2015)
- [Starling] Тормози меня плавно! (28.10.2014)
- [Starling идиотизмы] Об интерактивных событиях (02.10.2014)
- О типах исключений. (23.04.2014)
- Немного о Vector и ByteArray (28.03.2014)