CSRF攻撃中にRefererヘッダーを偽装することはどのようにできませんか？

Question

CSRF攻撃に対するアプリケーションの唯一の防御は、同一起点のリファラーヘッダをチェックすることであるとします。また、すべてのブラウザがリファラーヘッダーを送信するとします（必ずしもそうではありませんが）。

ユーザーが自分のリファラーヘッダーをスプーフィングするのは簡単ですが、CSRF攻撃者が同じことを行うにはIMPOSSIBLEだと読んでいます。

1.）あなたはどのようにリファラーヘッダを偽装していますか？ （注：リーダヘッダーはプログラムによってmodifiedになることはできません）

2.）なぜCSRF攻撃者はそれを実行できませんか？

Answer 1

独自のブラウザのリファラーヘッダーをスプーフィングすることは、プログラムでは変更できないとしても、簡単です。このトリックは、ブラウザがサーバーに送信した後、サーバーに到達する前に要求をインターセプトすることです。

これは、Burp Suiteのような代行受信プロキシを使用して簡単に行うことができます。基本的には、ローカル代行プロキシーをプロキシー・サーバーとして使用するようにブラウザーに指示します。ブラウザはローカルプロキシに要求を行います。ローカルプロキシはリクエストを有効に保ち、参照元ヘッダーを含め、HTTPテキストで必要なものを変更することができます。準備が整ったら、リクエストをリリースするだけで、ローカルプロキシがそれを送信します。簡単なピーシー。

また、あなたのウェブサイトでTLSを使用しない場合、途中のホップが潜在的に悪い可能性があり、要望に応じてリクエスト/レスポンスを変更する可能性があることにも注意してください。途中で数多くのホップを理解するには、tracerouteを試すことができます（ただし、ルータによってはtracerouteツールを動作させるパケットがドロップされるため、信頼できる測定ではありません）。

しかし、純粋なCSRF攻撃の場合、攻撃者は被害者のブラウザを制御できません。これは、被害者のブラウザがWebサーバーに直接リクエストを行い、常にそうであるように正しい参照元ヘッダーを送信することを意味します。これは、リフェラルヘッダーが簡単に偽装されているため一般的には恐ろしいセキュリティ方法ですが、犠牲者の参照ヘッダーを変更することは不可能です。

つまり、CSRFと戦うための最良の解決策は、CSRFトークンを使用することです。 OWASP recommends using the origin header and a CSRF token。

うまくいけば、これが役に立ちます。そうでない場合は、私のコメントで私に教えてくださいと私は明確にしようとします。