Referer のブラックリストとホワイトリストを使用したホットリンク保護 - Object Storage Service

OSS バケットに Referer のブラックリストとホワイトリストを構成して、リソースの不正なホットリンクを防ぎ、不要なトラフィックコストを削減できます。

仕組み

ブラウザが OSS からファイルをリクエストすると、HTTP リクエストの Referer ヘッダーには、リクエストを開始したページの URL が含まれます。OSS は、Referer の値を事前定義されたルールと照合して、アクセスを許可するか拒否するかを決定します。

ホットリンク保護を有効にすると、OSS は次の順序でアクセスリクエストを評価します。

空の Referer のチェック
- OSS はまず、リクエストの Referer ヘッダーが空であるかどうかをチェックします。
- 空の場合:
  - 空の Referer リクエストを許可する場合、OSS はリクエストを許可します。
  - 空の Referer リクエストを許可しない場合、OSS はホワイトリストも空である場合にのみリクエストを許可します。それ以外の場合、OSS はリクエストを拒否します。
ブラックリストのチェック
- 空でない Referer を持つリクエストの場合、OSS はブラックリストをチェックします。
- Referer がブラックリストのエントリと一致する場合、OSS はリクエストを直ちに拒否し、ホワイトリストのチェックをスキップします。
ホワイトリストのチェック
- リクエストの Referer が空でなく、ブラックリストと一致しない場合、OSS は次にホワイトリストをチェックします。
- リクエストの Referer がホワイトリストのエントリと一致する場合、OSS はリクエストを許可します。
- Referer がホワイトリストのどのエントリとも一致しない場合、OSS はリクエストを拒否します。

信頼できるウェブサイトからのアクセスのみを許可する

信頼できるウェブサイトのみが OSS リソースにアクセスできるように許可できます。この構成は、ブラウザからの直接アクセスもサポートし、OSS コンソールが正しく機能することを保証します。

ステップ 1: リクエスト Referer を取得する

ルールが有効であることを確認するには、まず OSS リソースにアクセスするリクエストから正確な Referer を特定する必要があります。

リアルタイムログクエリを使用する
1. OSS コンソールにログインします。
2. 左側のナビゲーションウィンドウで、[バケット] をクリックします。[バケット] ページで、ターゲットバケットの名前をクリックします。
3. 左側のナビゲーションウィンドウで、[ログ管理] > [リアルタイムクエリ] を選択します。
4. ログレコード内の referer フィールドを見つけます。このフィールドにハイフン (-) が表示されている場合、リクエストには空の Referer があります。
ブラウザの開発者ツールを使用する
1. Chrome などの最新のブラウザを使用して、OSS リソースを参照するウェブページにアクセスします。
2. F12 を押して[開発者ツール] を開き、[ネットワーク] パネルに切り替えます。
3. ページを更新し、OSS リソースのリクエストを見つけます。
4. リクエストを選択し、[ヘッダー] セクションで Referer フィールドの値を見つけます。

ステップ 2: ホットリンク保護ルールを構成する

OSS コンソールにログインします。
左側のナビゲーションウィンドウで、[バケット] をクリックします。[バケット] ページで、ターゲットバケットの名前をクリックします。
左側のナビゲーションウィンドウで、[データセキュリティ] > [ホットリンク保護] を選択します。
[ホットリンク保護] スイッチをオンにし、パラメーターを次のように構成します。
- [Referer ホワイトリスト]: 許可したいドメインを 1 行に 1 つずつ入力します。ユーザーは HTTP と HTTPS の両方を使用してウェブサイトにアクセスする可能性があるため、両方のプロトコルのエントリを追加します。また、コンソールの全機能を確保するために OSS コンソールドメインを追加する必要があります。
```
https://www.aliyun.com
http://www.aliyun.com
*.console.aliyun.com
```
  Referer ルールは、ワイルドカード文字のアスタリスク (*) と疑問符 (?) をサポートしています。たとえば、*.aliyun.com は aliyun.com のすべてのサブドメインに一致します。
