背景

例えば、A は Web サイトの Web マスターであるとします。 A の Web サイト の Web ページには、イメージおよびオーディオとビデオファイルへのリンクが含まれています。 各静的リソースは Alibaba Cloud OSS に保存されます。 たとえば、A は URL http://referer-test.oss-cn-hangzhou.aliyuncs.com/aliyun-logo.png を使用して OSS にイメージファイルを保存します。

OSS 外部リソースの URL について、URL に署名することなくOSS アドレスを確認するには、公開ユーザーのバケット権限が必要です。

B は別の web サイトの web マスターです。B は許可なく web サイトのイメージリソースを使用しています。あなたの web サイト内の web ページにイメージリソースを置くことにより、スペースとトラフィックを勝手に使用するためにこの方法を利用します。 この場合、サードパーティの Web サイトのユーザーは B の Web サイトを見ていますが、Web サイト上の画像のソースは明らかにはなっていません。 OSS は使用量によって課金されるため、ユーザー A には何のメリットもなく、リソース使用のコストだけが発生します。

このページは、Web ページの外部チェーンとして OSS リソースを使用するユーザーを対象としています。また、盗難防止チェーンを設定することにより、不要なリソースの使用を回避する方法について説明します。

実装方法

現在、OSS が提供する盗難防止チェーンのメソッドには、主に次の 2 種類があります。

  • Set Referer: 操作はコンソールと SDK から利用でき、ユーザーは必要に応じて選択します。
  • Use signature URL: これは、開発に慣れているユーザーに適しています。

このページでは、次の 2 つの例を紹介します。

  • コンソールから リファラー盗難防止チェーンを設定
  • PHP SDK に基づく署名付き URL 盗難防止チェーンの動的生成

リファラーの設定

