Katsunori IMAI
imai****@glatt*****
2004年 5月 13日 (木) 16:06:36 JST
田村様 今井です。こんにちは。 ＃早々にリプライをいただいたのに、レスポンスが遅くて申し ＃訳ありません。 セッションハイジャック自体は、「セッションを横取りされた 状態」であり、その横取りする方法に、田村さんが書かれてい る2種類（それ以上）あると思っています。 私は、現在世間で問題になっているセッションハイジャックは 「故意」にSIDを盗んでハイジャックする場合まで含んでいる と思います。例えば、経済産業省のプレスリリース http://www.meti.go.jp/kohosys/press/0004378/0/030811cookie.html でも、「故意」に盗むことまで考慮しています。 また、「セッションハイジャック」や「セッションハイジャッ ク対策」で検索をしても、「偶然」だけを防いで、セッション ハイジャック対策としているところはないと思います。 実際にどのようにして対策をするかは、IPAなどにもあります し、現在のosCに簡単に組み込むことができないこともわかっ ています。組み込んでくださいとお願いしているわけではあり ません。 このMLを見ている人はエンジニアだけでなく、「セッションハ イジャック」って何？？？の人も多いと思います。 私が危惧するのは、田村さんが組み込んでくださった対策をもっ て、「セッションハイジャック対策ができている」と考える 人がいるのではないかということです。ですので、 盗まれる可能性があること 盗まれた場合にこうやればログインしなくてもログイン状態 になることができること を書かせていただきました。 On Fri, 07 May 2004 21:29:13 +0900 TAMURA Toshihiko <tamur****@bitsc*****> wrote: > 今井さん、こんにちは。 > 田村です。 > > # 今井さんが書かれているのも、もっともだと思います。 > # セッション問題にはいろんな意見やアイデアもあるでしょうし、 > # osCommerceの実装も変わっていくのではないでしょうか。 > > セッションハイジャックにも、次の２種類があります。 > > a) BBSや検索サイトの検索結果に記録されたsidによって、 > 予期せずセッションハイジャックの状態になってしまっった。 > > b) 通信を盗聴されて、取得したsidでアクセスされた。 > > osCommerceで運営しているサイトは、 > a)の対策をまずやるべきだと思いますが、 > クッキーを受け付けない設定のユーザをサポートする必要もあって、 > b)に関しては対策がむずかしいです。 > > 個人的には、それに対しては次のような対策をとるのが > いいのではないかと考えています。 > > (対策1) すべてをSSLで運用する。 > ('HTTP_SERVER'/'HTTPS_SERVER'に'https://...'を指定する) > > (対策2) [アカウント情報]/[レジに進む]などのSSLページに移行するときに、 > ログイン後であっても毎回パスワードを入力させる。 > (そのときにsidを付け替える) > > サイトの性格や重要性によって、 > こういった対策の導入を考えればいいのではないでしょうか。 > > -- > 田村敏彦 / 株式会社ビットスコープ > E-mail:tamur****@bitsc***** > http://www.bitscope.co.jp/ > > > _______________________________________________ > Tep-j-general mailing list > Tep-j****@lists***** > http://lists.sourceforge.jp/mailman/listinfo/tep-j-general