- [Referer ブラックリスト]: このフィールドは空のままにします。ホワイトリストとブラックリストの両方が構成されている場合、ブラックリストが優先されます。
- [空の Referer]: [許可] を選択します。この設定により、ユーザーはブラウザのアドレスバーに URL を直接入力してファイルにアクセスでき、デスクトップアプリケーションなど、Referer ヘッダーを送信しないクライアントからのアクセスが可能になります。
- [QueryString の切り捨て]: [許可] (デフォルト) を選択します。柔軟性を高めるため、OSS は Referer を照合する際に、URL の疑問符 (?) の後の部分 (クエリ文字列) を無視します。
[保存] をクリックします。

ステップ 3: 構成を検証する

curl コマンドを使用して、さまざまなソースからのリクエストをシミュレートし、ホットリンク保護の構成が期待どおりに機能することを確認できます。

ホワイトリストに登録された Referer からのアクセスをシミュレートする (成功する見込み)
```
curl -e "http://www.aliyun.com" http://your-bucket-name.oss-cn-hangzhou.aliyuncs.com/demo.txt
```
期待される結果: demo.txt ファイルの内容が返されます。
ホワイトリストに登録されていない Referer からのアクセスをシミュレートする (拒否される見込み)
```
curl -e "http://www.example.com" http://your-bucket-name.oss-cn-hangzhou.aliyuncs.com/demo.txt
```
期待される結果: コマンドは AccessDenied と You are denied by bucket referer policy. を含むエラーメッセージを返します。
空の Referer でのアクセスをシミュレートする (成功する見込み)
```
curl http://your-bucket-name.oss-cn-hangzhou.aliyuncs.com/demo.txt
```
期待される結果: 構成が空の Referer を許可しているため、ファイルの内容が返されます。

特定の悪意のあるウェブサイトからのホットリンクをブロックする

ほとんどのソースからのアクセスを許可しつつ、特定の悪意のあるウェブサイトを明示的にブロックすることができます。他のすべての正当なソースへのアクセスを開いたまま、悪意のあるソースを正確にブロックするには、ブラックリストを使用できます。

ステップ 1: 悪意のあるウェブサイトの Referer を取得する

ルールを構成する前に、悪意のあるウェブサイトの Referer 値を正確に特定する必要があります。リアルタイムログをクエリして異常トラフィックを分析し、リソースをホットリンクしているソースを特定できます。

OSS コンソールにログインします。
左側のナビゲーションウィンドウで、[バケット] をクリックします。[バケット] ページで、ターゲットバケットの名前をクリックします。
左側のナビゲーションウィンドウで、[ログ管理] > [リアルタイムクエリ] を選択します。
異常トラフィックのレコードをフィルタリングし、referer フィールドをチェックして、悪意のあるウェブサイトのドメイン名パターンを特定します。

ステップ 2: ホットリンク保護ルールを構成する

OSS コンソールにログインします。
左側のナビゲーションウィンドウで、[バケット] をクリックします。[バケット] ページで、ターゲットバケットの名前をクリックします。
左側のナビゲーションウィンドウで、[データセキュリティ] > [ホットリンク保護] を選択します。
[ホットリンク保護] スイッチをオンにし、パラメーターを次のように構成します。
- [Referer ホワイトリスト]: ワイルドカード文字 * を入力して、すべてのソースからのアクセスを許可します。
```
*
```
- [Referer ブラックリスト]: ブロックしたい悪意のあるウェブサイトのドメインを 1 行に 1 つずつ入力します。
```
*bad-site.example
http://malicious-site.example
https://malicious-site.example
```
  ワイルドカード文字を使用すると、ドメイン全体とそのサブドメインを効果的にブロックできます。
- [空の Referer]: [許可] を選択します。これにより、直接アクセスや、Referer ヘッダーを送信しない正当なクライアントからのリクエストが続行できるようになります。
- [QueryString の切り捨て]: [許可] (デフォルト) を選択します。柔軟性を高めるため、OSS は Referer を照合する際に、URL の疑問符 (?) の後の部分 (クエリ文字列) を無視します。
[保存] をクリックします。

