Referer ルールによる悪意のあるトラフィックの防止 - CDN

Referer ブラックリストまたはホワイトリストは、HTTP リクエストの Referer ヘッダーに基づいて、リソースへのアクセスを制御します。この機能により、ホットリンクや不正なリソース利用を防止します。設定が完了すると、CDN およびは Referer ヘッダーを評価し、アクセスを許可または拒否します。

重要

デフォルトでは、Alibaba Cloud CDN およびの Referer ブラックリスト/ホワイトリスト機能は無効になっており、どのウェブサイトからでもリソースにアクセスできます。
Referer ブラックリストとホワイトリストは、ホットリンクを防止する方法の 1 つです。その他の方法については、「ホットリンク防止のベストプラクティス」をご参照ください。
Referer リストに aliyundoc.com のようなドメイン名を追加すると、CDN およびはそのルールをドメイン自体とそのすべてのサブドメイン (例: *.aliyundoc.com) の両方に適用します。

Referer の構造

Referer ヘッダーは、リクエストの発生元となったページの URL を示します。次の図に示すように、Referer URL はスキーム、ドメイン、パス、クエリパラメーターで構成されます。

説明

Referer ヘッダーの値は、本質的に URL です。
Alibaba Cloud は、ドメインのみの Referer 設定をサポートしています。これを有効にするには、スキームを無視 オプションを選択します。

利用シーン

Referer ブラックリストまたはホワイトリストは、主にウェブサイトのリソースが他のウェブサイトから直接リンクされたり使用されたりするのを防ぎます。一般的な利用シーンは次のとおりです。

著作権保護：著作権で保護されたコンテンツを持つウェブサイトの場合、Referer ホワイトリストを使用して、許可されたウェブサイトのみにアクセスを制限できます。
ホットリンク防止：ホワイトリストにより、特定ウェブサイトからのみリソースにアクセスできるようになり、他のサイトがコンテンツに直接リンクして帯域幅を消費するのを防ぎます。
ウェブサイトのセキュリティ強化：特定のウェブサイトのみにリソースへのアクセスを許可することで、悪意のあるホットリンク、不正アクセス、機密情報の盗難を防ぐことができます。
トラフィックソースの制御：特定のウェブサイトからのトラフィックを制限して、トラフィックソースを制御し、ウェブサイトの安定性とセキュリティを向上させることができます。

仕組み

POP (Point of Presence) は、各リクエストの Referer ヘッダーをチェックします。Referer がホワイトリストにない場合、またはブラックリストにある場合、POP はリクエストを拒否します。これにより、帯域幅が節約され、オリジンサーバーの負荷が軽減されます。CDN およびは、次のルールを使用して Referer リクエストを処理します。

リクエストの Referer がブラックリストのエントリと一致する場合、またはホワイトリストのどのエントリとも一致しない場合、CDN およびはリクエストを拒否します。
リクエストの Referer がホワイトリストのエントリと一致する場合、CDN およびはリクエストを許可します。

注意事項

Referer ブラックリストを設定した後も、ブラックリストに登録されたソースからのリクエストは CDN およびの POP に到達する可能性があります。ただし、これらのリクエストは 403 ステータスコードで拒否され、CDN およびのログに記録されます。
Referer ブラックリスト/ホワイトリスト機能は、HTTP リクエストの Referer ヘッダーに基づいてアクセスを制御します。リクエストをブロックすると、生成されたトラフィックに対して少額の料金が発生します。HTTPS の場合、リクエストごとにも課金されます。
CDN のホットリンクはパブリックネットワークアクセスから発生するため、Referer ルールはパブリックドメイン名にのみ適用されます。

操作手順

CDN コンソールにログインします。
左側のナビゲーションウィンドウで、ドメイン名 をクリックします。
ドメイン名 ページで、対象のドメイン名を見つけ、操作列の管理をクリックします。
ドメインのナビゲーションウィンドウで、リソースアクセス制御 をクリックします。
Referer ブラックリスト / ホワイトリスト タブで、変更をクリックします。
Referer パラメーターを設定します。詳細については、「Referer の設定パラメーター」をご参照ください。
OK をクリックして設定を保存します。

Referer の設定パラメーター

