authentication_tokenRailsは、サイトによって生成されたすべてのフォームにを追加することにより、デフォルトですべてのフォームにCSRF保護を自動的に追加します。
私のサイトでは、サイトのフロントページに簡単なサインアップフォームを配置したいと思っています。もちろん、これは静的なHTMLページになります。これにより、理想的にはRailsスタックにヒットすることをまったく回避し、フロントページにはるかに多くのリクエストを処理できるようになります。
これの欠点は、CSRF保護がより困難になることです。
しかし、CSRF攻撃は通常、信頼を利用できるようにログインしている被害者に依存していることを考えると、サインアップフォームにCSRF保護を設定することが本当に必要かどうか疑問に思います。サインアップフォームは、正しく検証されればユーザーをログインさせますが、それが攻撃者にとって何の役にも立たないと思います。
これまたはRails/jQueryを使用した回避策について確立された見解はありますか？
いいえ、この特定の状況ではありません。CSRF攻撃により、攻撃者は被害者が持つ権利を悪用することができます。bank.com/pay?ammount=1000&to=34.67.978.246
ログインフィールドへの攻撃を成功させるために必要な情報（ユーザー名とパスワード）を持っている場合、攻撃者は自分でログインできるため、ログインフォームを攻撃することは意味がありません。
RailsがログインフィールドでCSRF保護を使用する理由は単純です。フィールドの95％よりもグローバルにCSRF保護を実装する方がはるかに簡単です;）
まず、CSRFが実際に何であるかを明確にする必要があります。
クロスサイトリクエストフォージェリ は、Webサイトの悪用の一種であり、Webサイトが信頼するユーザーから不正なコマンドが送信されます。
次の例を考えてみましょう。ハッカーは、あなたがwww.example.comにアカウントを持っていることを知っており、それがあなたがログインしていて有効なセッションを実行しているWebサイトであるとしましょう。これで、ハッカーはあなたを別のWebサイト、たとえばtrustme.comを開くように誘惑することができます。このWebサイトに、次のコードを含む画像を投稿しました。
<img src="http://www.example.com/users/delete"/>
www.example.comのプログラマーが、単純なGETリクエストでそのURLを介してアカウントを削除することを実際に可能にし、ハッカーがその画像を表示して有効なCookieをロードするだけで、example.comのアカウントが削除されることを知っている場合、あなたはtrustme.comをサーフィンしているだけで、これら2つのサイトは互いに関係がないように見えましたが。
この例を要約すると、CSRFは、サイトがユーザーのブラウザーに対して持っている信頼、この場合はwww.example.comがブラウザーに対して持っている信頼を利用します。
あなたのケースにそのアナロジーを使用することは、ユーザーのブラウザであなたのサイトの信頼を利用することを意味します-しかし、ユーザーがあなたのフォームを見たときにまだログインしていないので、その信頼はまだ確立されていません。ただし、すでにログインしてそのフォームでページを再度読み込もうとすると、確立された信頼が悪用される可能性があるため、ユーザーがリダイレクトされることを確認する必要があります。
したがって、経験則として、ユーザーの検証要求にCookieとセッションを使用する場合、つまりユーザーの信頼を確認または確立する場合は常に、CSRF保護を使用してください。ユーザーがサインアップするときにユーザーの信頼を確立したいので、同じことが当てはまります。
残念ながら、CSRF攻撃はそれだけに限定されていません。私は起こり得る他の2つのことについて知りました（そしてそれは確かにそれに限定されません）：
1 .:以下は、ログインフォームのCSRF保護を省略したことで可能になった、アカウントのスパイの気の利いた例です。
2 .: CSRF保護がない場合、ハッカーは自分のhtmlドキュメントでログインまたはサインアップフォームを模倣し、信頼できるサイトがリクエストに気付かずに何度も何度も送信できる（またはターミナルからcurlを使用して送信する）ことができます。実際にはそれ自体から取得されます。つまり、信頼されたドメインの実際のログインフォームは、ブラウザに表示されておらず、そこから送信されていません。これにより、彼はブルートフォース攻撃をはるかに簡単に実行できます。悪意のあるユーザーが資格情報の検索に成功した場合、サーバーは有効なセッションCookieで応答し、そのユーザーを信頼します。これにより、ユーザーはIDを盗みます。サインアップフォームの場合、彼は大量のアカウントにサインアップして、データベースにスパムを送信することができます。
これを要約すると、CSRF保護を使用します。悪意のあるユーザーは、セキュリティで保護されていないログインおよびサインアップフォームを使用して、サイトを悪用したり、ユーザーをスパイしたり、ユーザーのIDを盗んだりする可能性があります。
詳細については、この同様の質問（ログインフォーム用）およびこの学術論文も参照してください。後者には、3ページのログインCSRFに関する専用の章があります。また、このCSRF防止に関するチートシートも確認してください。
CSRF保護では、セッションを使用してサーバー側で生成されたトークンとフォームから送信されたトークンを比較するため、これをクライアント側でのみ行う方法、つまりRailsスタックにアクセスしない方法は考えられません。重要なのは、クライアントがトークンを受け取るのは、サーバー側で生成された後だけであるということです。
サインアップフォームからcsrfを心配する技術的な理由はほとんどないように思われます。攻撃者は誰かをだましてあなたのサイトに新しいアカウントを作成させる可能性があります-被害者があなたのサイトを使用した場合、攻撃者はアカウントにもアクセスできるため、彼らの行動をスパイする可能性がありますか？
より可能性の高いリスクは、おそらく非技術的です。サイトがセキュリティ監査を受けるとき、csrfがここでリスクではない理由を説明する必要があります...そしてネガティブを証明するのは難しいです... "Appscanはこれを重大なセキュリティホールとしてフラグを立てました-なぜあなたはそうしませんか？修正しますか？チャールズのようなきれいなレポートを作成できないのはなぜですか？」:)
フロントページをキャッシュしたいが、CSRF保護を維持したい場合（チャールズが言ったように、これはおそらく良い考えです）、ページがロードされたら、Javascriptを介して適切な認証トークンを挿入できます。
これに関する情報は、http： //broadcastingadam.com/2011/05/advanced_caching_in_rails/の「CSRFandform_authenticty_token」ヘッダーの下にあります。関連するコードは次のとおりです。
$("meta[name='csrf-token']").attr('content', '<% Rack::Utils.escape_html(request_forgery_protection_token) %>');
$("meta[name='csrf-param']").attr('content', '<% Rack::Utils.escape_html(form_authenticity_token) %>');
この手法を使用すると、すべてのクライアントがこの認証トークンを取得するための追加の（ただし非常に小さく、迅速な）要求を行うことを犠牲にして、ホームページ全体をキャッシュできます。
一般的に言えば、CSRF攻撃から登録フォームを保護することをお勧めします。Google検索を検討し、ログインフォームはCSRFから保護されているが、登録フォームは脆弱であると想定します。攻撃者は、攻撃者が知っている資格情報を使用して新しいアカウントを登録するように被害者に強制できます。その瞬間から、被害者は被害者のアカウントにログインするための資格情報を知っているため、被害者はどの検索でも攻撃者に表示されます。これは、脆弱なサイトが登録後すぐにユーザーにログインすることを前提としています。
電子メールプロバイダーを使用する他のシナリオは、スパム目的のアカウントを作成することです。攻撃者は、被害者に登録フォームにCSRFを使用して新しいアカウントを作成させ、それらのアカウントを使用してスパムを送信する可能性があります。アイデアは、IPまたは国に基づいてアカウントの作成を抑制するセキュリティメカニズムを打ち負かすことです。
ただし、特定のシナリオでは、脆弱な登録フォームを利用できない場合がありますが、この種の分析は、対象の専門家でない人にとっては難しい場合があります。フォームを保護することをお勧めしますが、攻撃を成功させるシナリオは多くないため、通常はリスクが低くなります。
はい、他のウェブサイトはあなたのサインアップフォームを模倣することはできません！それと同じくらい簡単です。
彼らはそれをすることによって何を達成することができますか？