Загрузка данных с внешних доменов

[okouser]

empty

[alatar]

Это не баг и никогда багом не было.

[alatar]

Буду отрицать. Для JS и Canvas также существуют подобные ограничения. Это часть политики безопасности для веба.
Отображать картинки вам никто не мешает, ограничение касается только доступа к содержимому. Для этого и существует класс Loader.

[caseyryan]

Вы же не будете отрицать, что необходимость размещения на стороннем домене специального файла только ради того, чтобы флешеры смогли воспользоваться какими-то медиа-данными, сама по себе ущербна.

Да, идея на самом деле бредовая. Лучше было бы сделать так, что если разработчик не хочет, чтобы кто-то скачивал с помощью флеш плеера его контент, то ложил бы файл политик в корень, а в случае его отсутствия скачка была бы разрешена по умолчанию. Тем более что с помощью других технологий качать можно.
Но тем не менее alatar уже сказал, что это не баг. И с этим не поспоришь. Это задумано в адоби.

на который, кстати, очень хотелось бы взглянуть

Не получится. Это встроенный класс, написанный на С++. Исходников в свободном доступе нет.

[alatar]

Не надо таких обобщений, это далеко не так.

Что далеко не так? Почитайте о same origin policy. Не Adobe это придумала, не ей и оспаривать.

[maxkar]

А PHP, ASP.NET, Ruby и т.п.?

А все это выполняется на стороне сервера, а не клиента.

Adobe достаточно правильно защищает данные. Это нужно, чтобы флешка из интернета не могла выгрузить в этот интернет файлы из корпоративной сети, например. Поэтому картинки отображать можно, а контент получать (отрисовывать и т.п.) - нельзя. Мало ли в той же графике секретная информация. Да и общий подход - запрещать по умолчанию (whitelisting) считается более безопасным, чем blacklisting.

[caseyryan]

Это нужно, чтобы флешка из интернета не могла выгрузить в этот интернет файлы из корпоративной сети

Ну, это совсем не безопасность. Кому надо и серверный скриптик для этого набросают. Не надо просто данные в корпоративных сетях в свободном доступе хранить. Что мешает флешке обратиться к этому скрипту, он выкачает все что нужно и вернет флешке уже с разрешенного домена.
Вообще, вся эта политика same origin - одна большая тупость, имхо. Кроме как бесполезными палками в колеса, ее никак и не зназовешь

[maxkar]

Но настройки тогда должны быть на стороне клиента более гибкие, так они просто отсутствуют.

Нет! Только не на стороне клиента. Вы плохо знаете обычных пользователей, которые поразрешают все, что угодно. В качестве контрмеры автоматически был бы запрет использования флеша вообще. "Разрешать по умолчанию" тоже неправильно, потому что могут быть legacy-системы, в которых данный файлик не существует. А отслеживать все, что появилось в интернете и запрещать - тоже плохо, приведет к тотальным запретам.

Ну, это совсем не безопасность. Кому надо и серверный скриптик для этого набросают. Не надо просто данные в корпоративных сетях в свободном доступе хранить

Вы неправильно понимаете сценарий. Пусть есть какая-то корпорация megacorp. У нее есть своя интрасеть megacorp.intra (доступ есть только с компьютеров корпорации). Атакующий доступа к этой сети не имеет, зато может создать сайт в интернете. Вот он может создать какой-то свой сайт hacked.com и какую-нибудбь игру, например. Через некоторое время пользователь из megacorp запустит эту игру и флешка сольет данные с megacorp.intra (потому что флешка выполняется уже внутри периметра безопасности, а пришла - извне!). А еще лучше - не игру, а баннер. Запрещать пользователям весь интернет не всегда является решением. Т.е. "скриптик" не поможет, так как работает извне периметра безопасности. А вот флешка (а также javascript и прочие радости) могут проникать через границы контекста (страницы в интернете, скрипты в email).

Вообще, вся эта политика same origin - одна большая тупость, имхо.

Зависит от сценариев работы пользователя. Если можно строго разделить "безопасный" и "небезопасный" контексты работы пользователя (физически два разных компьютера и две сети, например), тогда same origin ни на что не влияет. Если же пользователь одновременно может работать с "защищенным" и "незащищенным" контекстом (сейлзы какие-нибудь, сбор информации из интернета и т.п.) "same origin" как раз и отслеживает этот самый контекст доступа. А другие решения слишком неудобны будут.

[caseyryan]

Вы неправильно понимаете сценарий. Пусть есть какая-то корпорация megacorp. У нее есть своя интрасеть megacorp.intra (доступ есть только с компьютеров корпорации). Атакующий доступа к этой сети не имеет, зато может создать сайт в интернете. Вот он может создать какой-то свой сайт hacked.com и какую-нибудбь игру, например. Через некоторое время пользователь из megacorp запустит эту игру и флешка сольет данные с megacorp.intra (потому что флешка выполняется уже внутри периметра безопасности, а пришла - извне!). А еще лучше - не игру, а баннер. Запрещать пользователям весь интернет не всегда является решением. Т.е. "скриптик" не поможет, так как работает извне периметра безопасности. А вот флешка (а также javascript и прочие радости) могут проникать через границы контекста (страницы в интернете, скрипты в email).

Собственно, это никак не противоречит концепции блэк листа. Такие сети могли бы содержать как раз запрещающий кроссдоменник. Так как подобных сценариев развития относительно мало (если сравнивать с общим количеством ситуаций, где используется флеш плеер), то вполне можно было бы сделать именно так.

[maxkar]

Собственно, это никак не противоречит концепции блэк листа. Такие сети могли бы содержать как раз запрещающий кроссдоменник.

Повторяю. Это не приведет к появлению запрещающего кроссдоменника. Это приведет к повальному запрещению flash в корпоративной среде. Просто потому, что flash запретить проще, чем настроить безопасность для "какого-то" плагина. Я не уверен, что adobe это нужно. Да и white lists рулят, а не black list. Правильный black list обычно очень сложно делать и поддерживать.

Нужно еще учесть в среднем не слишком высокую квалификацию обслуживающего персонала. Так что кросдоменник отсутствовал бы в достаточно большом количестве организаций (где на самом деле должен бы был быть). Поэтому периодически бы поднималась шумиха в СМИ по поводу очередной успешной атаки. Возможно, и иски к самому Adobe были бы (выграли бы или нет - уже другая история).