回答についての疑問点を列挙してみる。 まぁ、再質問したところで真っ当な回答が返ってくるとは思えないので、ここに列挙するだけとする。
A1に関して、通常のウェブアプリの作り方からすれば、セッション管理はCookieを使ったりして行う。 その場合、通信路上はセッションIDなどが通るわけだが、サーバー側の「外部から見えるところ」にはセッションIDなどは存在しないはずである。 従って、検索エンジンのロボットがセッションIDを含む情報を取得するはずがないと思っているのだが、間違っているだろうか？ もちろん、セッションIDなどを持つページが静的にサーバー上に存在していれば別の話だが、そんな初歩的なミスを開発会社が行うとは思えないのである。 ならば、検索エンジン経由で「オープンになっているセッション」を第三者が開くことは考えられないと思うのだが如何だろうか？ こう考えると、「再現できなかった」という件が成立する。
A2に関して、通常であればアプリケーションレベルで生成しているログと、ウェブサーバーへのアクセスログを突合することで、不正と思われるアクセスは抽出できるはずであると考える。 ましてや、検索エンジン経由でセッション接続中のページにアクセスできるというのであるから、ウェブサーバーへのアクセスログで抽出可能に思える。 ひょっとして、ウェブサーバーへのアクセスログを取得していないか、簡易なログに設定を変更しているのだろうか。 いずれにしても、言い訳としては拙い感じがする。
A6に関して、そもそも現象が再現しないものを、どのようにしてセキュリティ強度を高めたことを実証するのか疑問だ。 ひょっとすると、先に書いたようにセッションIDなどを含むページが静的に配置されるという「驚きの」システムだったとしたら、対応可能であろう。 しかしながら、真っ当に動的な生成を行っているとしたら相当難しいはずだ。 どのように対応し、どのように検証するのか知りたいところである。 なお、2009年に指摘した「ユーザーIDとパスワードが同一の利用者」が未だに存在していると言うことなので、ここは是非ともキチンと対応して欲しいものである。 そのようなユーザーを解消するよう進言したことを無視したことが、図らずも明らかになったわけである。
A7に関して、"http://ma51.notes.isetan/mail/ij/00300001.nsf/($Inbox)/E3AC22CC756ECF614925796F000D5813/?OpenDocument&PresetFields=s_ViewName;(%24Inbox),h_FolderStorage;(%24Inbox),s_FromMail;1,s_SortBy;4,s_UnreadOnly;0"という類いのリファラのログが多数残っている。 これ、伊勢丹さんの社内システムじゃないのかな？ 証拠が残っているんだから、ちゃんと事実関係を調査して回答しなきゃ駄目でしょ。 事実は小説よりも奇なりと言いますからねぇ。
いずれにしても、まるで検索エンジンのロボットがセッションハイジャックをしたかのように書かれていることが問題であり、その再現性を検証できないまま「対策して再開します」というのは説得力に欠ける回答であることは間違いない。 高木先生や徳丸氏が、この無知な私に御教授いただけると助かるのだが、未だに理解できない自分が存在している。
投稿者プロフィール
