- - PR -
struts struts-config（scope=session）
| 投稿者 | 投稿内容 | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2003-11-12 18:56
３は、どのようにしておこなうんでしょうか？ サンプルを載せていただけませんでしょうか。 ちなみに、a->b, b->c のＡｃｔｉｏｎＦｏｒｍは同じクラスです。 | ||||||||||||||||
|
投稿日時: 2003-11-12 19:55
こんばんわ 私なら１を選択します。(この場合はセッションの破棄がいるのかな?) 全ての画面で同じアクションを使うのなら requestスコープにする理由もわからないですし。 ２．requestスコープで管理する。（ａ→ｂの遷移時にhiddenで情報を隠す） で行うメリットがわかりません。 ３．requestスコープで管理する。（ａ→ｂの遷移時に再度requestにActionFormの情報を詰め直す） もいまいち理由がわかりません。 登録画面から確認画面にいき、次に登録処理を行うなら 登録画面で入力した内容は登録処理を実際に 行うまで編集したりしないんと思うので。 ちなみにhiddenで隠すのは 確かに場合によるとは思いますが toppoさんがおっしゃっているように セキュリティー上よくないとは思います。 | ||||||||||||||||
|
投稿日時: 2003-11-12 21:44
こういった、セキュリティ関連の話は木浩光さんのサイトにあるスライド類が参考になります。
このサイト内の安全なWebアプリ開発 31箇条の鉄則(PDF)で、hiddenで隠すことに関する話を見かけました。 | ||||||||||||||||
|
投稿日時: 2003-11-12 22:06
私もＨｉｄｄｅｎで隠すことはもう論外だとおもっています。 特にパスワードなどが含んだ場合も考えると、絶対ありえません。 １、３どちらかになるとおもうのですが、私のわかる範囲でのデメリットとしては、 １．Sessionスコープで管理する。 登録処理終了後も、セッションは行き続けてしまう。 セッション削除させるプログラムを書く必要がある・・ （struts-config.xml内でセッション指定する・しないにおおじてセッションを削除する・しないのプログラムを書きわける必要がでてくるため、今一スマートではない。） ３．requestスコープで管理する （ａ→ｂの遷移時に再度requestにActionFormの情報を詰め直す） 確認画面としてのプログラムを書く必要がある。 私は、無駄なリソースなるべく使わないようにという観点からみて、３を選ぶべきかと思いました。 | ||||||||||||||||
|
投稿日時: 2003-11-13 00:16
タイトル的には間違っていないし、このスレッドで話題が続くようなので突っ込ませていただきます。
まず、 >３．requestスコープで管理する。（ａ→ｂの遷移時に再度requestにActionFormの情報を詰め直す） この方法がいまいちわかりません。b の画面を表示するときに hidden で情報を保持せず、かつ session に情報を保持しないのであれば b→c へ遷移時にどうやって情報を受け渡すのでしょうか？2003-11-11 09:50 に Pal さんが指摘しているのと同じ疑問ですが。 また、hidden で情報を保持するとセキュリティ的に問題がある、というのはどういう意図でしょうか？ぱっと思いつく限り3つくらい理由がありました。 1)パケットキャプチャされる可能性がある post 時にも十分パケットキャプチャされる可能性があるので脆弱性に違いはあまりないかと思います。パケットキャプチャされて困るのであれば SSL 通信にするべきです。 2)通常のブラウザを使わずに意図的に不都合な値を POST する 無茶苦茶な例えでいうならば買い物の合計金額が hidden フィールドに収められているような場合です。ブラウザを使わないで、b→cへの遷移をエミュレートするプログラムで好きな金額で買い物ができる！って寸法ですが・・・・、Struts 使っているんだったら b→c の遷移でも validate はしてますよね？ というわけで、私の考えでは上記２つの理由はセキュリティ上問題になりません。気になるのが、３つ目です。 3)ソースを表示すれば内容がみられる ソーシャルエンジニアリングに対する耐性、という議論になるかと思いますが第三者が右クリックでソースを表示できる状況であればブラウザの戻るボタンを押して入力内容を変更してしまうことが可能ですよね。 hidden フィールドに設定されていることでパスワードを閲覧するのが若干楽になりますが。hidden に格納されていなくても、SSL接続でない、または HTTP でも同じパスへの POST を受け付けるのであれば(※)ブラウザを自前の悪意あるプロキシサーバを使うように設定することでパスワードは閲覧可能です。 ※)こういうの、WebLogic なんかだと AuthCookie なんてのが実装されてて安全です。SSLで FORM/BASIC認証後に HTTP で再度接続すると認証を要求されますので ・[WLS8.1解決済みの問題]-[サーブレットと JSP]-[CR094488] セッションに情報を格納する方法でも、フィルタ等を使って適切なタイミングで＊確実に＊セッションから情報を削除しないと結構危険かもしれません。 b→cと遷移せずに、突然ユーザはトップページかどこかとんでもないページへ遷移する可能性がありますから。その状態で第三者がブラウザを操作して画面 b を表示させて、「修正する」ボタンを押して画面aへ遷移して情報を書き換えて・・・・。などと疑いだしたらきりがありません。 それくらいの操作が可能なほど優れたソーシャルエンジニアリングが行える状況ではキーボードのタイピング内容をキャプチャするプログラムをインストールできるかもしれませんが・・・^^; で、結局私のスタンスとしては hidden に情報を保持しないことで少し覗き見はしにくくなるので、session に格納する方法に賛成です。 が、session に格納してしまえば安心、というわけではないので気をつける必要があります。安易な作りで session に情報を格納すると hidden に格納するのと同じくらいソーシャルエンジニアリングに弱くなります。 まとめると、安全性を考えると以下のような感じでしょうか。 1)情報は session に格納する 2)接続は SSL で行い、HTTP で同じパスを叩いた場合は再度認証を要求する(WebLogicなら config.xml の AuthCookieEnabled=true,WLS8.1 ではデフォルトで有効)、または HTTP での接続を許可しない(<transport-guarantee> を confidential に) 3)session に格納した情報はその情報を必要としない Action にたどり着いた段階で（または Filter でその前に) remove する [ メッセージ編集済み 編集者: インギ 編集日時 2003-11-13 00:53 ] | ||||||||||||||||
|
投稿日時: 2003-11-13 00:51
はじめまして。
1)入力画面 -> 2)確認画面 -> 3)登録完了画面 というよくある遷移であれば、 私ならSessionを使います。 みなさんがあげてる理由に加え 1．2->3の遷移において入力内容の再チェックをしなくてすむ 2．2->3の処理においてセッション情報がないと登録処理が走らない。そして セッションから情報を取り出した後すぐ削除する つくりにしておけば2重サブミットされにくい（完全ではないが）。 というのが経験上であります。 hiddenで引き継ぐとやはりみなさんがご指摘のように、プライバシーやら の情報が多分にふくんだ情報をいくら暗号化するにせよインターネット上を 何度も往復するのはセキュリティ上、どこかでいつか問題が発生する確率 を高めるきがします。 | ||||||||||||||||
|
投稿日時: 2003-11-13 01:33
インギさんは書きました---------------------------------------------------- この方法がいまいちわかりません。b の画面を表示するときに hidden で情報を保持せず、かつ session に情報を保持しないのであれば b→c へ遷移時にどうやって情報を受け渡すのでしょうか？2003-11-11 09:50 に Pal さんが指摘しているのと同じ疑問ですが。 -------------------------------------------------------------------------- たしかにscope=requestでは 登録確認画面でサブミットをしても データはサーバ側に送られないので 登録処理にフォームのデータは使えないですね。 tetoさんは書きました--------------------------------------------------- 1．2->3の遷移において入力内容の再チェックをしなくてすむ 2．2->3の処理においてセッション情報がないと登録処理が走らない。そして セッションから情報を取り出した後すぐ削除する つくりにしておけば2重サブミットされにくい（完全ではないが）。 ----------------------------------------------------------------------- strutsでは2重サブミットや URLを直に指定して不正なアクセスを行うのを 防止するための機能がありますよね。 (※ToransactionToken) ちなみにセッションの限界値は Webサーバによって異なるのかな?? | ||||||||||||||||
|
投稿日時: 2003-11-14 15:00
すいません、このメールを読んでもう一度考えてみました。 ダメジャン。。。。。。皆様ごめんなさい。 嘘言ってました。 修行し直します。 | ||||||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。