背景
たとえば、A はウェブサイトのウェブマスターです。ウェブサイトのウェブページには、画像やオーディオ/ビデオファイルへのリンクが含まれています。これらの静的リソースは、Alibaba Cloud OSS に格納されています。 たとえば、A は URLhttp://referer-test.oss-cn-hangzhou.aliyuncs.com/aliyun-logo.png
上にイメージファイルを保存することができます。
OSS 外部リソース url については、OSS アドレスを参照してください。そのような URL(署名なし)では、ユーザーのバケット許可が必要です。
B は別のウェブサイトのウェブマスターであり、B は許可なくウェブサイトの画像リソースを使用し、この方法を使用してウェブサイトのウェブページにスペースとトラフィックを盗み出します。この場合、サードパーティの Web サイトユーザーは B Web サイトを参照しますが、Web サイト上の画像のソースは明確ではありません。OSS は用途別に料金を徴収するため、ユーザ A は利益を得られないため、代わりにリソース使用のコストが負担されます。
この記事は、OSS リソースを Web ページの外部チェーンとして使用するユーザー、OSS にリソースを保存したユーザー、盗難防止チェーンを設定して不要なリソースを使用しないようにする方法についても説明します。
実装方法
現在、OSS が提供する盗難防止チェーンの方法には、主に次の 2 つのタイプがあります。
- Set Referer : 操作はコンソールと SDK から利用でき、ユーザは必要に応じて選択できます。
- 署名 URL を使用する:開発に慣れているユーザーに適しています。
この記事では、次の2つの例を示します。
- Referer の盗難防止チェーンをコンソールから設定する
- PHP SDK に基づいた署名付き URL 盗難防止チェーンの動的生成
リファラーを設定する
このセクションでは、Referer が何であるか、そして OSS が Referer を盗難防止チェーンに使用する方法に焦点を当てています。
- リファラーとは何ですか?
Referer は HTTP ヘッダーの一部で、ブラウザが Web サーバーに要求を送信したときにリファラーが付いています。この要求のリンク元をサーバーに伝えます。上記の例では、ユーザー B の Web サイトがユーザードメインスティールの場合、画像リンク
http://referer-test.oss-cn-hangzhou.aliyuncs.com/aliyun-logo.png
を盗み出したいと考えています。A の Web サイトドメイン名はuserdomain
です。チェーン Web サイトのユーザードメインスチールの Web ページが次のようになっているとします。
ソースステーション userdomainを持つWebページが次のようになっているとします。<html> <p>This is a test</p> <img src=”http://referer-test.oss-cn-hangzhou.aliyuncs.com/aliyun-logo.png” /></html>
<html> <p>This is my test link from OSS URL</p> <img src=”http://referer-test.oss-cn-hangzhou.aliyuncs.com/aliyun-logo.png” /></html>
- インターネットユーザーがブラウザを使用して B の Web サイト
http://userdomain-steal/index.html
ページにアクセスすると、Web ページのリンクはサイト A の画像になります。1 つのドメイン名( userdomain-steal)が別のドメイン名(メイド)にジャンプした場合、ブラウザは次のように HTTP リクエストのヘッダーで Referer を取得します。HTTP 要求のブラウザ Referer が
http://userdomain-steal/index.html
であることがわかります。この記事では主に Chrome のデベロッパーモードを使用して、次のようなウェブページリクエストを表示しています。 - 同じブラウザが
http://userdomain/error.html
を訪問し、ブラウザの Referer がhttp://userdomain/error.html
であることもわかります。 - ブラウザがアドレスを直接入力すると、リクエストで Referer が空であることがわかります。
a が OSS 上にリファラー関連の設定を持たない場合、3 つのケースすべてがユーザの画像リンクにアクセスすることができます。
- Referer の盗難防止チェーンによる OSS の原則
したがって、ブラウザが OSS リソースを要求すると、ページジャンプが発生した場合、ブラウザはリクエストで Referer を受け取り、Referer の値は前のページの URL になります。Referer は空の場合もあります。
どちらの場合も、OSS Referer 機能には 2 つのオプションがあります。
- 空の Referer アクセスを許可するかどうかを設定します。個別に設定することはできません。リファラーホワイトリストと組み合わせて使用する必要があります。
- リファラーのホワイトリストを設定します。
詳細は次のように分析されます。
- 盗難防止チェーン認証は、ユーザーが署名された URL または匿名アクセスによってオブジェクトにアクセスしている場合にのみ実行されます。要求されたヘッダーに「認可」フィールドがある場合、盗難防止チェーン検証は行われません。
- バケットは複数の Referer パラメータをサポートできます。
- Referer パラメータはワイルドカード文字 ‘’と ‘?’をサポートします。
- ユーザーは、空の referer に対する要求アクセスを許可するように設定できます。
- 白リストが空の場合、Referer フィールドは空でないことがチェックされます(空でない Referer が拒否されるため、すべての要求は拒否されます。空でない Referer OSS も Referer White List に見つかりません)。
- ホワイトリストは空ではなく、Referer フィールドが空ではないルールが設定されています。Referer のホワイトリストのみが許可され、Referer が空であるリクエストを含む他のリクエストは拒否されます。
- ホワイトリストは空ではありませんが、ルール “リファラーフィールドを空にする”が設定されています。Referer の空のリクエストとホワイトリストのリクエストは許可され、他のリクエストは拒否されます。
- Referer フィールドのバケット(private、public-read、public-read-write)の 3 つのパーミッションがチェックされています。
ワイルドカード文字の説明:
- アスタリスク’’:0 個以上の文字の代わりにアスタリスクを使用できます。AEWで始まるファイル名を検索する場合は、「AEW」で始まるすべてのタイプのファイル(AEWT.txt、AEWU.EXE、AEWI.dllなど)を検索するためにAEWを入力できます。 検索範囲を絞り込む場合は、AEW.txt と AEWDF.txt などのAEW.txtで始まるすべての.txt ファイルを検索するために AEW.txt を入力します。
- 疑問符(?):1 文字を表します。love?と入力すると、「love」で始まり、「lovey」や「lovei」などの文字で終わる名前のファイルがすべて表示されます。検索範囲を絞りたい場合は、love?.doc と入力して、「love」で始まり、lovey.doc や lovei.doc などの文字で終わるすべての.doc ファイルを検索できます。
- 異なる Referer 設定のアンチリーチ効果
Referer 設定の影響については、次のとおりです。
- 次の図に示すように、空の Referer を無効にします。
直接アクセス:反リーチ保護が有効になってもリソースにアクセスできます。その理由は、ホワイトリストが空白の場合、Referer フィールドが空白であるかどうかはチェックされません。ホワイトリストが空白の場合、Referer 設定は有効になりません。したがって、リファラーホワイトリストを設定する必要があります。
- 空の Referer を無効にし、Referer ホワイトリストを構成します。
前の例に示すように、ブラウザリクエストの Referer は、現在の Web ページの URL です。したがって、どの URL からリクエストがジャンプしたのかを知り、URL を指定する必要があります。
リファラーホワイトリストの設定ルール:
- この例では、Referer は
http://userdomain/error.html
です。したがって、リファラーホワイトリストはhttp://userdomain/error.html
に設定できます。OSS によって実行される Referer チェックはプレフィックスマッチングに基づいているため、http://userdomain/index.html
などの他の Web ページへのアクセスは失敗します。この問題を回避するには、リファラーホワイトリストをhttp://userdomain/
に設定することができます。 http://img.userdomain/index.html
などの他のドメイン名にアクセスできるようにするには、リファラーホワイトリストにhttp://*.userdomain/
を追加します。- このテストでは、ドメイン名は例としてのみ提供され、使用する実際のドメイン名と同じではありません。差別化を図ってください。
- リファラーホワイトリストに
http://userdomain/
のみが含まれていて、ブラウザがシミュレーションされた第 3 レベルのドメイン名http://img.userdomain/error.html
を介してリソースにアクセスしようとすると、第 3 レベルのドメイン名が一致しません Referer ホワイトリストのエントリのいずれか、および OSS は 403 を返します。 - [空の参照者を許可する]を有効にし、参照者のホワイトリストを構成します。
リファラーホワイトリストには、次の図に示すように、
http://*.userdomain/
とhttp://userdomain
が含まれています。テスト後、次の結果が得られます。
ブラウザ入力 期待 結果 http://referer-test.oss-cn-hangzhou.aliyuncs.com/aliyun-logo.png 空白の Referer による直接アクセスの期待:アクセスの成功 予想通り http://userdomain/error.html 起点サイトからの要求に対する期待:成功したアクセス 予想通り http://userdomain-steal/index.html リーチングサイトからのリクエストに対する期待:OSS は 403 を返します。アンチリーチ保護は成功しています。 予想通り http://img.userdomain/error.html 起点サイトの第 3 レベルドメインからの要求に対する期待:成功したアクセス 予想通り
ブラウザーの入力 想定 結果 http://referer-test.oss-cn-hangzhou.aliyuncs.com/aliyun-logo.png Referer:空白のReferers は許可されず、OSS は 403 を返します。 予想通り http://userdomain/error.html 起点サイトからの要求に対する期待:成功したアクセス。 予想通り http://userdomain-steal/index.html リーチングサイトからのリクエストに対する期待:OSS は 403 を返します。アンチリーチ保護は成功しています。 予想通り http://img.userdomain/error.html 起点サイトの第 3 レベルドメインからの要求に対する期待:成功したアクセス。 予想通り 注意 - この例では、Referer は
- OSS でリファラーを設定する方法
機能使用のリファレンス:
- API: バケットリフェラーを置く
- Console: アンチリーチの設定
- Referer アンチヒール保護の長所と短所
Referer anti-heech 保護はコンソールで簡単に設定できます。Referer anti-heech 保護の主な欠点は、悪意のあるスプーフィング Referers によるアクセス試行を防ぐことができないことです。リーパーがアプリケーションを使用してスプーフィング Referer で HTTP 要求をシミュレートした場合、Referer は反リーチ防止設定をバイパスできます。反リーチ防護要件がさらに高い場合は、署名された URL 反リーチ保護の使用を検討してください。
署名された URL署名付き URL の原則と実装方法については、第三者 Authorizing third-Party の承認を参照してください。署名付き URL は、次のように実装されます。
- バケット権限をプライベート読み取りに設定します。
- 有効期限(署名済みURLが期限切れになった時刻)に基づいて署名を生成します。
特定の実装- 最新の PHP コードは、PHP SDK のドキュメントを参照してインストールしてください。
- 署名付きの URL を生成し、それを外部リンクとして Web ページに追加します。例:
<? php require ‘vendor/autoload.php’; #Indicates the automatic loading function provided by the latest PHP. use OSS\OssClient; #Indicates the namespace used. $accessKeyId=”a5etodit71tlznjt3pdx7lch”; #Indicates the AccessKeyId, which must be replaced by the one you use. $accessKeySecret=”secret_key”; #Indicates the AccessKeySecret, which must be replaced by the one you use. $endpoint=”oss-cn-hangzhou.aliyuncs.com”; #Indicates the Endpoint, selected based on the region created by the bucket. In the example, the endpoint is Hangzhou. $bucket = ‘referer-test’; #Indicates the bucket, which must be replaced by the one you use. $ossClient = new OssClient($accessKeyId, $accessKeySecret, $endpoint); $object = “aliyun-logo.png”; #Indicates the object to be signed. $timeout = 300; #Indicates the expected link expiration time. The value indicates that the link is valid for 300 seconds from when this line of code starts running. $signedUrl = $ossClient->signUrl($bucket, $object, $timeout); #Indicates the function used to implement the signed URL. $img= $signedUrl; #Indicates dynamically placing the signed URL in image resources and printing it out. $my_html = “<html>”; $my_html .= “<img class="img-responsive"src=\””.$img. “\” />”; $my_html .= “<p>”.$img.”</p>”; $my_html .= “</html>”; echo $my_html; ? >
- ブラウザがリソースを複数回要求すると、署名された異なる URL が表示されることがあります。これは、署名された URL が期限切れになると変更されるため、通常の現象です。有効期限が過ぎると、リンクはもはや有効ではなくなります。Unix の時刻形式で表示されます(Expires = 1448991693 など)。 時間は現地時間に変換することができます。Linux では、時刻を変換するコマンドは
date -d@1448991693
です。また、インターネット上で変換ツールを見つけることもできます。
特別な指示署名付き URL は、Referer ホワイトリスト機能で使用できます。
署名された URL の有効期限が数分に制限されている場合、リーチャが Referer をスプーフィングした場合でも、署名された URL が取得され、署名された URL が期限切れになる前にリーチを完了する必要があります。Referer メソッドと比較して、これはリーチングをより困難にします。Referer ホワイトリスト機能で署名された URL を使用すると、吊り上げ防止機能が強化されます。
- 次の図に示すように、空の Referer を無効にします。
結論
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に設定しないでください。 バケット許可情報については、アクセス制御を参照してください。
- アクセス元を確認し、要件に基づいてリファラーのホワイトリストを設定します。
- より厳格な反リーチ解決策が必要な場合は、署名された URL の使用を検討してください。
- バケツのアクセスログを記録することで、すぐにリーチングを発見し、反リーチングソリューションの有効性を確認することができます。アクセスログ情報については、アクセスログ設定を参照してください。
よくある質問
- OSS コンソールでアンチヒールプロテクションを設定しましたが、設定が有効になりません。ウェブページへのアクセスはブロックされますが、プレーヤーへのアクセスはブロックされません。どうして?どのようにしてこの問題を解決できますか?
現在、オーディオファイルやビデオファイルに対して反リーチ保護が有効になっていません。Windows Media Player や Flash Player などのメディアプレーヤーを使用して OSS リソースを要求すると、空の Referer リクエストが送信されます。これにより、アンチヒール保護が無効になります。この問題を解決するには、先に署名した URL のアンチヒール防止方法を参照してください。
- Refererとは何ですか? どのように送信されますか? HTTPS の Web サイトを扱うには?コンマのようなものを追加する必要はありますか?
Referer は、HTTP プロトコルのリクエストヘッダです。 ページジャンプを伴うリクエストに添付されます。ブラウザから送信されたリクエストの Referer が
http://
またはhttps://
であるかどうかを確認する必要があります。通常、Referer はhttp://
。 - 署名付き URL はどのように生成されますか?クライアント上の AccessKeySecret を安全に保管していますか?
URL に署名する方法については、個々の SDK のマニュアルを参照してください。AccessKeySecret をクライアントに直接格納することはお勧めしません。RAM は、この問題を解決するための STS サービスを提供します。また、RAM と STS ガイドもご参照いただけます。
- ワイルドカード文字(、?)を使用して
a.baidu.com
とb.baidu.com
を書くにはどうすればよいですか?http://*.baidu.com
を使用できます。ワイルドカード文字が 1 文字のみを表す場合は、http://?.baidu.com
を使用することもできます。 *.domain.com
は第 2 レベルのドメイン名に一致しますが、domain.com
と一致しません。domain.com
の 2 番目のエントリだけを追加しても動作しません。どの設定を構成する必要がありますか?Referer には一般的に http などのパラメータが含まれています。リクエスト Referer を Chrome のデベロッパーモードで表示し、対応する Referer を指定することができます。この場合、
http://
を含めるのを忘れている可能性があります。これはhttp://domain.com
である必要があります。- 反リーチ保護が効力を発揮しない場合はどうすればよいですか?
Chrome を使用して問題を解決することをおすすめします。開発者モードを開き、Web ページをクリックして、HTTP リクエストの
Referer
固有の値を表示します。Referer
値が OSS で設定された Referer 値と一致するかどうかを確認します。一致しない場合は、OSS で設定された Referer 値を HTTP 要求の Referer 値に設定します。問題が解決しない場合は、チケットを開きます。