ステップ 3: 構成を検証する

通常のウェブサイトからのリクエストをシミュレートする (成功する見込み)
```
curl -e "http://www.example.com" http://your-bucket-name.oss-cn-hangzhou.aliyuncs.com/demo.txt
```
期待される結果: ファイルの内容が返されます。
ブラックリストに登録されたウェブサイトからのリクエストをシミュレートする (拒否される見込み)
```
curl -e "http://bad-site.example" http://your-bucket-name.oss-cn-hangzhou.aliyuncs.com/demo.txt
```
期待される結果: AccessDenied エラーメッセージが返されます。
空の Referer でのアクセスをシミュレートする (成功する見込み)
```
curl http://your-bucket-name.oss-cn-hangzhou.aliyuncs.com/demo.txt
```
期待される結果: ファイルの内容が返されます。

WeChat ミニプログラムからのアクセスを許可する

WeChat ミニプログラムで OSS リソースを使用するには、WeChat が送信する特定の Referer フォーマットを許可するようにホットリンク保護ルールを構成する必要があります。WeChat ミニプログラムからのリクエストには、https://servicewechat.com/{appid}/{version}/page-frame.html という固定の Referer フォーマットがあります。

ステップ 1: WeChat ミニプログラムの Referer フォーマットを理解する

WeChat ミニプログラムの Referer フォーマットは一貫しています。そのため、最初にキャプチャする必要なく、ワイルドカード文字で直接構成できます。正確なフォーマットを確認するには、次の手順に従います。

ミニプログラム内から OSS リソースにアクセスします。
リアルタイムクエリを使用して Referer フォーマットを確認します。
ログの referer フィールドを確認します。https://servicewechat.com/wx1234567890abcdef/1/page-frame.html のようになっているはずです。

ステップ 2: ホットリンク保護ルールを構成する

OSS コンソールにログインします。
左側のナビゲーションウィンドウで、[バケット] をクリックします。[バケット] ページで、ターゲットバケットの名前をクリックします。
左側のナビゲーションウィンドウで、[データセキュリティ] > [ホットリンク保護] を選択します。
[ホットリンク保護] スイッチをオンにし、パラメーターを次のように構成します。
- [Referer ホワイトリスト]: WeChat ミニプログラムのワイルドカードルールと OSS コンソールのドメインを入力します。
```
*servicewechat.com
*.console.aliyun.com
```
  ワイルドカードを使用すると、すべての WeChat ミニプログラムの AppID とバージョンに対応でき、構成が簡素化されます。コンソールドメインを追加すると、管理機能が引き続き機能することが保証されます。
- [Referer ブラックリスト]: このフィールドは空のままにします。
- [空の Referer]: [許可] を選択します。場合によっては、ミニプログラムが Referer を送信しないことがあります。空の Referer を許可することで、互換性が確保されます。
- [QueryString の切り捨て]: [許可] (デフォルト) を選択します。柔軟性を高めるため、OSS は Referer を照合する際に、URL の疑問符 (?) の後の部分 (クエリ文字列) を無視します。
[保存] をクリックします。

ステップ 3: 構成を検証する

WeChat ミニプログラムからのリクエストをシミュレートする (成功する見込み)
```
curl -e "https://servicewechat.com/wx1234567890abcdef/1/page-frame.html" http://your-bucket-name.oss-cn-hangzhou.aliyuncs.com/demo.txt
```
期待される結果: ファイルの内容が返されます。
不正なソースからのリクエストをシミュレートする
```
curl -e "http://www.example.com" http://your-bucket-name.oss-cn-hangzhou.aliyuncs.com/demo.txt
```
期待される結果: AccessDenied エラーメッセージ。
空の Referer でのアクセスをシミュレートする (成功する見込み)
```
curl http://your-bucket-name.oss-cn-hangzhou.aliyuncs.com/demo.txt
```
期待される結果: ファイルの内容が返されます。

プレビューとダウンロードのためのコンソールアクセスを有効にする

