基本情報技術者 2015年 秋期 午後 問04
Webサイトにおけるセッション管理に関する次の記述を読んで、設問1～4に答えよ。
セッションとは、一連の処理の始まりから終わりまでを表す概念である。例えば、あるショッピングサイトでは、会員がログインし、その後、商品の選択、注文、決済など、何度もWebサイトへのアクセスを繰り返しながら商品を購入し、最後にログアウトする。このときの、ログインからログアウトまでが同じ一つのセッションである。
Webサイトへのアクセスに使うプロトコルであるHTTPではセッションの扱いについての規定はないが、WebサイトとWebブラウザの間でセッションIDを送受信することで、一連の通信を一つのセッションとして管理できる。ここで、セッションIDとはセッションごとに割り振られた一意の文字列である。
Webサイトは、セッションの開始とともにセッションIDを生成し、Webブラウザに送る。Webブラウザは、Webサイトから受信したセッションIDを含めたHTTPリクエストをWebサイトに送る。Webサイトは、同じセッションIDをもつHTTPリクエストを、同一セッションの一連のHTTPリクエストとみなす。一般に、会員IDや選択された商品の情報などのセッションに関係する情報は、Webサイト側がセッションIDに関連付けて管理する。
セッションIDは注意して取り扱う必要がある。例えば、セッションIDの有効期限をできるだけ短くしたり、セッションIDを推測しにくい文字列にしたり、セッションIDの送受信を暗号化されている通信路で行ったりするなど、セキュリティ上のリスクを抑える工夫をする。
セッションIDの送受信には、主に次に挙げる方法が用いられている。
(1) HTTPリクエストの拡張ヘッダやWebサイトがWebブラウザに送信するHTTPレスポンスの拡張ヘッダに、クッキーの値としてセッションIDを記載する。このとき、Webブラウザでクッキーの管理が有効になっている必要がある。
(2) HTML中のリンク先やフォームの送信先を示すURLの中にセッションIDを埋め込む（次の例では下線の箇所）。
例：<a href="https://www.example.com/?sid=セッションID">top</a>
(3) HTML中のフォームでフィールドhiddenにセッションIDを埋め込む（次の例では下線の箇所）。
例：<input type="hidden" name="sid" value="セッションID">
設問1：
問題文を見る 次の記述中のに入れる適切な答えを、解答群の中から選べ。
ショッピングサイトAでの商品購入の流れは図1のとおりである。注文と決済に必要な情報をセッションIDに関連付けて管理するため、ショッピングサイトAでは、閲覧者がaにセッションIDを生成し、ログアウト時に破棄することとした。
aに関する解答群
ア：サイトの閲覧を開始したとき
イ：商品を閲覧するたび
ウ：商品を選択するたび
エ：ログインに成功したとき
模範解答
a：エ
解説
解答の導き方
セッションは、ログインからログアウトまでの一連の利用を指します。セッションIDは、その一連の利用を識別するための一意の文字列です。WebサイトはセッションIDに会員IDや商品の情報を関連付けて管理します。
- 図1では、ログイン前にも商品を閲覧できます。一方、ログインに成功すると、その後は商品の閲覧や選択、注文、決済へ進めます。
- 注文や決済に必要な情報を同じセッションIDに関連付けるには、ログイン後の商品の閲覧から決済まで、同じセッションIDを使い続ける必要があります。図1では、商品の閲覧や選択を繰り返したり、注文や決済の後に商品の閲覧へ戻ったりする流れがあります。
- そこで、会員としての利用が始まる「ログインに成功したとき」にセッションIDを生成します。ログインに失敗した場合は、まだログイン後の購入手続に進んでいないため、生成するタイミングではありません。
- 商品を閲覧するたび、または商品を選択するたびに生成すると、セッションIDが変わってしまいます。注文や決済に必要な情報を一続きの利用として管理しにくくなります。
- ログアウトすると一連の利用が終わるため、そのときにセッションIDを破棄します。
誤りやすいポイント
- サイトの閲覧開始と、会員としての利用開始を混同すること
ログイン前にも商品を閲覧できますが、この問題で注文や決済の情報を扱う一連の利用は、ログイン成功後に始まります。 - 商品を閲覧・選択するたびにセッションIDを生成すること
同じ利用中にセッションIDを変えると、注文や決済に関する情報を同じセッションとして関連付けにくくなります。 - ログインに失敗した時点を選ぶこと
図1では、ログインに失敗すると再びログインに戻ります。ログイン後の購入手続へ進めるのは、ログインに成功した場合です。
FAQ
Q: ログイン前に商品を閲覧するためのセッションは必要ないのですか？
A: 問題が尋ねているのは、注文と決済に必要な情報を関連付けて管理するためのセッションIDを、いつ生成するかです。その目的に合わせると、会員としての利用が始まるログイン成功時が適切です。
A: 問題が尋ねているのは、注文と決済に必要な情報を関連付けて管理するためのセッションIDを、いつ生成するかです。その目的に合わせると、会員としての利用が始まるログイン成功時が適切です。
Q: 商品の選択後にセッションIDを生成してはいけないのですか？
A: 商品を選ぶ前のログイン後の操作も、同じ一連の利用に含まれます。選択後に生成すると、それより前の操作とは異なるIDになり、同じセッションとして管理しにくくなります。
A: 商品を選ぶ前のログイン後の操作も、同じ一連の利用に含まれます。選択後に生成すると、それより前の操作とは異なるIDになり、同じセッションとして管理しにくくなります。
Q: ログアウト時にセッションIDを破棄するのはなぜですか？
A: ログアウトで一連の利用が終わるためです。使い終わったセッションIDを残さないことで、ログアウト後にそのIDが引き続き使われるリスクを抑えられます。
A: ログアウトで一連の利用が終わるためです。使い終わったセッションIDを残さないことで、ログアウト後にそのIDが引き続き使われるリスクを抑えられます。
関連キーワード: セッション、セッションID、認証、状態管理
設問2：
問題文を見る セッションIDとして使う文字列として適切な答えを、解答群の中から選べ。
解答群
ア：会員IDと同じ文字列
イ：会員IDと通し番号を連結した文字列
ウ：十分に長いランダムな文字列
エ：通し番号を示す文字列
模範解答
ウ
解説
解答の導き方
この設問では、セッションごとに使うセッションIDとして、どのような文字列が適切かを考えます。セッションIDは、Webサイトが一連のアクセスを同じセッションのものと判断するための目印です。
本文には、セッションIDは「セッションごとに割り振られた一意の文字列」とあります。つまり、別のセッションと区別できる必要があります。また、本文には「セッションIDを推測しにくい文字列にしたり」とあり、他人に当てられにくいことも重要だと分かります。
選択肢を確認します。
- アの会員IDは、会員を識別するためのものです。同じ会員が別の買い物を始めても会員IDは変わらないため、セッションごとに異なるIDを割り振る目的に合いません。
- イの会員IDと通し番号を連結した文字列は、会員IDや番号から推測されるおそれがあります。セッションIDを推測しにくくするという条件に合いません。
- エの通し番号を示す文字列は、番号の並びから次の番号を予測しやすいため、他人に推測されるおそれがあります。
- ウの十分に長いランダムな文字列は、別のセッションと区別しやすく、値も予測されにくくなります。
したがって、条件に合うのはウです。
誤りやすいポイント
- 会員IDとセッションIDを同じものだと考えないようにします。会員IDは人を識別するためのものですが、セッションIDは一連のアクセスを識別するためのものです。
- 通し番号なら重複しにくいと考えても、番号の規則が分かれば次の値を予測できます。セッションIDには、重複しにくいことだけでなく、推測されにくいことも必要です。
- 「ランダムな文字列」だけでなく、「十分に長い」こともポイントです。文字列が長いほど、候補となる値が増え、偶然当てられる可能性を下げられます。
FAQ
Q: セッションIDは、利用者の名前や会員情報を表すものですか？
A: いいえ。セッションIDは、Webサイトが一連のアクセスを同じセッションとして扱うための目印です。会員情報などは、Webサイト側でセッションIDに関連付けて管理します。
A: いいえ。セッションIDは、Webサイトが一連のアクセスを同じセッションとして扱うための目印です。会員情報などは、Webサイト側でセッションIDに関連付けて管理します。
Q: セッションIDを他人に知られると、なぜ問題なのですか？
A: WebサイトがそのIDを使ってアクセスを同じセッションのものと判断するためです。他人に知られると、そのセッションの利用者になりすまされるおそれがあります。
A: WebサイトがそのIDを使ってアクセスを同じセッションのものと判断するためです。他人に知られると、そのセッションの利用者になりすまされるおそれがあります。
Q: ランダムに作れば、同じセッションIDが絶対に重複しませんか？
A: ランダムに作るだけで絶対に重複しないとは限りません。そのため、実際には十分に長い値を使い、必要に応じて重複がないか確認します。
A: ランダムに作るだけで絶対に重複しないとは限りません。そのため、実際には十分に長い値を使い、必要に応じて重複がないか確認します。
関連キーワード: セッション管理、セッションID、乱数、認証、セッション乗っ取り
設問3：
問題文を見る 次に示す表は、(A)～(C)の特徴と、本文中のセッションIDを送受信する(1)～(3)の方法の組合せを示したものである。表中のに入れる適切な答えを、解答群の中から選べ。
bに関する解答群
模範解答
b：ウ
解説
解答の導き方
この問題では、特徴 (A)～(C) が、セッションIDを送受信する方法 (1)～(3) のどれに当たるかを見分けます。まず、本文にある3つの方法を整理します。
- (1) は、クッキー（WebブラウザがWebサイトから受け取り、次の通信でも送る小さな情報）にセッションIDを入れる方法です。本文には、Webブラウザでクッキーの管理が有効である必要があるとあります。
- (2) は、URL（Uniform Resource Locator：Webページなどの場所を示す文字列）の中にセッションIDを入れる方法です。
- (3) は、HTML（HyperText Markup Language：Webページの内容や構造を記述する言語）のフォームにあるhiddenフィールドにセッションIDを入れる方法です。フォームを送信するときに、この値も一緒に送られます。
それぞれの特徴を、方法と結び付けます。
-
(A)「Webブラウザのアドレスバーに表示されるURLの中にセッションIDが含まれる」
セッションIDがURLの中にあるので、URLに埋め込む方法である (2) です。本文の例でも、URLの「sid=」の後にセッションIDが入っています。 -
(B)「Webブラウザの設定次第で利用できないことがある」
クッキーの管理が無効になっていると、クッキーにセッションIDを入れる方法は利用できません。本文にも、(1)を使うにはWebブラウザでクッキーの管理が有効である必要があるとあります。したがって、(1) です。 -
(C)「タグ<a>で指定されたリンクのクリックではセッションIDが送信されない」
hiddenフィールドはフォームに含まれる情報です。リンクをクリックしたときはフォームを送信しないため、hiddenフィールドに入れたセッションIDは送られません。したがって、(3) です。
一方、URLにセッションIDを埋め込む方法なら、リンク先のURLにセッションIDを含められます。
以上から、表の上から順に当てはまるのは、(2)、(1)、(3)です。解答群では ウ に当たります。
誤りやすいポイント
- (A)は「アドレスバーに表示される」という点が手掛かりです。URLにセッションIDを埋め込む方法と結び付けます。
- (B)をhiddenフィールドと間違えないようにします。ブラウザのクッキー管理の設定が関係するのは、(1)です。
- hiddenフィールドの値はフォーム送信時に送られます。リンクをクリックするだけでは送られないため、(C)は(3)です。
- クッキーとURLのどちらも、Webブラウザからの通信にセッションIDを含められます。違いは、セッションIDをクッキーに保存するか、URLに含めるかです。
FAQ
Q: URLにセッションIDを入れると、なぜアドレスバーに表示されるのですか？
A: セッションIDがURLの一部になるためです。そのURLを開くと、アドレスバーにもセッションIDを含むURLが表示されます。
A: セッションIDがURLの一部になるためです。そのURLを開くと、アドレスバーにもセッションIDを含むURLが表示されます。
Q: hiddenフィールドは、リンクをクリックしたときにも送られますか？
A: 送られません。hiddenフィールドはフォームの項目なので、フォームを送信するときに送られます。
A: 送られません。hiddenフィールドはフォームの項目なので、フォームを送信するときに送られます。
Q: クッキーの管理が無効だと、セッション管理そのものができなくなりますか？
A: クッキーを使う方法 (1) は利用できないことがあります。ただし、本文にあるように、URLに埋め込む方法やフォームのhiddenフィールドを使う方法もあります。
A: クッキーを使う方法 (1) は利用できないことがあります。ただし、本文にあるように、URLに埋め込む方法やフォームのhiddenフィールドを使う方法もあります。
関連キーワード: セッション管理、セッションID、クッキー、URL、hiddenフィールド
設問4：
問題文を見る 次の記述中のに入れる正しい答えを、解答群の中から選べ。
クッキーは名前と値の組であり、WebサイトとWebブラウザでそれぞれ管理される。Webサイトは、Webブラウザに管理させたいクッキーを、Webブラウザに送信するHTTPレスポンスの拡張ヘッダに記載する。Webブラウザは、Webサイトから受信したクッキーを、そのWebサイトに送信するHTTPリクエストの拡張ヘッダに記載する。
クッキーの値としてセッションIDを記載することで、WebサイトとWebブラウザの間で、セッションIDを送受信することができる。
Webサイトは、HTTPレスポンスに記載するクッキーに、付加情報として送信先ドメイン名の指示を加えることができる。これは、Webブラウザに対し、当該クッキーをどのドメイン又はホスト宛てのHTTPリクエストに記載すべきかを指示するもので、HTTPレスポンスの送信元ホスト名か、より上位のドメイン名が指示されているクッキーだけが有効である。例えば、ホストwww.example.comの上位のドメインはexample.comとcomである。ただし、多くの組織の上位ドメインとなるcomやorgなどは有効とはみなさない。Webブラウザは、有効でないドメイン名が指示されたクッキーを管理しない。
Webブラウザは、管理しているクッキーを、指示されたドメイン名と等しいホストか、より下位ドメインのホスト宛てに送信するHTTPリクエストに記載する。例えば、送信先ドメイン名として、example.comが指示されているクッキーは、example.comの下位ドメインのホストである、www.example.comやwww.foo.example.com宛てに送信するHTTPリクエストに記載される。
送信先ドメイン名としてexample.comが指示されたクッキーをwww.example.comから受け取ったWebブラウザは、www.example.comの他、www2.example.comなどのexample.comの下位ドメインのホストへ送信するHTTPリクエストにも、当該クッキーを記載する。
クッキーを受け入れる設定であって、かつ、クッキーを一つも管理していないWebブラウザからhttp://www.foo.example.com/index.htmlにアクセスし、その応答として受け取ったHTTPレスポンスには、表1に挙げる名前をもつクッキーが含まれており、それぞれに、送信先ドメイン名の指示が付加されていた。Webブラウザは、このうちのc個のクッキーを管理する。この直後に、同じWebブラウザからhttp://www.bar.example.com/index.htmlにアクセスするときにHTTPリクエストに記載されるクッキーは、dである。
cに関する解答群
ア：1
イ：2
ウ：3
エ：4
オ：5
dに関する解答群
ア：c1
イ：c1とc2
ウ：c1とc5
エ：c4とc5
オ：c5
模範解答
c：ウ、d：ア
解説
解答の導き方
この設問では、最初のアクセスで受け取ったクッキー（Webブラウザに保存され、後の通信にも付けて送れる名前と値の情報）のうち、どれを保存できるか、さらに次のアクセスでどれを送るかを判断します。
HTTP（Hypertext Transfer Protocol：WebブラウザとWebサイトが情報をやり取りするための通信規則）では、クッキーの送信先ドメイン名が、受け取ったWebサイトのホスト名と同じか、その上位のドメイン名であれば有効です。ホスト名は通信先のサーバを表す名前です。
最初にアクセスしたホスト名は、www.foo.example.comです。ここから受け取ったクッキーについて、送信先ドメイン名を順に確認します。
本文には「送信元ホスト名か、より上位のドメイン名」が有効とあります。したがって、保存できるのはc1、c2、c3の3個です。cに入る選択肢はウです。
- c1の送信先ドメイン名はexample.comです。www.bar.example.comはその下位ドメインなので、送信されます。
- c2の送信先ドメイン名はfoo.example.comです。www.bar.example.comはその下位ドメインではないので、送信されません。
- c3の送信先ドメイン名はwww.foo.example.comです。www.bar.example.comはその下位ドメインではないので、送信されません。
よって、HTTPリクエストに記載されるのはc1だけです。dに入る選択肢はアです。
誤りやすいポイント
- example.comの下位にあるホストなら、どれも同じ範囲だと思い込まないようにします。foo.example.comとbar.example.comは、どちらもexample.comの下位ですが、foo.example.comはbar.example.comの上位ではありません。
- www.example.comは、www.foo.example.comの上位ドメインではありません。ドメイン名を右側からたどると、www.foo.example.comの上位はfoo.example.com、example.comの順です。
- 受信したクッキーが、将来アクセスするホスト宛てのものだからといって保存できるとは限りません。最初に受け取ったWebサイトに対して有効な指示かどうかを、先に判定します。
FAQ
Q: c2は、名前にwwwが含まれていません。それでも保存できるのですか？
A: 保存できます。foo.example.comはwww.foo.example.comの上位ドメインだからです。
A: 保存できます。foo.example.comはwww.foo.example.comの上位ドメインだからです。
Q: c5は次にアクセスするwww.bar.example.com向けですが、なぜ送信されないのですか？
A: c5は最初にアクセスしたwww.foo.example.comから受け取っています。www.bar.example.comはそのホスト名でも上位ドメインでもないため、クッキー自体を保存できません。
A: c5は最初にアクセスしたwww.foo.example.comから受け取っています。www.bar.example.comはそのホスト名でも上位ドメインでもないため、クッキー自体を保存できません。
Q: c1は、www.bar.example.com以外のホストにも送信されますか？
A: example.comと同じホストや、その下位ドメインのホストへのリクエストにも送信されます。
A: example.comと同じホストや、その下位ドメインのホストへのリクエストにも送信されます。
関連キーワード: クッキー、HTTP、ドメイン名、ホスト名、HTTPリクエスト