このセクションでは、リファラーの概要、OSS はリファラーを盗難防止チェーンにどのように使用するかについて焦点を当てています。

  • リファラーの概要

    リファラーは通常、リファラーに付属するヘッダーの HTTP 部分です。ブラウザーが Web サーバーに要求を送信したら、この要求のリンクのソースをサーバーに伝えます。 上記の例で、ユーザー B の Web サイトが userdomain-steal の場合、画像リンク http://referer-test.oss-cn-hangzhou.aliyuncs.com/aliyun-logo.png を盗もうとしています。 A の Web サイトドメイン名は userdomain です。

    チェーン Web サイトユーザー domain-steal の Web ページが次のような構成だとします。

    <html>
        <p>This is a test</p>
        <img class="img-responsive"src="http://referer-test.oss-cn-hangzhou.aliyuncs.com/aliyun-logo.png" />
    </html>
    ソースステーションのユーザードメインを含む Web ページが次のような構成だとします。
    <html>
        <p>This is my test link from OSS URL</p>
        <img class="img-responsive"src="http://referer-test.oss-cn-hangzhou.aliyuncs.com/aliyun-logo.png" />
    </html>
    • インターネットユーザーがブラウザーを使用して B の Web サイト http://userdomain-steal/index.html の Webページにアクセスすると、Web ページ内のリンクはサイト A の画像になります。あるドメイン名 (user domain-steal) からの要求が別のドメイン名 (maid) にジャンプしたので、次に示すように、ブラウザーは HTTP 要求のヘッダーにそれと一緒にリファラーを取得します。

      HTTP 要求内のブラウザーのリファラーは、http://userdomain-steal/index.htmlであることが確認できます。 次のように、本ページでは主に Chrome の開発者モードを使用して Web ページ要求を表示します。

    • 同じブラウザーが http://userdomain/error.html にアクセスすると、ブラウザーのリファラーは http://userdomain/error.html であることも確認できます。
    • ブラウザーがアドレスを直接入力した場合は、要求内のリファラーが空であることが確認できます。

      OSS に リファラー関連の設定がない場合は、3 つのケースすべてでユーザーの画像リンクにアクセスできます。

  • リファラー 盗難防止チェーンを介した OSS の原則

    ブラウザーが OSS リソースを要求した際に、ページジャンプが発生した場合、ブラウザーはその要求のリファラーを取得します。リファラーの値は前に開いたページの URL になります。リファラーは空の場合もあります。

    どちらの場合でも、OSS のリファラー機能は 2 つのオプションを提供します。

    • 空のリファラーアクセスを許可するかどうかを設定します。 個別に設定することはできず、リファラーホワイトリストと組み合わせて使用する必要があります。
    • リファラーホワイトリストの設定

    詳細は以下のように分析されます。

    • 盗難防止チェーン認証は、ユーザーが署名付き URL または匿名アクセスを通じてオブジェクトにアクセスしている場合にのみ、実行されます。 要求されたヘッダーに "Authorization" フィールドがある場合、盗難防止チェーンの検証は行われません。
    • バケットは複数のリファラーパラメーターをサポートしています。
    • リファラーパラメーターは、ワイルドカード文字 "*" と "?" をサポートしています。
    • ユーザーは空のリファラーへのアクセス要求を許可するように設定できます。
    • ホワイトリストが空の場合、リファラーフィールドは空であることがチェックされません (そうでない場合、すべての要求が拒否されます。空でないリファラー OSS はリファラーホワイトリスト上でも見つからないため、空のリファラーは拒否されます)。
    • ホワイトリストは空ではありません。また、リファラーフィールドを空にできないようにする規則が設定されています。 リファラー要求のホワイトリストのみが許可され、リファラーが空のものを含む他の要求は拒否されます。
    • ホワイトリストは空ではありませんが、"リファラーフィールドを空にすることを許可する" というルールが設定されています。 リファラーの空の要求とホワイトリストに準拠した要求は許可され、他の要求は拒否されます。
    • バケットの 3 つの権限 (private、public-read、public-read-write) リファラーフィールドがチェックされます。

    ワイルドカード文字の説明:

    • アスタリスク "*": 0 文字以上の代わりにアスタリスクを使用できます。 "AEW" で始まるファイル名を探している場合は (AEWT.txt、AEWU.EXE、AEWI.dll など)、"AEW" で始まる名前のすべての種類のファイルを検索するため、"AEW" と入力します。 検索範囲を絞り込む場合は、"AEW.txt" と入力することで、"AEW" で始まる名前を持つすべての .txt ファイル (AEWIP.txt や AEWDF.txt など) を検索できます。
    • 疑問符 (?): 1 文字を表します。 "love?" と入力すると、lovey や lovei のように、名前が "love" で始まり、ある文字で終わるすべての種類のファイルが表示されます。 検索範囲を絞り込む場合は、"love?.doc" と入力し、lovey で始まり、lovey.doc や lovei.doc のように、ある文字で終わる名前を持つすべての .doc ファイルを検索できます。
  • 各種リファラー設定の アンチリーチ 効果

    以下で、リファラー設定の効果について説明します。

    • 次の図に示すように、[空のリファラーを許可する]を無効にします。

      直接アクセス: アンチリーチ が有効になっている場合でもリソースにアクセスできます。 その理由は、ホワイトリストが空の場合、リファラーフィールドが空かどうかがチェックされないためです。 ホワイトリストが空の場合、リファラー設定は有効になりません。 そのため、リファラーホワイトリストを設定する必要があります。

    • [空のリファラーを許可する] を無効にして、リファラーホワイトリストを設定します。

      前の例で示したように、ブラウザーの要求リファラーは現在の Web ページの URL です。 そのため、要求がどの URL からジャンプするのかを知った上で、その URL を指定する必要があります。

      リファラーホワイトリスト設定規則:

      • この例では、リファラーは http://userdomain/error.html です。 そのため、リファラーホワイトリストは http://userdomain/error.htmlに設定します。 OSS によって実行されるリファラーチェックはプレフィックスマッチングに基づいているため、http://userdomain/index.htmlなどの他の Web ページへのアクセスは失敗します。 この問題を回避するには、リファラーホワイトリストを http://userdomain/ に設定します。
      • http://img.userdomain/index.html などの他のドメイン名へのアクセスを許可するには、http://*.userdomain/ をリファラーホワイトリストに追加します。

      両方のエントリーは、次の図に示すように設定されます。

      テスト後、以下の結果が得られます。

      ブラウザーの入力 予想 結果
      http://referer-test.oss-cn-hangzhou.aliyuncs.com/aliyun-logo.png 空のリファラーの直接アクセスに対する予想。 : 空のリファラーは許可されず、OSS は 403 を返します。 予想通り
      http://userdomain/error.html オリジンサイトからの要求に対する予想: c 予想通り
      http://userdomain-steal/index.html リーチングサイトからの要求に対する予想: OSS は 403 を返します。 アンチリーチ 保護は成功。 予想通り
      http://img.userdomain/error.html オリジンサイトの第 3 レベルドメインからの要求に対する予想: アクセス成功 予想通り
      • このテストでは、ドメイン名は単なる例として提供されており、実際に使用するドメイン名とは異なります。 例で使用したドメイン名と、実際に使用するドメイン名は必ず区別するようにします。
      • リファラーホワイトリストに http://userdomain/ しか含まれておらず、ブラウザーがシミュレートされた第 3 レベルドメイン名 http://img.userdomain/error.html を介してリソースへのアクセスを試みた場合、第 3 レベルドメイン名はリファラーホワイトリストのいずれのエントリとも一致せず、OSS は 403 を返します。
    • [空のリファラーを許可] を有効にして、リファラーホワイトリストを設定します。

      次の図に示すように、リファラーホワイトリストには、http://*.userdomain/http://userdomain が含まれています。

      テスト後、以下の結果が得られます。

      ブラウザーの入力 予想 結果
      http://referer-test.oss-cn-hangzhou.aliyuncs.com/aliyun-logo.png 空のリファラーの直接アクセスに対する予想。:アクセス成功 予想通り
      http://userdomain/error.html オリジンサイトからの要求に対する予想: アクセス成功 予想通り
      http://userdomain-steal/index.html リーチングサイトからの要求に対する予想: OSS は 403 を返します。 アンチリーチ 保護は成功。 予想通り
      http://img.userdomain/error.html オリジンサイトの第 3 レベルドメインからの要求に対する予想: アクセス成功 予想通り
  • OSS でリファラーを設定する方法

    機能用途のリファレンス

  • リファラー アンチリーチ 保護の長所と短所

    リファラー アンチリーチ 保護は、コンソールで簡単に設定することができます。 リファラー アンチリーチ 保護の主な欠点は、悪意のある偽装のリファラーによるアクセスの試みを防ぐことができないことです。 リーチャーがアプリケーションを使用して偽装のリファラーを使用して HTTP 要求をシミュレートする場合、リファラーはアンチリーチ 保護設定を回避できてしまいます。 より高い アンチリーチ 保護要件がある場合は、署名付き URL アンチリーチ 保護の使用をご検討ください。

