【ITニュース解説】Fetching user-supplied URLs from a Cloudflare Worker without getting burned

ユーザーから提供されたURLを外部から取得する機能（例えば、ウェブサイトのプレビュー表示や、サイトの稼働状況チェックなど）を開発する際、セキュリティを確保することは非常に重要だ。なぜなら、悪意のあるユーザーがこの機能を利用して、本来アクセスしてはいけない内部システムにアクセスしたり、意図しない情報を引き出したりする「サーバーサイドリクエストフォージェリ（SSRF）」のような攻撃を仕掛ける可能性があるからだ。

Cloudflare Workerのようなサーバーレス環境でURLのフェッチを行う場合、いくつかのセキュリティ上の利点がある。例えば、従来のクラウド環境で攻撃の標的となりやすかった「localhost」に存在するクラウドプロバイダーのメタデータサービスは、Cloudflare Workerでは直接利用できないため、その種のリスクは軽減される。しかし、Workerは依然として内部ネットワークのホスト名や、認証されていないとアクセスできないオリジン、あるいは非常に大きなファイルを指定される可能性があり、これらすべてに対応するには追加のセキュリティ対策が必要になる。

この記事では、そうしたリスクを効果的に防ぐための具体的な対策ステップを説明している。これらの対策は、リクエストがシステムに到達した際に順番に適用され、安全なURLフェッチを実現する。

まず一つ目の対策は「ネットワーク接続前のURL検証」だ。実際にネットワークに接続してURLの内容を取得しようとする前に、そのURLが安全な形式であるかを厳しくチェックする。具体的には、プロトコルが「http:」または「https:」以外であれば、それを拒否する。なぜなら、これら以外のプロトコル（例：ftp:、file:）は異なるセキュリティリスクを持つ可能性があるからだ。また、URLの中にユーザー名やパスワードといった認証情報が含まれている場合も拒否する。これらが不用意に外部に送信されることを防ぐためだ。さらに、ポート番号も「80」（HTTPの標準ポート）または「443」（HTTPSの標準ポート）以外は許可しない。特定のポートへのアクセスを制限することで、予期せぬサービスへの接続を防ぎ、攻撃範囲を狭めることができる。加えて、URLのホスト名が「localhost」のような内部用途のものや、「.local」「.internal」といった公開されていないドメイン名である場合もブロックする。これらは外部からアクセスできないだけでなく、内部ネットワークへの探査に利用される可能性があるからだ。

二つ目の対策は「ホスト名の解決とIPアドレスの検証」だ。URLのホスト名が指定されたとしても、それが実際にどのIPアドレスを指しているのかを確認することは非常に重要だ。例えば、「example.com」が外部の公開サーバーを指していると思いきや、実は内部ネットワークのサーバーを指しているように偽装される可能性がある。Cloudflare Workerには直接DNSを検索する機能はないが、「DNS over HTTPS (DoH)」という仕組みを利用して、安全にIPアドレスを解決できる。この方法では、Cloudflareが提供するDNSサーバーにHTTPS経由でホスト名のIPアドレスを問い合わせる。このとき、IPv4アドレスとIPv6アドレスの両方を同時に問い合わせ、取得したすべてのIPアドレスが公開されているものかを厳しくチェックする。仮に、複数のIPアドレスが返され、その中に一つでもプライベートIPアドレス（例：10.x.x.xや192.168.x.xといった内部ネットワークで使われるアドレス）や、特殊な目的のアドレス（例：ループバックアドレス127.0.0.1、マルチキャストアドレスなど）が含まれていれば、そのリクエストは即座に拒否される。これは、攻撃者がDNSの応答を操作して、一部のIPアドレスだけを公開用にしつつ、もう一方を内部用にして、防御側のチェックをすり抜けようとする可能性があるためだ。特にIPv6アドレスは構造が複雑で、その中にIPv4アドレスが埋め込まれているケースもあるため、それらも正確に解析して、不正なIPアドレスが含まれていないかを確認する必要がある。