ホットリンク保護を設定した後、OSS コンソールからのファイルのダウンロードとプレビューを許可するには、Referer ホワイトリストに *.console.aliyun.com を追加する必要があります。これにより、ホットリンク保護ポリシーが OSS コンソールから発信されるリクエストをブロックしないようにします。

ステップ 1: ホットリンク保護ルールを構成する

OSS コンソールにログインします。
左側のナビゲーションウィンドウで、[バケット] をクリックします。[バケット] ページで、ターゲットバケットの名前をクリックします。
左側のナビゲーションウィンドウで、[データセキュリティ] > [ホットリンク保護] を選択します。
[ホットリンク保護] スイッチをオンにし、パラメーターを次のように構成します。
- [Referer ホワイトリスト]: OSS コンソールドメイン。
```
*.console.aliyun.com
```
  ワイルドカード *.console.aliyun.com を使用すると、OSS コンソールのすべてのサブドメインとの互換性が確保され、さまざまなリージョンやコンソールのバージョンでプレビューが正しく機能するようになります。
- [Referer ブラックリスト]: このフィールドは空のままにします。
- [空の Referer]: [許可] を選択します。これにより、直接アクセスとコンソールのプレビュー機能の両方が正しく機能することが保証されます。
- [QueryString の切り捨て]: [許可] (デフォルト) を選択します。柔軟性を高めるため、OSS は Referer を照合する際に、URL の疑問符 (?) の後の部分 (クエリ文字列) を無視します。
[保存] をクリックします。

ステップ 2: 構成を検証する

コンソールからのアクセスをシミュレートする (成功する見込み)
```
curl -e "https://oss.console.alibabacloud.com" http://your-bucket-name.oss-cn-hangzhou.aliyuncs.com/demo.txt
```
期待される結果: ファイルの内容が返されます。
コンソールからのプレビューとダウンロードを検証する (成功する見込み)
1. OSS コンソールにログインします。
2. ターゲットバケットに移動します。
3. ファイルのプレビューとダウンロードを試みます。

URL による直接アクセスをブロックする

すべてのリクエストが特定のウェブサイトから発信されるように強制できます。ユーザーが URL を使用してリソースに直接アクセスするのを効果的に防ぎ、より厳格なアクセス制御を提供するために、空の Referer を許可しないようにすることができます。

注意:

この構成は、ブックマークやメール内のリンクからのアクセスを含む、すべての直接アクセス方法をブロックします。
一部のブラウザプラグインやダウンロードマネージャーは正しく機能しない場合があります。
メディアプレーヤーは、セグメントリクエストで Referer ヘッダーが省略されることが多いため、正しく機能しない場合があります。

ステップ 1: ウェブサイトの Referer を決定する

構成がすべての正当なアクセスシナリオをカバーするように、ウェブサイトのすべての可能なドメインとプロトコルの組み合わせを特定する必要があります。

ブラウザの開発者ツールを使用して、ウェブサイトが OSS リソースにアクセスするときの実際の Referer 値を確認します。
www プレフィックスの有無や、さまざまなサブドメインなど、考えられるすべてのドメインのバリエーションを考慮します。
HTTP と HTTPS の両方のプロトコルのサポートを確認します。

ステップ 2: ホットリンク保護ルールを構成する

OSS コンソールにログインします。
左側のナビゲーションウィンドウで、[バケット] をクリックします。[バケット] ページで、ターゲットバケットの名前をクリックします。
左側のナビゲーションウィンドウで、[データセキュリティ] > [ホットリンク保護] を選択します。
[ホットリンク保護] スイッチをオンにし、パラメーターを次のように構成します。
- [Referer ホワイトリスト]: ウェブサイトのドメインと OSS コンソールのドメインを含めます。
```
https://www.example.com
http://www.example.com
*.console.aliyun.com
```
  実際のニーズに基づいて、必要なすべてのドメインとプロトコルの組み合わせを追加します。管理機能が正しく機能するように、コンソールドメインを追加します。