署名付き URL

署名付き URL の原則と実装方法については、「サードパーティーダウンロードの承認」をご参照ください。 署名付き URL は次のように実装されています。

  1. バケットのアクセス許可を "private-read" に設定します。
  2. 予想される有効期限 (署名付き URL の有効期限が切れる時間) に基づいて署名を生成します。
具体的な実装
  1. 「PHP SDK の説明書」を参照し、最新の PHP コードをインストールします。
  2. 署名付き URL を生成し、それを外部リンクとして Web ページに追加します。次に例を示します。
    <? php
     require 'vendor/autoload.php';
     # 最新の PHP が提供する自動ロード機能を示します。
     use OSS\OssClient;
     # 使用されているネームスペースを示します。
     $accessKeyId="a5etodit71tlznjt3pdx7lch";
     # AccessKeyId を示します。これは、使用する ID に置き換える必要があります。
     $accessKeySecret="secret_key";
     # AccessKeySecret を示します。これは、使用するキーに置き換える必要があります。
     $endpoint="oss-cn-hangzhou.aliyuncs.com";
     # バケットによって作成されたリージョンに基づいて選択されたエンドポイントを示します。 この例では、エンドポイントは杭州です。
     $bucket = 'referer-test';
     # バケットを示します。バケットは使用するバケットと交換する必要があります。
     $ossClient = new OssClient($accessKeyId, $accessKeySecret, $endpoint);
     $object = "aliyun-logo.png";
     # 署名するオブジェクトを示します。
     $timeout = 300;
     # 予想されるリンクの有効期限を示します。 この値は、コード行の実行が開始されてから 300 秒間リンクが有効であることを示します。
     $signedUrl = $ossClient->signUrl($bucket, $object, $timeout); # 署名付き URL を実装するために使用される関数を示します。
     $img= $signedUrl;
     # 署名付き URL をイメージリソースに動的に配置して出力することを示します。
     $my_html = "<html>";
     $my_html .= "<img class="img-responsive"src=\"".$img. "\" />";
     $my_html .= "<p>".$img."</p>";
     $my_html .= "</html>";
     echo $my_html;
     ? >
  3. ブラウザーがリソースを複数回要求すると、異なる署名付き URL が表示されることがあります。 署名付き URL は期限切れになると変更されるため、これは通常の現象です。 有効期限が切れると、リンクは無効になります。 これは UNIX の時刻形式で表示されます (例えば、Expires=1448991693)。 時間は現地時間に変換できます。Linux では、時刻を変換するためのコマンドはdate -d@1448991693です。 インターネット上に変換ツールもあります。
特殊な指示

署名付き URL は、リファラーホワイトリスト機能で使用できます。

