Stop HTTP ресурс доступен вспышкой

Question

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

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

Я сделал дизайн флэш-плеер для воспроизведения его.

http://example.com/player.swf

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

http://other.com/player.swf

Их игрок попытается перезагрузить этот ресурс, пока он не доступен. Это вызывает большой стресс для моего HTTP-сервера. Чтобы остановить их от помех на моем сервере, я хочу разрешить доступ только с моего флеш-плеера. Как ни странно, я думаю, что в этом случае флеш-плеер должен сначала проверить 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

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

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

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

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

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

Answer 2

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

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

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