2

Rails アプリでエンドポイントの CSRF トークン チェックを無効にできれば、より優れたユーザー エクスペリエンスを提供できる状況に陥っています。

エンドポイントは、 deviseフィルターの背後にあるcreate( によってルーティングされる) アクションです。POST /whatever:authenticate!

before_filterその特定のエンドポイントの CSRF 保護を無効にすることで、追加のセキュリティ リスクにさらされることになるでしょうか。それとも、CSRF トークンが保護する種類の悪意のある要求を停止するために、認証に安全に頼ることができるでしょうか?


以下は、誰かが興味を持っている場合になぜこれをやりたいのかについて、もう少し詳細な説明です。

私の使用例は、基本的に Facebook のいいねボタンに非常に似たものを作成したいということですが、このボタンは (Facebook の同等のボタンとは異なり) 通常、同じページに複数回表示されます。

CSRF 保護は、ユーザーが空の Cookie を使用してページにアクセスした場合を除いて、正常に機能します。

この場合、Rails は X 個のリクエストごとに新しいセッションを生成します。これらはすべて Cookie を使用しないためです。そしてもちろん、新しいセッションごとに新しい CSRF トークンが生成され、iframe への応答で返されます。

ブラウザーはドメインに対して 1 つの Cookie のみを保持するため、各 iframe からの後続の要求はすべて同じセッションにマップされ、すべての CSRF トークン (1 つを除く) が無効になります。

ユーザーは一度ログインするように求められ、その後ボタンを押すたびに同じログインにマッピングされるため、単一のセッションへのマッピングは便利です。ページをリロードする必要はありません。

妥協案は で応答すること401 Unauthorizedですが、拒否されたリクエストのセッションを保持します ( をオーバーライドすることによりhandle_unverified_request)。これにより、サインイン ポップアップが再度トリガーされますが、今回は、ユーザーが既にサインインしているため、インスタント リダイレクトが発生します。

createもちろん、サインインポップアップウィンドウの点滅を避けるのが最善であるため、CSRF保護をアクションだけですべて無効にしたいと思います。

4

1 に答える 1

10

認証されたリクエストは、まさに CSRF の目的です。

CSRF が意味することは、攻撃者がユーザーのブラウザにリクエストを行うよう説得することです。たとえば、次のようなフォームを持つ攻撃者がホストするページにアクセスしたとします。

<form action="http://www.yourapp.com/some_action">
  #for parameters here
</action>

そして、フォームを自動送信するページ上のJavaScript。ユーザーがすでにアプリにログインしている場合、このリクエストは Cookie ベースの認証チェックに合格します。ただし、攻撃者は csrf トークンを知りません。

認証されていないリクエストの場合、csrf は何の役にも立ちません。攻撃者はとにかく先に進んでリクエストを行うことができます。被害者の資格情報をハイジャックする必要はありません。

したがって、短いバージョン: csrf 保護を無効にすると、csrf スタイルの攻撃に対して脆弱になります。

CSRF の本当の目的は、攻撃者が偽造できないパラメーターがフォームに含まれていることを確認することです。セッションはそのような値を保存する簡単な場所ですが、代替案を考え出すことができると思います. たとえば、ユーザーがフォーム内のパラメーターを制御できない場合は、フォーム内の他のすべてのパラメーターの署名となる別のパラメーターを追加できます (リプレイ攻撃を防ぐために、何らかのタイムスタンプまたは nonce を使用する可能性があります)。リクエストを受信すると、署名を確認することで、そのリクエストが生成したフォームからのものかどうかを判断できます。

間違えやすいので、この種のものには十分に注意してください（そして、大物でも時々間違えます.

于 2012-05-18T12:49:07.273 に答える