Хорошая тема. Как раз недавно один дотнетчег спросил меня, как во флэше насчет безопасности. Если перед вами тоже возникают такие задачи, и вы программируете на Action Script под версию Flash Player выше 9,0,155 (как и должны делать все правильные ребята) — то это Та Самая Статья.
Кстати, размещена статья в диковинном месте под названием "No Title Flash..."; хостинг, как водится, бесплатный. А ресурс достойный, смотрите: Карты искажений для displacementMapFilter (полусфера из квадрата), Построение стереограммы (open source) — наш брат из Беларуси рулит.
О новом Flash Player 9.0.124 мы уже писали: он поддерживает новую политику безопасности. А что за политика? Большая политика. Речь идет о глобальной AS-уязвимости Flash Player всех версий, кроме самой последней — 9.0.124. И похоже, что флэш-декомпиляторам может прийти крышка от старых добрых манипуляций с байткодом.
Подробно на все вопросы отвечает статья от Nox Noctis: Тотальная уязвимость Flash Player.
Вы не смотрите, что я пишу в шутливом тоне. Это я от волнения. Дело на самом серьезное, читать и понимать статью — срочно.
Хотите получать из своего RIA-приложения доступ к различным сервисам и API от Google? Голосуйте за этот запрос: Add crossdomain.xml for Google Accounts.
Чтобы проголосовать, нужно кликнуть звездочку справа от надписи "Issue 406:". Можно также написать свой комментарий — но это необязательное требование.
Евгений Рыбаков напомнил мне, что Adobe уже полных ходом реализует управление цифровыми правами (DRM, Digital Rights Management, УЦП) во Flash Player и Flash Media Server 3. Не стану перепечатывать оригинальную статью с securitylab.ru (там комменты жгут :)
Ключевой момент: зашифрованный канал обмена данными между Flash Player и FMS для распределения лицензированных (имеющих цифровую подпись) медиа-потоков (видео).
Александр Комлев выложил в своем блоге презентацию о безопасности флэш-приложений от Stefano di Paola. 36 слайдов посвящены поиску уязвимостей в коде и встроенных флэш-объектах, во взаимодействии Flash и JavaScript и т.п. Упоминается также инструмент для анализа флэш-уязвимостей — фреймворк SWFRTAnalyzer (SWF Runtime Analyser), бесплатная версия которого будет выпущена компанией Minded Security. Существует сайт flashsec.org, разрабочиком которого является автор презентации. На flashsec.org можно узнать, что к выпуску готовится продукт JAMFProxy, название которого тоже говорит само за себя. Побродив по разделу Software ни один флэш-хакер не останется равнодушным :)
Вы ходите по десяткам сайтов в день? Скачиваете файлы? Регистрируетесь? Постоянно вводите одни и те же данные? Что, правда? Даже не верится! А если все так и есть, то эта новость для вас и ваших сайтов.
Как подключить свой сайт к системе описано в кратком руководстве для разработчика. Вебмастеру нужно только встроить в страницу JavaScript-код (на пару строк всего) и микро-Flash-приложение, работающее с формами и параметрами запросов. В руководстве это описано подробно, перечислены поддерживаемые поля форм и параметры.
Потестируем?
Интересный вклад в проблему флэш-безопасности: статья о том, как зашить crossdomain.xml в GIF-файл и как добиваться вредных эффектов с помощью дыр в политике безопасности Adobe Flash Player, таких, как альтернативные файлы безопасности.
А мы еще жаловались, что политики безопасности эти больно строгие ;-)
// via Reijii
Нужно передать на сервер / в платежную сиcтему GET-запросом данные так, чтобы они не читались совсем уж открыто в адресной строке (и при этом не в силах ждать, когда AS3 (где это есть по умолчанию) заполонит пользовательские компьютеры)?
Пользуйтесь Actionscript 2.0: Base64 Encoder'ом от Jason Nussbaum.
Добавлено: внимание, Base64 -- это метод кодирования, но не шифрования данных (именно к шифрованию и следует прибегнуть, если вы хотите надежно защитить свои данные)! Это -- средство самой-самой базовой защиты -- или, скорее, простой обфускации. Также алгоритм Base64 можно использовать для передачи бинарных данных в текстовом виде. Именно таково и было изначальное назначение этого алгоритма -- он используется для пересылки аттачментов в email-сообщениях.
Это как раз то, о чем мы мечтали: защитить свой ActionScript, не становясь хакером. Илья Шляховой и Иван Дембицкий дарят нам этот подарок. Любой желающий может теперь воспользоваться бесплатным онлайн-сервисом для защиты ActionScript-кода.
Пришла пора сходить по счастливой ссылке: ActionScript protection online service.
Это работает! Уже при открытии файла, содержащего защищенный код, декомпилятор выдает ошибки. И продолжает их выдавать. Защищенный код мне увидеть пока не удалось.
Для тех, кто сходил по ссылке:
Если я правильно понял -- чтобы защитить весь AS-код приложения, нужно делать это индивидуально с каждым куском кода (например, если части кода разбросаны по разным мувиклипам/кадрам)? Если так, то преимущества однокадровых скриптов становятся еще значительнее.
У меня просто нет больше слов..
Если ваше приложение делает что-либо из нижеперечисленного, то вашему сайту срочно нужен файл с описанием междоменной политики безопасности:
("Абсолютный URL" — это что-то вроде 'http://www.deneg.net' или 'http://nichego.net');
Если ваш сайт использует что-либо и названного и на нем не выложен файл с описанием междоменной политики безопасности (cross-domain policy), пользователи Flash Player 7 увидят гадкое окно с предупреждением о нарушении безопасности — оно появится при просмотре вашего клипа, созданного под формат Flash Player 6.
Можете почитать статью от того, кто это натворил: Security Changes in Macromedia Flash Player 7 (Deneb Meketa — вот этот изобретатель).
Во Flash Player 6 все это начиналось с того, что придумали политику безопасности:
Во Flash Player 7 все стало еще хуже. Во Flash Player 6 приложения с поддоменов имели право обращаться к данным или клипам с родительского домена (и друг к другу). В Flash Player 7 доступ друг к другу/данным могут получить только приложения с точно одного и того же домена. Например, Flash Player 6 позволял клипу, хранящемуся на eshche.deneg.net загрузить XML с uzhe.deneg.net. А Flash Player 7 не позволит.
Вот еще один, более жестокий пример: во Flash Player 7, если вы обращаетесь к сайту по сокращенному URL типа "http://vodki.net" (без "www"), клипы с этого сайта не смогут загрузить данные с его полного URL, "www.vodki.net". Это ограничение касается файлов формата Flash Player 6 и Flash Player 7. Если .swf-файл опубликован под Flash Player 6 (или более ранний), то Flash Player 7 выдаст предупреждение, спрашивая посетителя, можно ли клипу получить доступ к данным с другого домена.
Файл с описанием междоменной политики безопасности поможет решить эти проблемы и автоматизировать доступ к данным на www.yoursite.com из клипа с yoursite.com.
<?xml version="1.0"?> <!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd"> <cross-domain-policy> <allow-access-from domain="www.yoursite.com" /> <allow-access-from domain="yoursite.com" /> </cross-domain-policy>
Описанная техника используется также для предоставления доступа к данным сайта с любого внешнего домена.
Например, чтобы дать всем клипам с moock.org доступ к yoursite.com, XML на yoursite.com должен быть таким:
<?xml version="1.0"?> <!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd"> <cross-domain-policy> <allow-access-from domain="www.yoursite.com" /> <allow-access-from domain="yoursite.com" /> <allow-access-from domain="*.moock.org" /> </cross-domain-policy>
После этого все клипы с moock.org (включая www.moock.org, games.moock.org, и т.д.) получат доступ к данным с yoursite.com. (Заметьте, в файле политики можно использовать символ "*".)
Веб-сервисы типа amazon.com или google.com могут предоставлять доступ к своим данным любому Flash-клипу, используя такие конструкции:
<?xml version="1.0"?> <!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd"> <cross-domain-policy> <allow-access-from domain="*" /> </cross-domain-policy>
Если вы держите XMLSocket-сервер типа Unity, вам также не обойтись без полицейского файла, который разрешит клипам, загруженным с www.yoursite.com или yoursite.com подключаться к серверу. Файл с политиками должен быть загружен через HTTP-протокол с домена, на котором находится ваш XMLSocket-сервер. Например, если вы запустили сокет-сервер на moock.org, то нужно запустить на moock.org веб-сервер, в руте которого и хранить файл с политиками и полицейскими:
<?xml version="1.0"?> <!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd"> <cross-domain-policy> <allow-access-from domain="www.moock.org" /> <allow-access-from domain="moock.org" /> </cross-domain-policy>
Без файла с политиками подключиться к серверу не удастся, например, сокет-сервер на moock.org не ответит клипу с www.moock.org.
System.security.allowDomain
System.security.allowInsecureDomain
Кое-что можно узнать здесь:
См. также справку к Macromedia Flash 2004: "ActionScript Reference Guide > Working with External Data > Flash Player security features > About allowing cross-domain loading".
// via Colin
Ненавижу политику.
Совсем древнее: 17-20.09.2002, 23-30.09.2002, 01-04.10.2002, 07-11.10.2002, 14-19.10.2002, 20-26.10.2002, 27.10-02.11.2002, 04-08.11.2002, 11-16.11.2002, 18-23.11.2002 25-30.11.2002, 02-07.12.2002, 09-14.12.2002 Сайт заработал 17.09.2002