Форум Flasher.ru
Ближайшие курсы в Школе RealTime
Список интенсивных курсов: [см.]  
  
Специальные предложения: [см.]  
  
 
Блоги Правила Справка Пользователи Календарь Поиск рулит! Сообщения за день Все разделы прочитаны
 

Вернуться   Форум Flasher.ru > Блоги > dimarik

Оценить эту запись

Loader vs FP security. Мат в два хода.

Запись от dimarik размещена 24.06.2010 в 12:38
Обновил(-а) dimarik 05.04.2011 в 23:35

Сделать хотел утюг, -
Слон получился вдруг


Из популярной песенки.

Немного соглашения о терминах.

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.

Проверим
Код AS3:
trace(new LocalConnection().domain); // mydomain.com
ExternalInterface.call(null)// SecurityError
Это было ожидаемо. Наша задача загрузить loadee в тот же SecurityDomain, где расположено host application.

Свойство parent у загруженного loadee ссылается на экземпляр класса Loader, инстанцированного от класса, принадлежащего домену example.com. Нам лишь необходимо попросить его повторно загрузить наше приложение, но уже в его SecurityDomain. Как ни странно, но такая конструкция срабатывает.

Код AS3:
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);
}
Готово. Теперь мы имеем доступ к классам из домена example.com

Проверим. Пусть Document class загрузчика называется Main.

Код AS3:
trace(new LocalConnection().domain); // example.com
trace( getDefinitionByName("Main") ); // [class Main]
Попробуем еще разок
Код AS3:
ExternalInterface.call(null)// SecurityError
Да что ж такое!

А давайте загрузим loadee в ApplicationDomain, в котором находится Main.

Код AS3:
var context:LoaderContext = new LoaderContext(true, super.stage.loaderInfo.applicationDomain, SecurityDomain.currentDomain);
loader.load(request, context);// SecurityError
Странная ошибка, ведь мы уже находимся в "правильном" SecurityDomain.

Пробуем загрузиться в дочерний домен по отношению к ApplicationDomain, в котором находится Main.

Код AS3:
var context:LoaderContext = new LoaderContext(true, new ApplicationDomain(super.stage.loaderInfo.applicationDomain), SecurityDomain.currentDomain);
loader.load(request, context);
Ошибок не возникает.

Пробуем
Код AS3:
ExternalInterface.call(null);
И тут все тихо. Ну что ж, финальный аккорд!
Код AS3:
ExternalInterface.call("alert('Here we are!')");
Проверено на FP 10 и 10.1.

Вероятно, стоит заявить об уязвимости в adobe, но у меня не получается выпросить у них доступ в jira.

UPD 05 апреля 2011. А дырочку нашу прикрыли.
Всего комментариев 13

Комментарии

Старый 24.06.2010 14:11 Psycho Tiger вне форума
Psycho Tiger
 
Аватар для Psycho Tiger
Хаха, супер)
Мне только непонятно, как ты это всё находишь. У меня методом тыка не получилось бы
Старый 24.06.2010 14:27 BlooDHounD вне форума
BlooDHounD
 
Аватар для BlooDHounD
Psycho Tiger, обычно люди приходят к этому при помощи логики
Старый 25.06.2010 01:50 Котяра вне форума
Котяра
 
Аватар для Котяра
Очень хитрая резьба!
Старый 25.06.2010 03:36 Mur4ik вне форума
Mur4ik
>> Вероятно, стоит заявить об уязвимости в adobe, но у меня не получается выпросить у них доступ в jira.

Мы этим пользуемся. Может не нужно?
Старый 25.06.2010 03:52 BlooDHounD вне форума
BlooDHounD
 
Аватар для BlooDHounD
а просто loadBytes сделать низя? там SecurityDomain указывать не надо =) да и запроса лишнего не будет.
Старый 25.06.2010 10:47 dimarik вне форума
dimarik
 
Аватар для dimarik
Просто loadBytes у меня не получилось. А запроса к серверу и так не будет. Я уже обсуждал с тобой проявления механизма кеширования FP.
Старый 25.06.2010 10:59 BlooDHounD вне форума
BlooDHounD
 
Аватар для BlooDHounD
f[ да. жаль что loadBytes не прокатил.и кстати почему? чего он говорит?
Старый 25.06.2010 13:16 dimarik вне форума
dimarik
 
Аватар для dimarik
Для context в loadBytes нельзя указывать SecurityDomain.
Старый 25.06.2010 13:22 BlooDHounD вне форума
BlooDHounD
 
Аватар для BlooDHounD
dimarik, спасибо кэп =) а зачем? ты хелп читал?
Старый 25.06.2010 14:23 dimarik вне форума
dimarik
 
Аватар для dimarik
Да, прочитал. Там указано, что LoaderContext#checkPolicyFile и LoaderContext#securityDomain для loadBytes "do not apply". При тестировании дает одну из ошибок.

- Если установлен checkPolicyFile: Error: Error #2115: Параметр LoaderContext.checkPolicyFile должен иметь значение "false".
- Если задан securityDomain: Error: Error #2114: Параметр LoaderContext.securityDomain должен иметь значение "null".

Загрузить с помощью loadBytes удалось. Видимо, указывал неподходящий application domain.
Старый 25.06.2010 14:36 BlooDHounD вне форума
BlooDHounD
 
Аватар для BlooDHounD
http://help.adobe.com/ru_RU/AS3LCR/F...oadBytes%28%29
Цитата:
Если параметр context не задан или ссылается на несуществующий объект, содержимое загружается в текущий домен защиты – процесс, обозначенный как «загрузка-импорт» в документации о безопасности проигрывателя Flash Player. В частности, если загружаемый SWF-файл установил отношения доверия с удаленным SWF-файлом, встроив удаленный SWF-файл в свой код, то загружаемый SWF-файл может импортировать удаленный файл непосредственно в собственный домен защиты.
Старый 25.06.2010 15:14 dimarik вне форума
dimarik
 
Аватар для dimarik
Это укладывается в мое понимание. Если Loader из security domain example.com будет загружать swf посредством loadBytes, то в его внутренностях произойдет вызов SecurityDomain.currentDomain.

Однако непонятно почему вызов SecurityDomain.currentDomain из домена mydomain.com дает объект, который указывает на security domain host application. И Loader#load позволяет загрузить "левую" флешку в свой security domain.
Старый 02.04.2011 01:17 kseniya вне форума
kseniya
 
Аватар для kseniya
спаасибаа
 

 


Часовой пояс GMT +4, время: 15:17.


Copyright © 1999-2008 Flasher.ru. All rights reserved.
Работает на vBulletin®. Copyright ©2000 - 2024, Jelsoft Enterprises Ltd. Перевод: zCarot
Администрация сайта не несёт ответственности за любую предоставленную посетителями информацию. Подробнее см. Правила.