- [Referer ブラックリスト]: このフィールドは空のままにします。
- [空の Referer]: [許可しない] を選択します。これは、リソースへの直接アクセスをブロックする重要な設定です。
- [QueryString の切り捨て]: [許可] (デフォルト) を選択します。柔軟性を高めるため、OSS は Referer を照合する際に、URL の疑問符 (?) の後の部分 (クエリ文字列) を無視します。
[保存] をクリックします。

ステップ 3: 構成を検証する

ウェブページからのリクエストをシミュレートする (成功する見込み)
```
curl -e "http://www.example.com" http://your-bucket-name.oss-cn-hangzhou.aliyuncs.com/demo.txt
```
期待される結果: ファイルの内容が返されます。
直接アクセスをシミュレートする (拒否される見込み)
```
curl http://your-bucket-name.oss-cn-hangzhou.aliyuncs.com/demo.txt
```
期待される結果: AccessDenied エラーメッセージが返され、直接アクセスがブロックされていることを示します。
別のウェブサイトからのリクエストをシミュレートする (拒否される見込み)
```
curl -e "http://other.example" http://your-bucket-name.oss-cn-hangzhou.aliyuncs.com/demo.txt
```
期待される結果: AccessDenied エラーメッセージが返されます。

本番環境での適用

CDN でのキャッシュバイパスのリスク: OSS リソースに CDN アクセラレーションが構成されている場合、ホットリンクのリクエストが CDN エッジノードのキャッシュにヒットして提供されることがあり、OSS のホットリンク保護がバイパスされます。完全かつ効果的な保護を確保するには、多層保護を実装するために、CDN レイヤーで同じ Referer ホットリンク保護ルールを構成する必要があります。
ブラウザの Referrer-Policy の影響: 最新のブラウザは Referrer-Policy ヘッダーをサポートしており、これによりウェブサイトはクロスオリジンリクエストで送信される Referer 情報の量を制御できます。no-referrer などの特定のポリシーにより、ブラウザは Referer ヘッダーを省略します。OSS はこれらを空の Referer リクエストとして扱い、これは構成時に考慮すべき要素です。
ビデオ再生の互換性: ネイティブのブラウザ video タグでオンラインビデオファイルを再生する場合、ブラウザは通常、Referer を含む初期ページ読み込みリクエストと、Referer を含まない後続のメディアデータリクエストの 2 種類のリクエストを送信します。ビデオ再生が正しく機能するようにするには、空の Referer アクセスを許可する必要があります。

Referer 構成ルール

Referer ホワイトリストまたはブラックリストを構成する際は、次のルールに従う必要があります。

ルール	説明
Referer の照合には URL プロトコルが含まれる	`http://www.aliyun.com` として構成されたルールは、`http://www.aliyun.com/123` および `http://www.aliyun.com.cn` (`http://www.aliyun.com` で始まる任意のアドレス) に一致しますが、`https://www.aliyun.com/123`、`https://www.aliyun.com.cn`、または `www.aliyun.com` には一致しません。
アスタリスク (*) ワイルドカード文字は 0 個以上の文字を置き換える。	`` として構成されたルールは、すべてのドメイン名と IP アドレスに一致します。 `www.example.com` として構成されたルールは、`http://www.example.com`、`https://www.example.com`、および `www.example.com` に一致します。 `*.example.com` として構成されたルールは、`http://help.example.com`、`https://help.example.com`、`http://www.example.com`、および `https://www.example.com` に一致します。
疑問符 (?) ワイルドカード文字は 1 つの文字を置き換える。	`http://www.aliyun?.com` として構成されたルールは、`http://www.aliyunc.com` に一致します。
Referer にはポート付きのドメインまたは IP アドレスを含めることができる。	例には、`http://www.example.com:8080` および `10.10.10.10:8080` が含まれます。

QueryString 解析ルール

QueryString の切り捨てを許可しない場合、OSS は次のルールに従って QueryString を解析します。