署名付き URL の有効期限が数分に制限されている場合、リーチャーがリファラーを偽装した場合でも、リーチャーは署名付き URL を取得して署名付き URL が期限切れになる前に、完全に検索を実行する必要があります。 リファラーのメソッドと比較して、これはリーチングをより困難にします。 署名された URL をリファラーホワイトリスト機能と一緒に使用することで、アンチリーチ 保護を強化することができます。

まとめ

OSS ベースの アンチリーチ 保護のベストプラクティス

  • referer-test.oss-cn-hangzhou.aliyuncs.com/aliyun-logo.png などの第 3 レベルのドメイン名 URL は、バインドされた第 2 レベルのドメイン名よりも安全なので、使用することを推奨します。 第 3 レベルのドメイン名アクセス方式では、バケットレベルのクリーニングと分離が可能になるため、さまざまなバケットが相互に影響を及ぼさないようにしながら、リーチングトラフィックのバーストに対応できるため、サービスの可用性が向上します。
  • カスタムドメイン名をリンクとして使用する場合は、ルールバケット + エンドポイントを使用して、CNAME を第 3 レベルのドメイン名にバインドします。 たとえば、バケットの名前は “ test”、第 3 レベルのドメイン名は test.oss-cn-hangzhou.aliyuncs.com です。
  • バケットにはできるだけ厳しいアクセス許可を設定してください。 たとえば、インターネットサービスを提供するバケットを "public-read" または "private" に設定します。 "public-read-write" には設定しないようにしてください。 バケットのアクセス許可の情報については、「アクセス制御」をご参照ください。
  • アクセスソースを検証し、要件に基づいてリファラーホワイトリストを設定します。
  • より厳格な Anti-leeching ソリューションが必要な場合は、署名付き URL の使用をご検討ください。
  • バケットのアクセスログを記録することで、漏出を迅速に発見し、Anti-leeching ソリューションの有効性を検証できるようにします。 アクセスログの情報については、「アクセスログの設定」をご参照ください。

よくあるご質問

  • OSS コンソールで アンチリーチ 保護を設定しましたが、設定が有効になりません。 Web ページへのアクセスはブロックされますが、プレーヤーへのアクセスはブロックされません。 なぜでしょうか。 この問題はどのようにしたら修正できるでしょうか。

    現在、アンチリーチ 保護は、オーディオファイルやビデオファイルには適用されていません。 Windows Media Player や Flash Player などのメディアプレーヤーを使用して OSS リソースを要求すると、空のリファラー要求が送信されます。 これは アンチリーチ 保護を無効にします。 この問題を解決するには、前述の署名付き URL のアンチリーチ 保護メソッドをご確認ください。

  • リファラーとは何ですか。 リファラーはどのように送られますか。 HTTPS Web サイトをどのように扱いますか。 コンマなど、他に何か追加する必要はありますか。

    リファラーは HTTP プロトコルの要求ヘッダーです。 リファラーはページジャンプを伴う要求にアタッチされています。 ブラウザーから送信された要求の中のリファラーが http://https:// かを確認する必要があります。 通常、リファラーは http:// です。

  • 署名付き URL はどのように生成されますか。AccessKeySecret をクライアントに保存するのは安全ですか。

    URL への署名方法については、個々の SDK のドキュメントをご参照ください。 AccessKeySecret を直接クライアントに格納することは推奨されません。 RAM はこの問題を解決するため、STS サービスを提供します。 「RAM および STS ガイド」についてもご参照ください。

  • a.baidu.comb.baidu.com と書くためにはワイルドカード文字 (*、?) はどのように使用すればいいですか。

    http://*.baidu.com と書きます。 ワイルドカード文字が 1 文字のみを表す場合は、http://?.baidu.com とすることもできます。

  • *.domain.com は第 2 レベルのドメイン名と一致しますが、domain.comとは一致しません。 また、domain.com の 2 番目のエントリを追加するだけでは機能しません。 どのような設定が必要ですか。

    リファラーには通常、"http" などのパラメーターが含まれています。 Chrome の開発者モードで要求リファラーを表示し、対応するリファラーを指定します。 この場合のように、http:// を含めるのを忘れている可能性があります。http://domain.com とする必要があります。

  • アンチリーチ 保護が有効ではない場合はどうしたらいいですか。

    問題を解決するため、Chrome を使用することを推奨します。 開発者モードを開き、Web ページをクリックして、HTTP 要求内のリファラーの特定の値を表示します。 リファラーの値が OSS で設定されているリファラーの値と一致するかどうかを確認します。 値が一致しない場合は、OSS で設定されているリファラーの値を HTTP 要求内のリファラーの値に設定します。 問題が解決しない場合は、チケットを起票し、サポートセンターへお問い合わせください。