停止HTTPリソースは、フラッシュ

Question

によってアクセスすることが、私は私のHTTPサーバ上でいくつかのオーディオストリーミングのリソースを持って、私はそれを再生するためのフラッシュプレーヤーを設計しなかったのは、

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

をしましょう。

http://example.com/player.swf

そして、私はいくつかの人がその音声を再生するには、サードパーティのFlash Playerを使用していることに気づきました。

http://other.com/player.swf

彼らのプレーヤーは、それが利用可能になるまで、そのリソースを再ロードしようとします。これは私のHTTPサーバーに多くのストレスを与えます。私のサーバーをハミングするのを止めるために、私はフラッシュプレーヤーからのアクセスのみを許可したいと思っています。不思議なことに、この場合、Flash Playerはcrossdomain.xmlを最初にチェックしてから自分のオーディオリソースをロードする必要がありますが、そうではありませんでした。彼らはちょうど音をロードし、遊ぶ。 corssdomain.xmlはそこにもありません。私は1つを追加しようとすると、それはうまく動作しません

<?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> 

それでは、Flash Playerの何が問題なのですか？なぜcrossdomain.xmlをチェックせずにリソースにアクセスできるのですか？

Flash Playerでcrossdomain.xmlを確認する必要はありませんか？そうであれば、私のリソースには（他のドメインの）サードパーティのプレーヤーがアクセスするのを止める方法はありますか？

ありがとうございました。

Answer 1

Soundからのリクエストは、クロスドメインポリシーを効果的に無視します。これは古くからの生きているバグですが、Adobeは何年も前に修正していませんでした。この "機能"は、サーバーにデータを送信する必要があるだけのときに使用されることがよくありますが、応答は期待できません。つまり、プレーヤーは、ポリシーファイルを提供しないサーバーからの応答を取得できないようにしますが、とにかく要求を送信します。

ddos​​攻撃から自分自身を守ろうとしている場合、これはまったく別の問題です。攻撃者はこのような攻撃を開始するためにFlash Player以外のものを使用する可能性が非常に高いでしょう。 Flash PlayerのネットワーキングAPIは、この種のアクティビティにはいくらか欠けている/制限しています...

ファイルを処理するための認証が必要な場合、おそらくHTML/Cookieベースのソリューションは理想的ではない/常にうまくいかない場合があります。正当なセッション/クッキー？ 2つのコンポーネントの暗号化（たとえばRSA）を使用して、鍵ペアを生成することができます。一方は認可されたユーザー用、もう1つはサーバー用です。ユーザーのキーにデータの要求と資格情報が提供されることを要求します。ユーザーがサービスに登録されていない場合、キーのサーバーの部分と組み合わされたキーのユーザーの部分は、ユーザーの資格情報（またはキーを使用して暗号化したデータ）を生成しません。要求者などをブロックするのはあなた次第です。この方法は、しっかりした、熟知していないハッカーのバイパスのようなアプローチです。ハッカーが許可されていない場合、今世紀にはデータを取得しません:)

認証を必要としない場合は、依然として脆弱ではありますが、さらに難しくなります）。

あまりにも多くのリクエストが問題であることに気がつきました。それでは、なぜ、あなたが本当のデータを手に入れることができないことがわかっているのであれば、テラバイトの大きなファイル1つを提供するのはなぜですか？ :)あるいは、ジャスティン・ビーバーのレコード/彼らの音楽的な味にマッチしそうなものは何でも送ってください。 :)

Answer 2

本当にこれを修正したいのであれば、私はあなたのリソースの周りにいくつかの本当の保護を置くことを調査するでしょう。 I.E.、http://example.com:7000/foo.mp3に直接アクセスできないようにしてください。あなたはhttp://example.com:7000/foo.mp3?key=1234として要求される必要があるようにワンタイムキーのようなものを強制するサーバーの後ろに置くことができます。1234はcryptographically secureランダムキーです。 フラッシュアプ​​リケーションをロードするWebサーバーは、このキーを生成し、変数としてFlashアプリケーションに渡し、メディアコンテンツ（同じサーバー）を提供しているサーバーでこのキーを認証します。特に、リソースサーバーとHTMLサーバーが同じ場合は、HTTPクッキーで簡単に実行できます。

これで、誰かがあなたのHTMLを読み込んで認証されたキーを取得することが妨げられることはありません。ただし、HTML内にキーを正しく埋め込むと、少なくとも重要な抑止力になります。 （このHTMLページの認証と承認が必要な場合は、すべてをカバーする必要があります）

crossdomain.xmlまたは他の同様のアプローチを使用すると、サーバーの代わりにクライアントのセキュリティをリソースのセキュリティに置くことになりますこれは決して良い考えではありません。