問題タブ [csrf]

何か案は？デスクトップブラウザからアクセスする場合は問題ありません。

Spring WebFlow 2でビルドされたアプリケーションにCSRF保護を追加する（うまくいけば簡単な）方法を探しています。

Spring WebFlow 3（リリースされた場合）に適切に移行するアプローチが推奨されます。

私はクロスサイト認証に取り組んでいます（一部のドメインは共通の認証を取得しています）。そこで、認証データ（ログイン、パスワード）を他からメインドメインに送りたい。

どのように使用すればよい protect_from_forgeryですか?また、有効なドメインからデータを受信したかどうかを確認するにはどうすればよいですか?

今考えているのはprotect_from_forgery、セッションコントローラーをオフにして、受信データのドメイン名を確認することです。

しかし、1 つのドメインだけでなく、CSRF 保護を構成することはできますか?

アプリを構築するとき、フォームへの攻撃を防ぐためにトークンを使用します

フォームがレンダリングされるたびに、フォームに非表示フィールドとして含める新しいONETIMEセキュリティトークンを取得します。このトークンもセッションに保存されます。

フォームが送信されると、トークンはセッション内のトークンと照合され、フォームが正当であることを確認します。これは、標準のページに最適です。

問題 Ajaxを使用してフォームを送信する場合、ページに複数のフォームが存在する可能性があります。これらのフォームの1つを送信すると、トークンは1回限りのトークンとして他のフォームに対して無効になります。

誰かがこれについてアドバイスしていますか？または、セッションごとに1つのトークンを生成し、フォームが送信されるたびにトークンを無効にする代わりにそれを使用するのに十分な安全性がありますか？

そのため、フォームをもう少し安全にし、CSRF 攻撃を防ぐのに役立つ可能性があるため、非表示フィールドにランダムなトークン値を追加し、その値がサーバー側のセッション データにも保存されるようにしたいと考えています。

新しいトークンはいつ発行する必要がありますか? 実行？フォームがあるページの読み込みごとに? セッションごと？フォームが正常に送信されるとすぐに無効にすることができますが、いつフォームを生成するのか疑問に思っています。

フォームごとまたはページごとに発行する場合、ユーザーが別のウィンドウを開いて最初のフォームを送信した場合に、重複したトークン値が既存の (有効な) トークンを上書きする可能性はありませんか?

Google App Engine で実行する GWT アプリを開発していますが、クロスサイト リクエスト フォージェリについて心配する必要があるのか​​、それとも自動的に処理されるのでしょうか?

認証を必要とするすべての RPC リクエストに対して、次のコードを用意しました。

UserServiceが認証をチェックする方法に関するドキュメントが見つかりませんでした。上記のコードに頼るだけで十分ですか、それとももっと頼る必要がありますか? 私はこれの初心者ですが、CSRF攻撃を回避するために私が理解していることから、いくつかの戦略は次のとおりです。

1. Cookie をチェックするだけでなく、リクエスト ペイロードに認証トークンを追加する
2. HTTP Referer ヘッダーの確認

SID 値のように見える Google からの Cookie が設定されていることはわかりますが、ペイロード内のシリアル化された Java オブジェクトからは、トークンが渡されているかどうかを判断できません。また、Referer ヘッダーが使用されているかどうかもわかりません。

それで、私は問題がないことを心配していますか？そうでない場合、ここでの最善の戦略は何ですか? これは十分に一般的な問題であり、標準的な解決策が存在する必要があります...

Django 1.2にアップグレードしたばかりで、プロジェクトを実行しようとしています。ログインした後、

以前にCSRF保護を有効にしたことがないので、これは奇妙です。プロジェクトを機能させるために何か他のものを構成する必要がありますか？

ディレクティブでSaltパラメーターを使用する ASP.NET MVC アプリケーションを考えてみましょう。[ValidateAntiForgeryToken]

シナリオは、アプリが多くの顧客によって使用されるようなものです。Saltコンパイル時に既知であることはあまり望ましくありません。

現在の戦略は、web.config でソルト値を見つけることです。

Saltこれにより、コンパイル時に const でなければならないことを示すコンパイル時の例外が発生します。

属性引数は、定数式、typeof 式、または属性パラメーター タイプの配列作成式でなければなりません

Salt顧客ごとにアプリを再ソルトして再コンパイルする必要がないように、アプリケーションを変更して実行時にロードできるようにするにはどうすればよいですか?

Saltが頻繁に変更されることはないと考えてください。これにより、フォームが無効になる可能性がなくなります

CSRF防止を追加する必要があるコードを継承し、struts2tokenSessionインターセプターを使用してこれを実行しようとしています。次のようにstruts2トークンタグを使用してフォームにトークンを追加しています。

私のjavascript関数では、いくつかの検証ルールを追加/削除しています（必要なアクションに応じて、フォームを送信します：

リクエストをインターセプトし、トークンを追加していますが、struts2tokenSessionインターセプターがinvalid.tokenを返しています。このインターセプターがなくても、コードは期待どおりに機能します。（struts2 xmlファイルは投稿されていません-必要に応じて関連するセクションを投稿します）。また、基本的なhtml送信ボタンを使用する（つまり、javascriptまたはjqueryを経由しない）他のページでtokenSessionインターセプターを使用しましたが、これも期待どおりに機能します。トークンを無効にしているのは何ですか？

注意：私が継承したプロジェクトでは、標準のhtml、struts2タグ、ExtJS、JQueryの奇妙な組み合わせを使用しています。いつかこれをクリーンアップしますが、現時点では、tokenSessionインターセプターをコード内でできるだけ早く機能させる必要があります（数百ページに同様の修正を適用する必要があるため...）。

ヘルプ/ポインタ/ヒントなどは大歓迎です！

よろしく、

ジョン

サイトからのすべてのAJAXPOSTリクエストがauthenticity_tokenなしで通過できるようにする規定はレールにありますか？

コントローラメソッドを呼び出すJqueryPOSTajax呼び出しがありますが、認証コードを入れていませんが、呼び出しは成功します。

私のApplicationControllerには「request_forgery_protection」があり、変更しました

私のenvironments/development.rbでfalseに

また、コードを検索して、真正性トークンを送信するためにajaxSendをオーバーロードしていないことを確認しました。

チェックを無効にするメカニズムはありますか？現在、CSRF保護が機能しているかどうかはわかりません。

Rails2.3.5を使用しています。

明確にするための更新：

上記の関数を呼び出す'hrefを持つリンクがあります。