0

これが必要かどうかはわかりませんが、ログイン フォームに csrf トークンが表示されません。通常、フォームを作成するときにform_rest(form)最後に追加すると、csrf トークンが追加されます。しかし、ログイン フォームは別の方法で処理されます。実際にはフォーム オブジェクトではなく、自動魔法のようなものです。docsでそれを見ることができます。

それでどうしたの？ログインフォームに csrf 保護がないのはなぜですか? CSRF 攻撃は認証されたユーザー向けであることは知っていますが、Sf2 の匿名ユーザーは技術的に認証されています (セッション Cookie を参照)。確定メンバー。

何かご意見は？

4

2 に答える 2

3

ログインフォームでは CSRF 保護は必要ありません。

CSRF の定義: 攻撃者は被害者に HTTP リクエストをサーバーに送信させることができます。

典型的な教科書の例: 送金を開始する。攻撃者は次のようなリクエストを強制できます: http://bank.example.com/withdraw?account=Alice&amount=1000000&for=Eve

ご覧のとおり、攻撃者は事前に URL を作成する必要があります。

ログイン リクエストの場合、攻撃者はhttp://example.com/login?user=pierre.ernst&pwd=secretのような URL を作成する必要があるため、意味がありません。

攻撃者がこの情報 (資格情報) をすでに持っている場合、攻撃者は CSRF を試行しない可能性があります :-)

それが役立つことを願っています。

于 2012-12-04T16:10:36.180 に答える
0

実際にform_rest(form)は、CSRF トークンをスローするだけでなく、この関数はまだレンダリングされていないフォーム行をすべて出力し、無視された追加フィールドが確実にレンダリングされるようにするのに適しています。

CSRF トークンが表示されない理由は、FOSUserBundle ログイン フォームが Symfony フォームではなく、FOSUser フォーム ハンドラーによって処理される通常の HTML フォームであるためです。

この決定が下された理由は完全にはわかりませんが、その背後に技術的な理由があったことは確かです。問題がある場合は、手動で追加し、フォームハンドラーを拡張して処理し、応答で検証することができます.サービスはパラメータ化されているので、交換は比較的簡単だと思います。

しかし、私の大きな質問は、なぜあなたがこれをわざわざするのですか? それは大規模な取引ですか？CSRF は便利なステップですが、セキュリティの万能ソリューションではありません。個人的には、これよりも優先度が高くなります。大したことであれば、いつか FOS で修正されるでしょう。

後者の点については、関連性がよくわかりませんが、これが段階的な関与の達成をどのように妨げているのですか? とにかく簡単なヒントですが、システムのこの部分を自分で設計したわけではありませんが、私が最近取り組んでいる e コマース プロジェクトで、リーダーは段階的なエンゲージメントを達成することを決定しました (人々が匿名でチェックアウトできるようにするため)。彼らのアクションの非常に早い段階で、新しいユーザーは自動生成されたユーザー名と ROLE_GUEST などのカスタムロールで永続化されます.Symfony のデフォルト機能は私たちのユースケースには不十分であることがわかります.

于 2012-12-03T22:18:25.157 に答える