問題タブ [csrf]

ユーザー名とパスワードを入力して HTMLUnit webClient を使用してフォームを投稿していますが、ログインできませんでした。調査したところ、投稿要求で csrf が有効になっていることがわかったので、ネイティブ Web ブラウザーが必要です。HTMLUnitまたはJavaの他のツールを使用してcsrf対応Webサイトにログイン(フォームを投稿)する方法はありますか?それとも不可能ですか?

デフォルトでは、Rails のフォーム ポスト CSRF 保護は、ユーザーのセッションが変更された場合にのみ変更されるユーザーの認証トークンを作成します。お客様の 1 人がサイトのセキュリティ監査を行い、問題としてフラグを立てました。

監査人の声明は、XSS の脆弱性もあれば、攻撃者が別のユーザーの認証トークンを取得し、ユーザーのセッションが期限切れになるまでそれを CSRF 攻撃に利用できるというものでした。

しかし、そのような XSS 脆弱性があれば、攻撃者は別のユーザーのセッション Cookie を簡単に取得して、そのユーザーとして直接ログインできるように思えます。または、攻撃されているユーザーとして、スクリプトから REST Api を呼び出すだけです。このような状況では、CSRF 攻撃を実行できることはそれほど悪いことではないように思われます...問題は XSS の脆弱性です。

私は何かを逃しましたか？Rails のデフォルトの CSRF 保護に実際の問題はありますか?

二重送信された Cookie の CSRF 防止スキームでは、サーバーが Cookie を提供する必要がありますか?

クライアントページでjavascriptを生成してCookie「anti_csrf」を設定し、それを2回送信することができるようです（1回はCookieとして、ブラウザによって行われ、1回はリクエストの本文で）。

外部ドメインは、「anti_csrf」Cookie を読み書きしてリクエストの本文に含めることができません。

これは安全ですか、それとも何かを見落としていますか?

誰かがSymfony1.4のフォームのCSRFトークンエラーメッセージをどこで/どのようにカスタマイズするか教えてもらえますか？ログインにsfDoctrineGuardを使用しています。特にこのフォームでは、セッションが終了してもページを開いたままにすると、「CSRF攻撃が検出されました」という非常にユーザーフレンドリーなエラーがスローされます。「このセッションは期限切れです。ホームページに戻ってもう一度やり直してください」のように聞こえます。

フォームクラスでこれを行う正しい方法は何ですか？

ありがとう。

2007 年と2010 年のOWASP トップ 10 リストを見ていきます。

私はクロス サイト リクエスト フォージェリ (CSRF) に出くわしました。

これに対する解決策は、すべての URL にトークンを追加することであり、このトークンはすべてのリンクに対してチェックされます。

たとえば、製品 x に投票する場合、URL は次のようになります。

ハッカーはトークンを推測できないため、これは確実な解決策のように見えます。

しかし、私は次のシナリオを考えていました（それが可能かどうかはわかりません）：

非表示の iFrame または div を使用して Web サイトを作成します。その後、通常の iFrame または ajax を使用して、私の Web サイトを読み込むことができます。

自分の Web サイトを Web サイト内に隠してロードし、ユーザーがセッションを保存している場合、次のことができます。URLS からトークンを取得し、必要なすべてのアクションを実行できます。

このようなことは可能ですか？または、このクロスドメインを行うことはできませんか。

「チャレンジトークン」を使用すると、どのような種類の予防策が追加されるのかわかりません。どの値を何と比較する必要がありますか？

OWASPから：

一般に、開発者は現在のセッションでこのトークンを1回だけ生成する必要があります。このトークンの最初の生成後、値はセッションに保存され、セッションが期限切れになるまで後続の各要求に使用されます。

プロセスを正しく理解していれば、これが起こります。

http://example.comにログインすると、このランダムトークンを含むセッション/Cookieが作成されます。次に、すべてのフォームには、フォーム送信時にセッション/ Cookieと比較される、セッションからのこのランダムな値も含む非表示の入力が含まれます。

しかし、それは何を達成しますか？セッションデータを取得してページに配置し、まったく同じセッションデータと比較するだけではありませんか？循環論法のようです。これらの記事では、「同一生成元ポリシー」に従うことについて話し続けていますが、すべてのCSRF攻撃はユーザーと同じ起源であり、ユーザーをだまして意図しないアクションを実行させるため、意味がありません。

トークンをすべてのURLにクエリ文字列として追加する以外の方法はありますか？非常に醜くて実用的ではないようで、ユーザーにとってブックマークが難しくなります。

