- - PR -
JSPの暗黙オブジェクトsessionについて
1
投稿者 | 投稿内容 | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2007-02-08 13:57
いつも参考にさせていただいています。
Java(Struts + JSP/JSTL)でのWebアプリ開発について本を読みながら勉強しています。 (1)この本に出てくるサンプルアプリではログイン認証にパスすると HttpSessionにユーザ情報(Userオブジェクト)が格納されます。
(2)また、すべてのJSPには次のような記述があり、 暗黙オブジェクトsessionをJSPで使えないようにしています。
(3)また、画面の共通メニュー部分には次のような記述があります。
(4)そして、ほとんどのStruts Actionクラスのexecuteメソッドでは(3)の処理のために 次のようにしてリクエストスコープにユーザ情報を設定しています。
疑問に思っていることは、どうしてHttpSessionにあるユーザ情報を直接使わずに わざわざリクエストスコープに設定し、それを(3)で表示するようにしているかです。 JSPで暗黙sessionオブジェクトを使用すると何か問題があってのことなのかなと 推測しているのですが、理由がわかりません。 もしご存知の方いらっしゃいましたら、ご教示下さい。 よろしくお願いします。 | ||||||||||||||||
|
投稿日時: 2007-02-08 14:19
何ででしょうねぇ?著者の趣味じゃないですか? <%@ page session="false" %> としないと、JSPが必ずセッションを作ってしまうのでその対策かも。 ログイン前はセッションを維持したくない、等の場合でしょうか? で、他のJSPも先頭付近はみんな同じものをコピペしまくりとか。 この設定があっても、どのみちStrutsのタグやELからは参照できますし。 | ||||||||||||||||
|
投稿日時: 2007-02-08 14:22
単純にセッションを使えない場合を想定してるのでは?
後はセキュリティの関係でセッション使うな!!って言われた経験もありますね。 | ||||||||||||||||
|
投稿日時: 2007-02-08 15:31
あしゅさん、さるさん、返信ありがとうございます。
さるさん
セッション(Cookieのことですよね?)を使わないとなると URL書き換えでセッション管理されたのでしょうか? でも、もしそうならば URL書き換えの方がCookieよりも安全にセッション管理できるということ??? よろしければ教えて下さい あしゅさん
なるほど。 サンプルアプリ上はログイン前にセッションがあっても問題ないが、 著者は開発現場でこのようなログイン前セッションを維持しない考えがあって それがサンプルコードに表現されたという感じかもしれないですね。 真意を著者に直接たずねてみようかと思います。 わかりましたらこちらにご報告します。 ありがとうございました。 | ||||||||||||||||
|
投稿日時: 2007-02-08 17:20
struts初体験の頃の案件だったので結局詳しい事を理解してなかったけど、
セッションに入れずに全部リクエストで投げて、もう一回投げ返してもらってた。 クライアントに送る時に暗号化かけて、 戻ってきたリクエストはサーブレットで復号化かけて、 下っ端コーダーの俺らにはなんも問題なくおまじないを唱えればOKって感じw [追加] セッションクッキーを使ったの方でOK! 言葉足らずですんません。 [/追加] [ メッセージ編集済み 編集者: さる 編集日時 2007-02-08 18:04 ] | ||||||||||||||||
|
投稿日時: 2007-02-08 17:42
>セッション(Cookieのことですよね?)を使わないとなると
>URL書き換えでセッション管理されたのでしょうか? セッション = Cookie ではありません。 URL書き換えで管理するのも同じくセッションです。 どちらが危険かと言えば、セッションID入りのリンクをIMなりメールなどで送ればセッションの共有ができてしまうという意味で URL 書き換えの方がやや危険と言えるかもしれません。 パケットキャプチャしてしまえばどちらもセッションIDが丸見えなので乗っ取りは可能です。 たとえば WebLogic なんかは AuthCookie というセッションID の盗聴による乗っ取りを防ぐ仕組みが実装されています。 - dev2dev Home > リソース > 日本語ソリューション > BEA WebLogic Server > S-20464 "セッション ID の盗聴に対して有効な設定はありますか?" http://www.beasys.co.jp/BeaPortal/cs/solution/getSolution.do?solutionId=20464 他のサーバでセッションの乗っ取りを危惧するのであれば XSS 対策はもちろんのこと、SSL でのみアクセスを許可するか、AuthCookie と同じく HTTPとHTTPSで別のIDを発行するような仕組みが必要です。 [ メッセージ編集済み 編集者: インギ 編集日時 2007-02-08 17:44 ] | ||||||||||||||||
|
投稿日時: 2007-02-08 21:54
さるさん、インギさん、コメントありがとうございます。
さるさん まだまだお聞きしたいことがあるのですが、 きりがないのでここでやめておきます いんぎさん セッションハイジャックの解説と情報ポインタありがとうございます。 お陰様で理解が進みました。 それと商用アプリサーバーはさすがですね。 *** 以下独り言モード *** ◎TomcatでセッションIDの盗聴への対策をとる(Secure Cookie)場合、次をしなければならない? (1)Secure Cookie生成時(通常ログイン認証)のリクエストプロトコルは http ではなく、https にする。 http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?topic=5722&forum=12 (2)セッション管理が必要なリクエストについてはすべて https とする。 ◎以下の連載は good http://www.atmarkit.co.jp/fsecurity/rensai/struts04/struts01.html このページにある次のコード(HttpSession#invalidate)はSession Fixation対策のみならず、 Tomcatでのセッション盗聴対策(1)でSession IDをSecure Cookieとして生成するためにも重要。
◎@ITの投票機能で 「あなたが現在開発しているWebシステムでは、 セッション盗聴、セッション固定攻撃への対策を施していますか?」 とみなさんに問うてみたい <追記> セッションハイジャックをセッション盗聴に変更。 [ メッセージ編集済み 編集者: cube 編集日時 2007-02-08 22:11 ] | ||||||||||||||||
|
投稿日時: 2007-02-09 00:45
ログイン処理をSSLでやるとして、それまでにセッションが作られなければ、
非SSLでセッションIDが漏れる可能性がなくなりますね。 SSLになったところでセッションIDが発行されても漏れることはないですし。 本題ではセッションを作成済みみたいなので、 あんまり意味がないというか本題とズレていますね・・・ 筆者の趣味としか思えないですね。 「そうしなければいけない。」という根拠が全くないので。 |
1