- PR -

JSPの暗黙オブジェクトsessionについて

1
投稿者投稿内容
cube
会議室デビュー日: 2007/01/25
投稿数: 3
投稿日時: 2007-02-08 13:57
いつも参考にさせていただいています。

Java(Struts + JSP/JSTL)でのWebアプリ開発について本を読みながら勉強しています。

(1)この本に出てくるサンプルアプリではログイン認証にパスすると
HttpSessionにユーザ情報(Userオブジェクト)が格納されます。
コード:
・・・・・・
User user = shop.getUserByUserId(Integer userId);
httpSession.setAttribute(WebConstants.USER_KEY, user);
・・・・・・



(2)また、すべてのJSPには次のような記述があり、
暗黙オブジェクトsessionをJSPで使えないようにしています。
コード:
<%@ page session="false" %>



(3)また、画面の共通メニュー部分には次のような記述があります。
コード:
<c:choose>
  <c:when test="${not empty loginUser}">
    <font color="red">ようこそ、<c:out value="${loginUser.loginId}" />さん</font>
  </c:when>
  <c:when test="${empty loginUser}">
    <font color="red"><html:link action="/login">ログイン</html:link></font>
  </c:when>
</c:choose>



(4)そして、ほとんどのStruts Actionクラスのexecuteメソッドでは(3)の処理のために
次のようにしてリクエストスコープにユーザ情報を設定しています。
コード:
・・・・・・
User user = (User) httpSession.getAtrribute(WebConstants.USER_KEY);
request.setAttribute("loginUser", user);
・・・・・・



疑問に思っていることは、どうしてHttpSessionにあるユーザ情報を直接使わずに
わざわざリクエストスコープに設定し、それを(3)で表示するようにしているかです。
JSPで暗黙sessionオブジェクトを使用すると何か問題があってのことなのかなと
推測しているのですが、理由がわかりません。
もしご存知の方いらっしゃいましたら、ご教示下さい。
よろしくお願いします。
あしゅ
ぬし
会議室デビュー日: 2005/08/05
投稿数: 613
投稿日時: 2007-02-08 14:19
引用:

cubeさんの書き込み (2007-02-08 13:57) より:
疑問に思っていることは、どうしてHttpSessionにあるユーザ情報を直接使わずに
わざわざリクエストスコープに設定し、それを(3)で表示するようにしているかです。
JSPで暗黙sessionオブジェクトを使用すると何か問題があってのことなのかなと
推測しているのですが、理由がわかりません。



何ででしょうねぇ?著者の趣味じゃないですか?

<%@ page session="false" %>
としないと、JSPが必ずセッションを作ってしまうのでその対策かも。

ログイン前はセッションを維持したくない、等の場合でしょうか?
で、他のJSPも先頭付近はみんな同じものをコピペしまくりとか。

この設定があっても、どのみちStrutsのタグやELからは参照できますし。
さる
ぬし
会議室デビュー日: 2005/07/14
投稿数: 276
お住まい・勤務地: 実家戻ったw
投稿日時: 2007-02-08 14:22
単純にセッションを使えない場合を想定してるのでは?
後はセキュリティの関係でセッション使うな!!って言われた経験もありますね。
cube
会議室デビュー日: 2007/01/25
投稿数: 3
投稿日時: 2007-02-08 15:31
あしゅさん、さるさん、返信ありがとうございます。

さるさん
引用:

後はセキュリティの関係でセッション使うな!!って言われた経験もありますね。


セッション(Cookieのことですよね?)を使わないとなると
URL書き換えでセッション管理されたのでしょうか?
でも、もしそうならば URL書き換えの方がCookieよりも安全にセッション管理できるということ???
よろしければ教えて下さい

あしゅさん
引用:

ログイン前はセッションを維持したくない、等の場合でしょうか?


なるほど。
サンプルアプリ上はログイン前にセッションがあっても問題ないが、
著者は開発現場でこのようなログイン前セッションを維持しない考えがあって
それがサンプルコードに表現されたという感じかもしれないですね。

真意を著者に直接たずねてみようかと思います。
わかりましたらこちらにご報告します。

ありがとうございました。
さる
ぬし
会議室デビュー日: 2005/07/14
投稿数: 276
お住まい・勤務地: 実家戻ったw
投稿日時: 2007-02-08 17:20
struts初体験の頃の案件だったので結局詳しい事を理解してなかったけど、
セッションに入れずに全部リクエストで投げて、もう一回投げ返してもらってた。
クライアントに送る時に暗号化かけて、
戻ってきたリクエストはサーブレットで復号化かけて、
下っ端コーダーの俺らにはなんも問題なくおまじないを唱えればOKって感じw

[追加]
セッションクッキーを使ったの方でOK!
言葉足らずですんません。
[/追加]

[ メッセージ編集済み 編集者: さる 編集日時 2007-02-08 18:04 ]
山本 裕介
ぬし
会議室デビュー日: 2003/05/22
投稿数: 2415
お住まい・勤務地: 恵比寿
投稿日時: 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 ]
cube
会議室デビュー日: 2007/01/25
投稿数: 3
投稿日時: 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として生成するためにも重要。
コード:

/** ログイン処理を実行して成功したらセッションを再発行 */
if (login(userId, password)) {
  request.getSession(true).invalidate();
  HttpSession session = request.getSession(true);
  // sessionにログイン情報をセット
}



◎@ITの投票機能で
「あなたが現在開発しているWebシステムでは、
セッション盗聴、セッション固定攻撃への対策を施していますか?」
とみなさんに問うてみたい

<追記>
セッションハイジャックをセッション盗聴に変更。

[ メッセージ編集済み 編集者: cube 編集日時 2007-02-08 22:11 ]
かつのり
ぬし
会議室デビュー日: 2004/03/18
投稿数: 2015
お住まい・勤務地: 札幌
投稿日時: 2007-02-09 00:45
ログイン処理をSSLでやるとして、それまでにセッションが作られなければ、
非SSLでセッションIDが漏れる可能性がなくなりますね。
SSLになったところでセッションIDが発行されても漏れることはないですし。

本題ではセッションを作成済みみたいなので、
あんまり意味がないというか本題とズレていますね・・・

筆者の趣味としか思えないですね。
「そうしなければいけない。」という根拠が全くないので。
1

スキルアップ/キャリアアップ(JOB@IT)