パラメーター		説明
タイプ		ブラックリスト POP は、ブラックリストに含まれる Referer を含むリクエストへのアクセスを拒否します。ホワイトリスト POP は、ホワイトリストに含まれる Referer を含むリクエストのみを許可します。説明ブラックリストとホワイトリストは相互排他的です。一度に 1 つのタイプしか選択できません。
ルール		複数の Referer を追加できます。各エントリは改行で区切ります。アスタリスク () をワイルドカードとして使用して、すべてのサブドメインに一致させることができます。たとえば、`.example.com` は `example.com` のすべてのサブドメインに一致します。ワイルドカードを指定しない場合、エントリはドメイン自体とそのすべてのサブドメインの両方に一致します。たとえば、`example.com` のエントリは `example.com` と `*.example.com` の両方に一致します。説明 Referer リスト内のすべてのルールの合計サイズは 60 KB を超えることはできません。ルールにスキームを含める必要はありません。
リダイレクト URL		リクエストがブロックされた場合、POP は Location レスポンスヘッダーとともに 302 リダイレクトを返します。このパラメーターは、Location ヘッダーの値を指定します。URL は `http://` または `https://` で始まる必要があります。例：`http://www.example.com`。
詳細設定	ユーザーがブラウザのアドレスバーからリソース URL に直接アクセスできるようにします。	このオプションはデフォルトでクリアされています。このオプションを選択すると、リストの設定に関係なく、空の Referer を持つリクエストはブロックされず、リソースへのアクセスが許可されます。空の Referer は、次のいずれかとして定義されます。リクエストに Referer ヘッダーが含まれていない。 Referer ヘッダーの値が空である。
	完全一致	このオプションはデフォルトでクリアされています。このオプションを選択すると、サブドメインに一致するデフォルトの動作が無効になります。ワイルドカードを使用しない場合、`example.com` などのエントリは `example.com` にのみ一致します。
	スキームを無視	スキームを無視オプションがクリアされている場合、Referer ヘッダーには HTTP または HTTPS スキームが含まれている必要があります。スキームを無視オプションを選択すると、Referer ヘッダーにスキームを含める必要はありません。
ルール条件		ルール条件を使用すると、リクエストが特定の基準を満たした場合にのみルールを適用できます。重要機能がルール条件を参照する場合、実行順序は機能設定の順序ではなく、関連するルール条件の優先度に従います。使用しない：条件付きルールを無効にします。ルールエンジンで条件付きルールを追加または編集できます。

設定の検証

curl コマンドを使用して設定をテストできます。-e オプションを使用して Referer の値を指定し、-I オプションを使用して高速化ドメイン名のレスポンスヘッダーのみを取得します。以下の例では、検証のためにホワイトリストを使用します。

シナリオ 1：[ルール] パラメーターのみ

説明

このシナリオでは、aliyun.com の Referer ルールが設定されています。[リダイレクト URL]、[詳細設定]、および [ルール条件] パラメーターは設定されていません。
この設定は、http(s)://aliyun.com またはそのサブドメインからの Referer を含むリクエストに一致します。ホワイトリストにない Referer を持つリクエストは拒否されます。

メインドメインからの Referer でアクセスをテストします。コマンド：curl -e http://aliyun.com -I <accelerated_domain_name>。
```
HTTP/1.1 200 OK
Server: Tengine
```
サブドメインからの Referer でアクセスをテストします。コマンド：curl -e http://sub.aliyun.com -I <accelerated_domain_name>。
```
HTTP/1.1 200 OK
Server: Tengine
```
別のドメインからの Referer でアクセスをテストします。コマンド：curl -e http://aIiyun.com -I <accelerated_domain_name>。
```
HTTP/1.1 403 Forbidden
Server: Tengine
```
空の Referer でアクセスをテストします。コマンド：curl -e "" -I <accelerated_domain_name>。
```
HTTP/1.1 403 Forbidden
Server: Tengine
```
ドメインのみの Referer でアクセスをテストします。コマンド：curl -e aliyun.com -I <accelerated_domain_name>。
```
HTTP/1.1 403 Forbidden
Server: Tengine
```

シナリオ 2：[ルール] とユーザーがブラウザのアドレスバーからリソース URL に直接アクセスできるようにします。

説明

