スゴ技

平成27年度秋基本情報技術者試験【問4】（その1）

Blog：IT・情報処理BLOG | 2015.10.25

おはようございます、ブログの3男、佐藤です。今日までが本学・IT分野の試験休み、明日から通常授業に戻ります。とはいえ週末が学園祭のため浮足立つことまちがいなしですが。
基本情報・応用情報・高度試験から1週間経ち、頭からすっぽり抜け落ちてしまった残念なコトになっていないかが気になるところです。自己採点の結果と今後の対応を考えると、頭に残っているうちに再度叩き込んでおくぐらいしておかないといけませんね。
ということで午後問題問4にあたってみたいと思います。たぶん2回に分けての解説になりそうな気が…

必要なもの: 受験時の試験問題もしくは過去問配布ページよりH27秋問題冊子(午後)

この問題、Webページのセッション遷移やその際のデータのやり取りについての確認といった様相です。

もともとHTTPでは、「常に一見さん」という考え方でページのやり取りが行われる設計でした。仕方ないです、当初の想定していた対象が ハイパーテキストを転送する というレベルものでしたから(ハイパーテキスト: HyperText; 単なる文面でなく、何らかの付加情報を持つ高度な文面)、テキストデータ+若干の画像程度のものでした(HTTP/0.9)。
その結果シンプルなプロトコルになっていたりします。GETしかメソッドなかったし、

クライアント(ブラウザ): 「データくれよ!」
サーバー: 「わかったよ、これだから受け取れや」

という組み合わせで一往復で全てが完結し、その時点でサーバーも綺麗サッパリ忘れる仕組みです。好きです、こういう割り切り感。

でも実際のところ、その後にフォームによるデータのクライアントからの送信や、電子商取引(通販など)における仕組みが必要になったことから、リクエスト(クライアント→サーバー)・レスポンス(サーバー→クライアント)においておまけデータの添付が可能な状況になってます(この仕組を利用したのがいわゆるクッキー)、この辺りの仕様がHTTP/1.0でしょうか。

その後、ホスト名ベースのバーチャルホストのサポートが入ったりいくつか追加事項の入ったHTTP/1.1へ進化し、現在ではHTTP/2へとなってきてます(HTTP/2の実装はまだまだこれから感がありますが、進むことはまちがいないでしょう、試験的にどうなのかは未知数ですが)。

さて、よく使われているHTTPにおけるクッキーは、

サーバーからクライアントに、有効範囲(ドメイン名とパス)と有効期限を付与したクッキー情報を送る
受け取ったクライアント側は正当性を確認し、クライアント側で保存(もしくは破棄)する
後ほど同じサーバーに接続した際に、該当するクッキー情報を送る

という構造になっています。そのため、一見さんであったとしても

レスポンス(サーバー→クライアント): 「本日はありがとうございました、次お越しの際はこのチケットをご提示ください」
受信したクライアント: 「どうもです」 → お財布などにしまっておく
後日来店(クライアント→サーバー): 「(ガラガラ)こんにちは、以前お世話になりましたHOGEHOGEです」と言いつつ財布からチケットを取り出して渡す
チケットを確認したサーバー: チケットのデータを端末に打ち込み「以前お越しになられたHOGEHOGE様ですね、毎度ありがとうございます」

という形で以前の内容を掘り起こしてもらえるようにできます。
もちろんこのためにはチケット(以前のやり取り(セッション))をサーバー側で記憶しておく必要があります。この部分はデータベースに入れておくのが一般的ですね。

有効期限については、設定されている(チケットに書かれている、事実上無制限というレベルで長期間に設定されることもあるよ)こともあれば、設定されていないこともあります。ログアウトやブラウザウィンドウを閉じた時点で消される(メモリ上に保存されるタイプ)ことも設定によっては発生します。

ということで、このクッキーに状態の記憶をしておくためのキー(セッションID)を用意し、共有することで状態遷移を管理しようというのは至極当然となるわけですね。

はい、事前ネタここまで。

さてさて問題、設問1を見てみましょうか。
図1(問題文ページ番号18)で、ショッピングサイトの状態遷移図がでています。
要は どのタイミングでセッションID作るのか という問題です。

カートに入れたという情報はとりあえずセッションIDに紐付けられて保持されている
- 「商品の選択」→「選択済み商品の確認」のタイミングではセッションIDがないとおかしい
実は「商品の閲覧」→「選択済み商品の確認」というフローがある
- カートに入れる操作してないのに?
- セッションIDに「前使った時に選択してるけど未精算なもの」が入っている可能性

後者の問題からすると、閲覧時点ですでに存在 してないと困ったことになりそうですね。となると、その直前段階となる ログイン になりますね。
ログインに失敗してできてても無駄ですので、 ログインに成功した時 ということになりますね… あった、エですね。

設問2はどうかな?
問題文あまり関係ないし… セッションIDの重要なポイントについての確認です。
それは、 過去の情報から類推されてしまう可能性 です。
セッションIDは、もし誰かに借用されると、勝手にカートに対し出し入れできてしまう可能性が出てくるので、類推されると危ないわけです。なおかつ、その時のログイン状況に応じて随時作られていくようにしないといけませんし、再利用されてもいけません。だから設問1にもあるように (設問1空欄)にセッションIDを生成、ログアウト時に破棄 なんです。

ア: 会員IDなんて毎回同じじゃないですか! 論外です
イ: 確かにこれなら毎回違う、でも通し番号だったら類推できる可能性があるよね、無限に通し番号を入れてセッションを捏造すればいつかあたっちゃうかも! やっぱり論外
ウ: 十分に長いランダムなら類推が難しいし、ログアウト時に破棄されているなら大丈夫そうですね、保留
エ: 通し番号って…イと同じで論外です

ということで解答として使えるのは実質ウしかないというサービス問題というところでした。

ふぅ、長々書くと疲れます、ということで残りは次回。