ルール	説明
QueryString は URL デコードされない。	リクエスト URL が `http://www.example.com/?job_id=task$01` の場合、Referer リストが `http://www.example.com/?job_id=task%2401` に設定されていると、リクエスト URL は Referer に一致しません。
QueryString 内のパラメーターは大文字と小文字を区別しない。	リクエスト URL が `http://www.example.com/?ACTION=NOP` の場合、Referer リストが `http://www.example.com/?action=nop` に設定されていると、リクエスト URL は Referer に一致します。
クエリ文字列パラメーターの解析を無効にする	リクエスト URL が `http://example.com/?b=c&a=b` の場合、Referer リストが `http://example.com/?a=b&b=c` に設定されていると、リクエスト URL は Referer に一致しません。

クォータと制限

トリガー条件: OSS は、オブジェクトが匿名で、または署名付き URL を使用してアクセスされた場合にのみ、ホットリンク保護の検証を実行します。AccessKey などのメソッドを使用して署名された API 呼び出しは、ホットリンク保護ルールによって制限されません。これらの呼び出しは、Authorization ヘッダーを含むリクエストです。
リストサイズの制限: Referer ホワイトリストとブラックリストを合わせた合計データサイズは 20 KB を超えることはできません。この制限を超えると、構成を保存するときに InlineDataTooLarge エラーが返されます。
フォーマット仕様: ルールは、パターンマッチングのためにアスタリスク (*) と疑問符 (?) のワイルドカード文字をサポートしています。マッチングにはプロトコル名が含まれ、ポート番号付きのドメインまたは IP アドレス形式をサポートします。
効果の範囲: ホットリンク保護ルールはバケットレベルで適用されます。バケット内の特定のオブジェクトまたはディレクトリに対して異なるルールを構成することはできません。

よくある質問

ホットリンク保護の構成が機能しないのはなぜですか？

次の項目を順番に確認してください。

ブラウザ環境のチェック: WeChat ミニプログラムや iframe などの特定のブラウザ環境では、特定の Referer 値が変更または設定される場合があります。OSS のリアルタイムログまたはブラウザの開発者ツールを使用して、リクエストの実際の Referer 値をクエリし、ホットリンク保護ルールを再構成できます。
Referer フォーマットの仕様: 入力した Referer が正しいフォーマットであることを確認してください。ブラウザからのリクエストには通常、http:// または https:// プロトコルプレフィックスが含まれます。構成でプロトコルプレフィックスを省略すると、リクエストは正しく照合されません。OSS Referer 構成ルールに従う必要があります。
CDN でのキャッシュバイパス: CDN を使用して OSS へのアクセスを高速化しているが、CDN でホットリンク保護を構成していない場合、リクエストが検証をバイパスする可能性があります。たとえば、正しい Referer を持つ最初の CDN リクエストがファイルをキャッシュした場合、Referer のない後続のリクエストにキャッシュされたファイルが提供される可能性があります。CDN で一貫したホットリンク保護ルールを構成する必要があります。

WeChat ミニプログラムで OSS リソースへのアクセス拒否エラーを解決するにはどうすればよいですか？

WeChat ミニプログラムからのリクエストには、通常 https://servicewechat.com/ で始まる固定の Referer フォーマットがあります。ホットリンク保護のホワイトリストに *servicewechat.com ルールを追加して、すべてのミニプログラムからのアクセスに対応できます。

ブラウザのアドレスバーから直接ファイルにアクセスするときのアクセス拒否エラーを解決するにはどうすればよいですか？

ブラウザのアドレスバーから直接ファイルにアクセスすると、空の Referer リクエストが生成されます。ホットリンク保護の構成で空の Referer が許可されていない場合、このタイプのアクセスは拒否されます。直接アクセスをサポートするには、ホットリンク保護設定の [空の Referer] オプションを [許可] に変更します。

構成を保存するときに「InlineDataTooLarge」エラーが発生した場合はどうすればよいですか？

このエラーは、Referer リスト (ホワイトリストとブラックリストの合計) の合計サイズが 20 KB の制限を超えていることを示します。ワイルドカード文字を使用して類似のルールを組み合わせるか、不要なエントリを削除して構成のサイズを小さくすることができます。