6

CSRF保護に関する多くの記事（これは良いものです）とSOに関するさまざまな質問を読んだことがありますが、どれも私の質問に答えるのに十分な情報を提供していないようです。

私は独自のCMSを開発しており、ログインフォームとコメントフォームを保護したいと考えています。匿名ユーザーが私のウェブサイトにコメントできるようにします。

私のウェブサイト上のすべてのフォームは、トークンを使用して保護されています。そのアプローチについてはすでに知っていますが、問題は、アクティブなセッションが必要なことです（つまり、ユーザーがログインした後）。ログインフォームとコメントフォームの問題は、ほぼすべての人がアクセスでき、ログインする必要がないことです。この場合、CSRFに対する最善の保護は何でしょうか。

上記のリンクで、ユーザーがログインしようとしたときに「プレセッション」を作成して、通常のアンチCSRFメソッド（ユーザーのセッションにトークンを割り当てるなど）に進むことができる可能性があることを読みましたが、私はこれを達成する方法についての洞察はありません。

リファラーヘッダーは弱い解決策なので、気にしないでください。Originヘッダーは、私がテストした限り、GoogleChromeでのみサポートされています。カスタムヘッダーはどうですか？XMLHTTPRequestは可能性のように思えますが、私は文字通り3時間以上Googleで、そのようなセキュリティ対策をWebサイトに実装する方法に関する情報を調べてきました。しかし、カスタムヘッダーを使用できたとしても、HTTPヘッダーは完全に偽造される可能性があるため、役に立たないのではないでしょうか。

それで、質問：ログインフォームとコメントフォームをCSRFからどのように保護する必要がありますか？

編集：ここに私が上で提供したリンクからのいくつかの追加情報があります：

ログインフォームは通常HTTPS経由で送信されるため、ログインCSRFから保護するために、厳密なリファラー検証をお勧めします。この場合、リファラーヘッダーは正当な要求に対して確実に存在します。ログインリクエストにリファラーヘッダーがない場合、サイトは悪意のある抑制から防御するためにリクエストを拒否する必要があります。

と

シークレット検証トークンはログインCSRFに対して防御できますが、ログイン前にCSRFトークンをバインドするセッションがないため、開発者は防御の実装を忘れることがよくあります。シークレット検証トークンを使用してログインCSRFから保護するには、サイトは最初に「プレセッション」を作成し、トークンベースのCSRF保護を実装し、認証が成功した後に実際のセッションに移行する必要があります。

上記の引用を読んだ後、私はこの議論に終止符を打つことができません。そのうちの1つは、リファラーヘッダーの使用について言及していますが、それがWebアプリのセキュリティに本当に大きな効果をもたらすかどうかはよくわかりません。

編集2： CAPTCHAの使用はどうですか？

4

4 に答える 4

3

CSRFの問題は、ログインしたユーザーのクレデンシャルを使用して何かを送信する人に関連しています。悪意のあるサイトは、あなたのサイトを閲覧したばかりの人と同じように何かをする可能性があるため、これは非常に問題があります。ログインせずに匿名で使用できるフォームについて話している場合、別のサイトからフォームに投稿することで得られる利益が大幅に少ないため、CSRFのリスクがはるかに少なくなります。誰でも同じ権限で直接行うことができるためです。 。

そのため、ログインしていないフォームのCSRFから保護する必要がある理由がわかりません。

これが必要な場合は、セッション前のトークンは技術的には実際のセッションに似ていますが、より軽量なトークンです。生成されたトークン以外は実際には含まれません。

編集：セッション前トークンにPHPが提供する$ _SESSIONの使用について、これはPHPの標準セッションメカニズムです。あなたがそれを使いたいのなら、そうです、それはそれについてです。

