Остановить доступ к http-ресурсу через flash

Question

У меня есть несколько потоковых аудио-ресурсов на моем HTTP-сервере, скажем,

http://example.com:7000/foo.mp3

Я разработал флеш-плеер для воспроизведения.

http://example.com/player.swf

И я заметил, что некоторые парни используют сторонний флеш-плеер для воспроизведения этого звука.

http://other.com/player.swf

Их игрок попытается перезагрузить этот ресурс, пока он не станет доступен. Это делает большой стресс для моего HTTP-сервера. Чтобы они не могли отключить мой сервер, я хочу разрешить доступ только с моего флеш-плеера. Странно, но я думаю, что в этом случае Flash Player должен сначала проверить файл crossdomain.xml, прежде чем загружать мой аудио ресурс, но они этого не сделали. Они просто загружают звук и играют. Corssdomain.xml даже не там. Я пытаюсь добавить один, он не работает так же хорошо

<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM
"http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
    <allow-access-from domain="*.example.com"/>
</cross-domain-policy>

Так что не так с флеш-плеером? Почему он может получить доступ к ресурсу без проверки crossdomain.xml?

В некоторых случаях флэш-плееру не нужно проверять crossdomain.xml? Если да, как я могу остановить доступ к моему ресурсу сторонним игрокам (из другого домена)?

Спасибо.

Answer 1

Если вы действительно хотите это исправить, я бы попробовал установить реальную защиту для ваших ресурсов. Т.е., http://example.com:7000/foo.mp3 не должно быть напрямую доступно. Вы можете поместить его позади сервера, который вызывает что-то вроде одноразовых ключей, так что его нужно будет запрашивать как http://example.com:7000/foo.mp3?key=1234, где 1234 - это криптографически безопасный случайный ключ. Ваш веб-сервер, который загружает ваше приложение флэш-памяти, сгенерирует этот ключ, передаст его как переменную в приложение флэш-памяти, а затем авторизует этот ключ на сервере, который обслуживает ваш медиа-контент (возможно, тот же сервер). Особенно, если сервер ресурсов и сервер HTML одинаковы, это также легко можно сделать с помощью файлов cookie HTTP.

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

Использование crossdomain.xml или любого другого подобного подхода позволяет обеспечить безопасность ваших ресурсов под контролем клиента, а не сервера - что никогда не является хорошей идеей.

Answer 2

Запросы, сделанные из класса Sound, эффективно игнорируют междоменные политики. Это старая живая ошибка, Adobe не исправляла целую вечность. Эта «функция» часто используется, когда вам нужно только отправить данные на сервер, но вы не ожидаете никакого ответа. То есть проигрыватель не позволит вам получить ответ от сервера, который не предоставляет файл политики, но все равно отправит запрос.

Теперь, если вы пытаетесь защитить себя от атаки ddos ​​- это совершенно другая проблема, злоумышленник, скорее всего, использует что-то другое, кроме флэш-плеера, для запуска такой атаки. API-интерфейсы для работы с Flash-проигрывателем для этого вида деятельности несколько отсутствуют / ограничены ...

Если вам требуется аутентификация для обслуживания файлов, то, вероятно, решение на основе HTML / cookie не является идеальным / не всегда будет работать, так как иногда вам может потребоваться предоставить файл без использования html / что, если хакер создает легитимный файл сеанс / cookie? Вы можете использовать двухкомпонентное шифрование (например, RSA) для генерации пар ключей: одну для авторизованного пользователя, а другую для сервера. Требовать предоставления ключа пользователя вместе с запросом данных, а также учетных данных. Если пользователь не зарегистрирован в службе, пользовательская часть ключа в сочетании с серверной частью ключа не будет генерировать учетные данные пользователя (или любые другие данные, зашифрованные с помощью ключей) - что будет сигнализировать о попытке мошенничества. Тогда вам решать заблокировать запрашивающую сторону и т. Д. Этот способ является надежным, не слишком хитрым подходом. Если хакер не авторизован, то он не получит данные в этом веке:)

Если вам не требуется аутентификация, то, вероятно, будет уместным подход на основе файлов cookie / сеансов (что означает, что доступ к данным будет по-прежнему уязвим, но к нему будет сложнее добраться).

О, я только что понял, что проблема заключается в слишком большом количестве запросов. Тогда, ну, почему бы вам не «удовлетворить» запросы, если вы уже можете узнать, что они не получат никаких реальных данных, скажем, предоставляя им файл размером в один Терабайт? :) Или, может быть, прислать им несколько записей о Джастине Бибере / что еще вряд ли соответствует их музыкальному вкусу? :)