エンジニア諸君、日々のお勤めご苦労様。CSOのデスクから少しだけ現場の「泥臭い話」をさせてもらう。
「XSS対策は万全だ」と胸を張る開発者に限って、Refererヘッダーによる機密情報の流出という盲点を見落としていることが多い。今回は、単なる脆弱性スキャナでは拾いにくい、この「仕様の隙間」を突く攻撃と、それを封じ込めるための実務的な防衛術を叩き込む。
—
1. なぜ「URL」が攻撃の入り口になるのか
Webアプリケーションにおいて、URLは単なるリソースの場所ではない。時に、セッションIDやパスワードリセットトークン、あるいは顧客の個人情報がクエリパラメータとして付与されることがある。
ここで、攻撃者が仕掛ける罠を想像してほしい。
1. 攻撃のシナリオ(PoC):
- 攻撃者は、被害者がアクセスする可能性のある外部サイト(ブログや掲示板)に、
タグやタグを仕込む。 - 被害者がそのサイトを訪れると、ブラウザはデフォルトの挙動として「直前のページのURL」を
Refererヘッダーに載せて送信する。 - もしURLに
https://internal-app.example.com/reset-password?token=a1b2c3d4...のような情報が含まれていれば、攻撃者は自ら運営するサーバーのアクセスログから、その機密情報を「盗み見」できる。
これが、我々が「Referer漏洩」を軽視できない理由だ。単なるXSS以上に、「情報が漏れていることに被害者も管理者も気づかない」という点が最も恐ろしい。
—
2. 防御の要:Referrer-Policyの実装
この攻撃を防ぐ鍵は、ブラウザに対して「どの範囲のReferer情報を送っていいか」を明確に指示することだ。これを制御するのが Referrer-Policy ヘッダーである。
推奨設定:strict-origin-when-cross-origin
現代のWeb開発において、最もバランスが良く推奨される設定は strict-origin-when-cross-origin だ。
- 同じドメイン内: 完全なURLを送る(利便性を維持)。
- 異なるドメイン(HTTPS→HTTPS): ドメイン情報のみを送る(パスやクエリは削る)。
- 安全でない通信(HTTPS→HTTP): Refererを送信しない。
—
3. 実務で使える実装サンプル
Webサーバーでの設定 (Nginx)
アプリケーションコードをいじる前に、まずはインフラ層で全ページに適用するのが鉄則だ。nginx.conf に以下を追記する。
全てのレスポンスにセキュリティヘッダーを付与
add_header Referrer-Policy “strict-origin-when-cross-origin” always;
add_header X-Content-Type-Options “nosniff” always;
add_header X-Frame-Options “SAMEORIGIN” always;
アプリケーションでの設定 (PHP Laravel)
Laravel等のフレームワークを使っているなら、ミドルウェアで動的に制御することも可能だ。
// app/Http/Middleware/SecureHeaders.php
public function handle($request, Closure $next)
{
$response = $next($request);
// Referer情報の漏洩を防ぐための厳格な設定
$response->headers->set(‘Referrer-Policy’, ‘strict-origin-when-cross-origin’);
return $response;
}
フロントエンドでの個別の防衛 (HTML/JS)
特定のリンク先だけに制限をかけたい場合は、HTMLタグで直接制御することもできる。
—
4. セキュリティチーフからの「最後の警告」
設定さえすれば完璧、とは言い切れない。現場のエンジニアが陥りやすい罠を二つだけ伝授しておく。
1. URLに機密情報を含めるな(最重要):
Referrer-Policyはあくまで「保険」だ。URLパラメータに token や secret を含める設計そのものがアンチパターンである。POSTリクエストで送るか、セッションストレージやメモリ内で保持する設計へリファクタリングする勇気を持て。
2. 古いブラウザの挙動:
Referrer-Policy をサポートしていない非常に古いブラウザも稀に存在する。その場合、サーバーサイドでRefererヘッダーをチェックし、怪しい場合はセッションを破棄するといった「多層防御」の考え方が、最後には自分たちの首を救うことになる。
技術は常にアップデートされる。だが、「攻撃者の視点に立ち、最悪の事態を想定して実装を絞り込む」という姿勢だけは、どんなに時代が変わっても変わらない。
今日紹介した設定は、明日からすぐに反映できるものばかりだ。君たちの手で、プロダクトの堅牢性を一段階引き上げてくれ。期待している。
コメント