ただし、そのようにする必要はありません。個人的には、すべての訪問者のサーバーメモリを消費するため、このようにする必要はありません。実際には必要ありません。より効率的なメカニズムを実現するには、基本的にa）ユーザーを識別するCookieと、b）Cookieが有効であることを示すサーバー側に保存されているもの（および必要に応じて、誰に対して有効であるか、つまりIPを意味する）が必要です。より軽量なアプローチの場合は、トークンを作成してCookieに保存し、そのトークンに一致するものを非表示フィールドとしてフォームに生成し、送信時に一致させることができます（Deveshによる説明のように）。後者は別のサイトからのフォームの送信を防ぎ、前者は悪意のあるサイトがあなたのサイトを検索し、エンドユーザーにCookieを設定しようとする場合でも防ぎます。だから私が考えることができる3つのアプローチ：

  • 他のサイトからの画像リクエストを防ぐだけです-POSTを使用するとこれを防ぐことができます
  • 別のサイトからのフォーム送信を防止します-Cookieに一致するフォームの非表示フィールドがこれを防止します
  • サイトで事前検索を行う別のサイトからのフォーム送信を防止します。これには、IP検証が必要になります。これは、Cookieに一致するデータベースのIPなど、サーバー側に保存されているものです。

EDIT2：キャプチャでは、主な使用例は、自動化された（ブルートフォース）ログイン試行を防ぐことです。ログインフォームでのCSRFリクエストの問題も修正されますが、それはやり過ぎです。ブルートフォースログイン攻撃を防ぐために、場合によってはそれらが必要になることがありますが、使いやすさをあまり低下させないために、よりユーザーフレンドリーなものが必要になる場合があります。たぶんKittenAuthのようなもの:)

于 2013-03-26T08:56:12.593 に答える
0

匿名フォームをCSRFから実際に保護することはできません。他のサイトが通常のユーザーとして機能できるという理由だけで。匿名フォームへのリクエストを実行するサイトを作成しcurl、Cookieとトークンを変数に格納するだけです。次に、フォームを投稿するための2番目のリクエストを行います。スクリプトは実際にはリクエストを偽造していませんが、自動的に投稿しているだけです。

CSRFのポイントは、スクリプト/人が別のユーザーに代わってアクションを実行するのを防ぐことです。だから私はあなたとして投稿しようとしています。トークンを使用したセッション/Cookieのアプローチが適切な解決策であることを防ぐため。あなたのサイトが他の領域で欠陥がない限り、私はあなたのセッションとトークンを取得する方法がないからです。OWASPガイドラインを読んで、何に注意を払うべきかについてのアイデアを得ることをお勧めします。

常に行うべきもう1つのことは、「アクション」が常にリクエストに応じて行われるようにすることです。これにより、「 http://www.yoursite.com/delete.php?id=10POST 」にリンクする画像をフォーラムに簡単に配置することはできません。リクエストを許可し、この画像を含むページを開くと、リクエストを偽造したことになります。許可するだけでは結果はありません。GETPOST

于 2013-03-26T08:55:53.177 に答える
0

フォームに追加された非表示フィールドを組み合わせて、同時にCookieに同じ値を追加し、ユーザーの応答に添付することで、CSRFのような問題に取り組むことができると思います。ユーザーがフォームをポストバックするときに、リクエストからの非表示フィールドの値とCookieの値を一致させようとします。両方が一致している場合は、問題ありません...

于 2013-03-26T09:00:59.353 に答える
0

CSRFの問題は、ログインしたユーザーのクレデンシャルを使用して何かを送信している人に関連しています。悪意のあるサイトは、あなたのサイトを閲覧したばかりの人と同じように何かをする可能性があるため、これは非常に問題があります。ログインせずに匿名で使用できるフォームについて話している場合、別のサイトからフォームに投稿することで得られる利益が大幅に少ないため、CSRFのリスクがはるかに少なくなります。誰でも同じ権限で直接行うことができるためです。 。

そのため、ログインしていないフォームのCSRFから保護する必要がある理由がわかりません。

これが必要な場合は、セッション前のトークンは技術的には実際のセッションに似ていますが、より軽量なトークンです。生成されたトークン以外は実際には含まれません。

于 2014-07-05T18:07:02.590 に答える