このシナリオでは、Referer ルールは aliyun.com に設定され、[ブラウザからのリソース URL への直接アクセスを許可] オプションが選択されています。その他の詳細設定、リダイレクト URL、およびルール条件は設定されていません。
シナリオ 1 と比較して、この設定では、ブラウザからの直接アクセスなど、空の Referer を持つリクエストも許可されます。

Referer なしでアクセスをテストします。コマンド：curl -I <accelerated_domain_name>。
```
HTTP/1.1 200 OK
Server: Tengine
```
空の Referer 値 ("") でアクセスをテストします。コマンド：curl -e "" -I <accelerated_domain_name>。
```
HTTP/1.1 200 OK
Server: Tengine
```

シナリオ 3: ルールとスキームを無視

説明

このシナリオでは、Referer ルールは aliyun.com に設定され、[スキームを無視] オプションが選択されています。その他の詳細設定、リダイレクト URL、およびルール条件は設定されていません。
この設定はシナリオ 1 と似ていますが、ドメイン名 aliyun.com のみを持つリクエストなど、スキームを含まない Referer リクエストも許可します。

スキームを持たない Referer でアクセスをテストします。コマンド：curl -e aliyun.com -I <accelerated_domain_name>。

HTTP/1.1 200 OK
Server: Tengine

よくある質問

Referer スキームの欠落

ほとんどの場合、ユーザーリクエストの Referer ヘッダーには HTTP または HTTPS スキームが含まれています。ただし、特定の状況では、Referer にスキームが含まれていない場合があります。

一般的なシナリオは、ユーザーが安全でないウェブサイト (HTTP を使用) から安全なウェブサイト (HTTPS を使用) に移動する場合です。ブラウザは、ユーザーデータを保護するために、Referrer-Policy などのセキュリティポリシーに基づいて Referer ヘッダーを変更または削除する場合があります。この場合、Referer ヘッダーにはスキームなしでドメインのみが含まれることがあります。

さらに、一部のブラウザやプロキシサーバーは、プライベートブラウジングモードが使用されている場合や、匿名プロキシを介してウェブサイトにアクセスした場合など、特定の状況で Referer ヘッダーを自動的に削除することがあります。

したがって、Referer ヘッダーにスキームがないリクエストを考慮する必要があります。このようなリクエストに一致させたい場合は、スキームを無視 オプションを選択します。

空の Referer の処理

空の Referer は、HTTP リクエストに Referer ヘッダーがない場合、またはその値が空の場合に発生します。リクエストの Referer ヘッダーには通常、スキーム (例: http または https)、ホスト名、および場合によってはパスとクエリ文字列を含む完全な URI が含まれています。空の Referer は、次のシナリオで発生する可能性があります。

直接アクセス：ユーザーがブラウザのアドレスバーに直接 URL を入力した場合、ブックマークを使用した場合、または新しい空白のタブでリンクを開いた場合、参照元のページは存在しません。したがって、Referer ヘッダーは空になります。
ユーザーのプライバシー：ユーザーまたはユーザーが使用するソフトウェア (ブラウザ拡張機能やプライバシーモードなど) が、プライバシーを保護するために意図的に Referer ヘッダーを削除する場合があります。
セキュリティプロトコル：ユーザーが HTTPS ページから HTTP ページに移動する場合、ブラウザは通常、機密情報の漏洩を防ぐために Referer ヘッダーを送信しません。
クライアント側のポリシー：一部のウェブサイトやアプリケーションは、<meta> タグや Referrer-Policy などの HTTP ヘッダーを設定することで、セキュリティ上の理由から Referer ヘッダーが送信されるかどうかを制御する場合があります。
クロスオリジンリクエスト：一部のクロスオリジンリクエストには、ブラウザのセキュリティポリシーにより Referer ヘッダーが含まれない場合があります。

空の Referer を持つリクエストの処理方法は、特定のユースケースとセキュリティ要件によって異なります。以下にいくつかの推奨事項を示します。

デフォルトポリシー：サービスが意思決定のために Referer 情報に依存していない場合は、空の Referer を持つリクエストを許可できます。
アクセスを許可：特定の URL またはオリジンについては、ユーザーがブラウザのアドレスバーからリソース URL に直接アクセスできるようにします。 オプションを選択できます。これにより、Referer が空の場合でもアクセスが許可されます。この場合、CDN およびの POP はリソースへのアクセスを許可します。