3

JSFフレームワークで使用されるビューIDには、リクエストトークンとして機能し、CSRFを無効にするという嬉しい副作用があることをどこかで読みました。これがプログラミングの観点から何もする必要がないことを意味するかどうか、誰か教えてください。プログラマーとして、JSF を使用すれば、CSRF について心配する必要はありませんか?

4

3 に答える 3

4

JSF にjavax.faces.ViewState. JSF 1.x では、推測するのはおそらく「簡単すぎる」だけです。これは JSF 2.1 で修正されました。JSF impl issue 812およびJSF spec issue 869も参照してください。

主な懸念事項は、XSSSQL インジェクションです。成功した XSS 攻撃は、成功が保証された CSRF 攻撃のソースになります。XSS を回避するには、「プレーン バニラ」テンプレート テキストではなく、すべてのユーザー制御入力を(再) 表示していることを確認してください。h:outputTextSQL インジェクションは、必ずしも潜在的な CSRF ホールにつながるわけではありませんが、機密データが漏洩したり、改ざんされたりする可能性があります。これを回避するには、名前付きクエリ (JPA、Hibernate など) を使用する堅牢な ORM フレームワークを使用していることを確認するか、「プレーン バニラ」JDBC を使用している場合は、すべてのPreparedStatement代わりに使用していることを確認してください。 Statement.

于 2010-04-09T11:54:50.663 に答える
0

これは保証されていますか?JSF の一部の実装では、攻撃者が推測できる順次 ID を使用しています。

これは、より受け入れられている Java SecureRandom の代わりに、順次ビュー ID 生成を行う Sun JSF-RI について説明している記事です。

http://seamframework.org/Documentation/CrossSiteRequestForgery

于 2010-04-19T18:44:47.377 に答える
-1

すみません、先日、「私の JSF アプリケーションは CSRF の問題を報告しなかったと言いました」と間違っていました。しかしここで、 JSF には CSRF に対する「組み込み」の保護がないことをお伝えしたいと思います。CSRFTester ツールでテストしたところ、JSF アプリケーションが CSRF 攻撃に対して脆弱であることがわかりました。また、すべての Java EE アプリケーションは CSRF 攻撃に対して脆弱であることもお伝えしたいと思います。アプリケーションを CSRF 攻撃から保護する方法の 1 つは、ランダムなトークンを生成して URL に追加することであることがわかりました。ありがとう!!

于 2010-10-26T09:41:27.933 に答える