更新：GWT 2.3は、XSRF攻撃と戦うためのより優れたメカニズムを導入しています。http://code.google.com/webtoolkit/doc/latest/DevGuideSecurityRpcXsrf.htmlを参照してください

GWTのRPCメカニズムは、すべてのHTTPリクエストで次のことを行います-

1. 2つのカスタムリクエストヘッダー（X-GWT-PermutationとX-GWT-Module-Base）を設定します
2. コンテンツタイプをtext/x-gwt-rpcとして設定します。charset = utf-8

HTTPリクエストは常にPOSTであり、サーバー側ではGETメソッドが例外をスローします（メソッドはサポートされていません）。

また、これらのヘッダーが設定されていないか、値が間違っている場合、サーバーは「おそらくCSRF？」という例外を除いて処理に失敗します。またはその効果のために何か。

質問は：これはCSRFを防ぐのに十分ですか？純粋なクロスサイトリクエストフォージェリメソッドでカスタムヘッダーを設定し、コンテンツタイプを変更する方法はありますか？

ここ数日で CSRF 攻撃を防ぐ方法について読みました。ページロードごとにトークンを更新し、トークンをセッションに保存し、フォームを送信するときにチェックを行います。

しかし、ユーザーが自分の Web サイトで 3 つのタブを開いて、セッションの最後のトークンを保存したとしたらどうなるでしょうか? これにより、トークンが別のトークンで上書きされ、一部の事後アクションが失敗します。

セッションにすべてのトークンを保存する必要がありますか、それともこれを機能させるためのより良い解決策はありますか?

コードのXSRF修正を行っています。これを実現するために、セッショントークンを使用してトークン比較メソッドを要求しています。セッショントークンがリクエストトークンと等しくない場合は、エラーページにリダイレクトされます。

問題：メインメニューページに移動した後、ユーザーがページを「更新」すると、XSRFの問題が発生します。 理由：リクエストトークンがないため（ページの更新を行う場合）。リクエストトークンがNULLであり、セッショントークンと等しくないため、XSRFエラーがスローされていました。

アプリケーションのユーザーは、このアプローチにあまり満足していません。では、ページの更新を有効にする方法はありますか？または、（セキュリティのために）ページの更新を無効にすることが絶対に必要/重要ですか？

前もって感謝します。

最近、ソリューションを MVC 2 に更新しました。これにより、AntiForgeryToken動作が更新されました。残念ながら、これはもはや AJAX フレームワークには適合しません。

Name問題は、MVC 2 が対称暗号化を使用して、ユーザーのプロパティ (から)を含む、ユーザーに関する一部のプロパティをエンコードすることIPrincipalです。AJAX を使用して新しいユーザーを安全に登録できます。その後、ユーザーに新しいプリンシパルが付与されると偽造防止トークンが変更されるため、その後の AJAX 呼び出しは無効になります。ユーザーが自分の名前を更新するなど、これが発生する可能性がある他のケースもあります。

私の主な質問は、なぜ MVC 2 がわざわざ対称暗号化を使用するのかということです。では、プリンシパルのユーザー名プロパティを気にするのはなぜでしょうか?

私の理解が正しければ、ランダムな共有シークレットで十分です。基本的な原則は、特定のデータ (HttpOnly!) を含む Cookie がユーザーに送信されることです。この Cookie は、副作用 (通常は POST) を持つ可能性のある各要求で返されるフォーム変数と一致するために必要です。これはクロスサイト攻撃から保護することのみを目的としているため、テストに簡単に合格する応答を簡単に作成できますが、それは Cookie に完全にアクセスできる場合に限られます。クロスサイト攻撃者はユーザー Cookie にアクセスできないため、保護されます。

対称暗号化を使用することで、Cookie の内容を確認する利点は何ですか? つまり、既に HttpOnly Cookie を送信している場合、攻撃者は (ブラウザに重大なセキュリティ上の問題がない限り) それを上書きすることはできません。

考えてみると、これは「追加されたセキュリティ層」のケースの 1 つであるように見えますが、防御の第 1 ラインが落ちた場合 (HttpOnly)、攻撃者は完全なアクセス権を持っているため、とにかく第 2 層を通り抜けようとしています。間接的な XSS/CSRF 攻撃を使用する代わりに、ユーザーの Cookie コレクションに直接なりすますことができます。

もちろん、大きな問題を見落としている可能性もありますが、まだ見つかっていません。ここで明らかな問題または微妙な問題が発生している場合は、それらに注意したいと思います。