8

JSESSIONIDがセキュリティの観点からどのように機能するかについての「ダミー向け」のわかりやすい英語の説明を探しています。

  • 私の現在のJSESSIONIDを知っているだけの人が、私のセッションを偽装/ハイジャックできますか？
  • どのシナリオでJSESSIONIDがURLの一部になり、このOWASP＃2セキュリティリスク（シナリオ＃1）はTomcat / Glassfishの最新バージョンに引き続き関連しますか？もしそうなら、それを防ぐために何を「オフ/オン」にしますか？
4

1 に答える 1

14

Q：現在のJSESSIONIDを知っているだけの人が、私のセッションを偽装/ハイジャックできますか？

A：はい。

そのため、サイトでCookieに注意することが重要です。実際、パケットスニッフィングが心配な場合は、HTTPS接続を介してリクエストが行われたときにのみセッションCookieを送信する必要があることを意味します1。また、「httpOnly」フラグを設定すると、クライアント側のjavascriptなどによるCookieの使用が停止されます。

Q：どのシナリオでJSESSIONIDがURLの一部になりますか

A：通常、これはWebサーバー（コンテナーレベル）がセッショントークンをURLに挿入したときに発生します。

  • ユーザーのブラウザがCookieを設定しない場合の回避策として、または
  • URLをブックマークしたり、電子メールで他の人に送信したりするのに「適した」ものにするため。

明らかに、これは安全ではなく「悪い習慣」です...ただし、短いセッションタイムアウトはこれを軽減する傾向があります。（または、HTTPS経由でOKです...ユーザーが他の人とURLを共有しない場合1。）

Tomcat 6.xの場合、コンテナがセッションIDをURLに（これまでに）追加しないようにする方法は、disableURLRewriting="false"属性をコンテキストに追加することだと思います。

Tomcat 7の場合：

Context.disableURLRewriting：これは削除されました。同等の効果は、WebアプリケーションまたはグローバルCATALINA_BASE / conf/web.xmlファイルでsession-config/tracking-mode要素を構成することで取得できます。

1-これは、既知のSSLエンドポイントの脆弱性に対処するためにWebサーバーにパッチを適用（など）していることを前提としています。そうでない場合、HTTPS接続は安全でない可能性があります。

于 2012-05-07T04:07:04.620 に答える