三つ目の対策は「リダイレクトの自己処理」だ。通常、URLをフェッチする際にウェブサーバーから「このURLは別の場所に移転しました」といったリダイレクト指示があった場合、多くのHTTPクライアントは自動的に新しいURLを追跡する。しかし、この自動追跡機能がセキュリティ上の大きな落とし穴となる可能性がある。なぜなら、最初のリクエストは厳しくチェックされたとしても、リダイレクト先のURLはチェックをスキップしてしまう可能性があるからだ。これを防ぐため、自動リダイレクト機能を無効にし、リダイレクト指示があった場合は、その新しいURLに対してもステップ1とステップ2で説明したすべての検証を再度適用する。これをリダイレクトの連鎖が終わるまで繰り返し行う。また、無限にリダイレクトが続く「リダイレクトループ」や、設定された最大リダイレクト回数を超える場合もエラーとして処理し、悪意のあるリダイレクト連鎖によるリソース枯渇を防ぐ。

四つ目の対策は「処理時間とデータ量の制限」だ。悪意のあるユーザーは、非常に大きなファイルを指定したり、応答に時間がかかるサーバーを指し示したりすることで、システムのリソースを枯渇させようとすることがある。これを防ぐために、取得するコンテンツのサイズと、フェッチにかかる処理時間を厳しく制限する。レスポンスヘッダーにコンテンツのサイズが記載されていれば、それが大きすぎる場合にすぐにリクエストを拒否できる。さらに、実際にデータをストリーミングで受信する際も、総バイト数が上限を超えないかを監視し、超えた時点で即座に処理を中断する。圧縮されたコンテンツ（例：gzip圧縮されたウェブサイトの地図ファイル）の場合、展開後に膨大なサイズになる可能性があるため、展開後のサイズも考慮して制限を適用する必要がある。また、すべてのフェッチ操作にタイムアウトを設定し、指定された時間内に応答がない場合は処理を中断することで、システムが無限に待機してしまう事態を防ぐ。Cloudflare Workerには無料プランで利用できるCPU時間やサブクエスト数に制限があるため、大きなファイルを処理したり、多数のDNSルックアップを行ったりすると、これらの制限に抵触する可能性もある。このような場合、DNSキャッシュの導入や有料プランへの移行を検討することも重要だ。

五つ目の対策は「robots.txtの適切な遵守」だ。もしアプリケーションがウェブサイトのコンテンツをクロールする目的を持つ場合、そのサイトの「robots.txt」ファイルに記載されたルールを尊重することは、ウェブのエチケットとして非常に重要だ。robots.txtは、どの部分のコンテンツをクロールしてよいか、どの部分をクロールしてはいけないかを示すファイルだ。2022年に標準化された新しいRFC 9309に従い、これらのルールを正確に解釈する必要がある。ルールには、最も具体的なパターンが優先されること、Allow（許可）とDisallow（不許可）が同じ具体性であればAllowが勝つこと、ユーザーエージェント（クロールするアプリケーションの名前）に合わせたグループを選択することなどが含まれる。robots.txt自体が取得できない場合（例えばサーバーエラーで）、すべてをクロール不可と見なすなど、堅牢な処理が求められる。これにより、不要なクロールや、サイト運営者が意図しないコンテンツの取得を防ぐことができる。

これらの多層的なセキュリティ対策が正しく機能することを保証するためには、徹底したテストが不可欠だ。単体テストでは、robots.txtのパターンマッチングが意図通りに機能するか、IPアドレスの検証ロジックがさまざまな形式の不正なIPアドレスを検出できるかなどを確認する。さらに、リダイレクトチェーンのテストや、不正なURLが適切にブロックされるかを検証する統合テストも必要だ。これにより、実運用環境で予期せぬ脆弱性が露呈するリスクを最小限に抑えることができる。

このように、ユーザーから提供されたURLをCloudflare Workerで安全にフェッチするためには、単一の対策だけでなく、URLの事前検証、IPアドレスの厳格なチェック、リダイレクトの自己管理、リソース使用量の制限、そしてウェブサイトのルール遵守といった、複数の段階にわたる包括的なセキュリティ対策を講じることが極めて重要になる。これらの対策を組み合わせることで、システムをSSRF攻撃やDoS攻撃などの脅威から守り、安定したサービス提供が可能となる。