4

独自の MVC と承認モデルに基づく Web アプリケーションでは、最近 Spring MVC に移行しました。その動きの一環として、ローカルで作成された GUID から、各要求と共に Cookie ベースのセッション ID に渡されることも検討しています。

一見すると、私たちのケースでは、標準の JSESSION/HttpSession がすべてのセキュリティ悪の根源であるように見えるため、そうすることは大きな欠点になるように見えます。

  1. セッション固定 (既存のコードでは、セッションはログインに成功した後にのみ作成されるため、セッションを無効にする必要はありません。
  2. CSRF - セッションが Cookie として渡されることはないため、これは決してリスクではありません (実際のフレームワークや、HDIV および CSRFGuard をチェックした一般的なソリューションがないため、処理に問題があります)。
  3. 使いやすさのテスト - QA では、JSESSION では不可能な、複数の役割を持つ複数のユーザーを同じサーバーに簡単に接続できます。
  4. さまざまなコンテナ (Weblogic、JBOSS、および Websphere) での一貫した HTTPSession の作成と無効化
  5. HTTP から HTTPS に移行するときの JSession 処理の一貫性がありません。

それで、「標準であること」の明らかな利点以外に、なぜJSESSIONルートに行きたいのかについての手がかりはありますか?

4

2 に答える 2

1

jsession を使用する必要がある、または使用しない理由についての明確な回答ではありませんが、懸念事項に関するいくつかのコメントがあります。

  1. アプリケーションは、セッションが存在するかどうかに依存するべきではありません。特定のルール（ユーザー認証、このユーザーに割り当てられたロールなど）に従ってセッションが有効であるという事実に依存する必要があります。
  2. 賢明なアクションに GET を使用しないように注意する限り、CSRF は大した問題ではありません。また、Spring MVC について言及されているように、CSRF で達成するのは非常に簡単です。
  3. 確かに、1 つのブラウザーだけに依存している場合はそうです。補足として、手動テストは状況によっては依然として必須ですが、多くのユースケースでは自動化のメリットが得られるため、役割を別の役割に切り替える必要がある場合の影響を軽減できます。
  4. それで問題が発生することはありません。ただし、セッションの内容はできるだけ少なくするようにしました。
  5. そして、それは良いことです。気付かないうちに安全な接続から離れるのを防ぐことができます。

さて、どのオプションを選択しても、常にいくつかの欠点があります。各リクエストに (したがって、場合によっては各 GET URL に) UUID があると、ユーザーはブックマークを簡単に使用できなくなります。セッションを維持することもできません。

于 2011-03-04T12:55:44.047 に答える
0

多くの議論の分析とテストの後、RIA UI のようなデスクトップを備えた RESTfull 以外のアプリケーションである私の場合、JSESSION は (主に CSRF) 進むべき道ではなく、より良いオプションは BODY です。ベースの内部生成キー。ただし、これは、アプリケーションがタイムアウトとセッションの無効化を強制的に処理することを意味します。

于 2011-03-31T19:45:49.007 に答える