CSRF保護に関する多くの記事(これは良いものです)とSOに関するさまざまな質問を読んだことがありますが、どれも私の質問に答えるのに十分な情報を提供していないようです。
私は独自のCMSを開発しており、ログインフォームとコメントフォームを保護したいと考えています。匿名ユーザーが私のウェブサイトにコメントできるようにします。
私のウェブサイト上のすべてのフォームは、トークンを使用して保護されています。そのアプローチについてはすでに知っていますが、問題は、アクティブなセッションが必要なことです(つまり、ユーザーがログインした後)。ログインフォームとコメントフォームの問題は、ほぼすべての人がアクセスでき、ログインする必要がないことです。この場合、CSRFに対する最善の保護は何でしょうか。
上記のリンクで、ユーザーがログインしようとしたときに「プレセッション」を作成して、通常のアンチCSRFメソッド(ユーザーのセッションにトークンを割り当てるなど)に進むことができる可能性があることを読みましたが、私はこれを達成する方法についての洞察はありません。
リファラーヘッダーは弱い解決策なので、気にしないでください。Originヘッダーは、私がテストした限り、GoogleChromeでのみサポートされています。カスタムヘッダーはどうですか?XMLHTTPRequestは可能性のように思えますが、私は文字通り3時間以上Googleで、そのようなセキュリティ対策をWebサイトに実装する方法に関する情報を調べてきました。しかし、カスタムヘッダーを使用できたとしても、HTTPヘッダーは完全に偽造される可能性があるため、役に立たないのではないでしょうか。
それで、質問:ログインフォームとコメントフォームをCSRFからどのように保護する必要がありますか?
編集:ここに私が上で提供したリンクからのいくつかの追加情報があります:
ログインフォームは通常HTTPS経由で送信されるため、ログインCSRFから保護するために、厳密なリファラー検証をお勧めします。この場合、リファラーヘッダーは正当な要求に対して確実に存在します。ログインリクエストにリファラーヘッダーがない場合、サイトは悪意のある抑制から防御するためにリクエストを拒否する必要があります。
と
シークレット検証トークンはログインCSRFに対して防御できますが、ログイン前にCSRFトークンをバインドするセッションがないため、開発者は防御の実装を忘れることがよくあります。シークレット検証トークンを使用してログインCSRFから保護するには、サイトは最初に「プレセッション」を作成し、トークンベースのCSRF保護を実装し、認証が成功した後に実際のセッションに移行する必要があります。
上記の引用を読んだ後、私はこの議論に終止符を打つことができません。そのうちの1つは、リファラーヘッダーの使用について言及していますが、それがWebアプリのセキュリティに本当に大きな効果をもたらすかどうかはよくわかりません。
編集2: CAPTCHAの使用はどうですか?