3 Minutes NetWorking
No.75

3Minutes NetWorking

第75回HTTP(6) Cookie

■ セッションステートレス

インター博士

さて、ネット君。HTTPの基本動作、リクエストとレスポンスについては大体説明したわけだ。

ネット助手

はい、メソッドと、ステータスコードですよね。

インター博士

まぁ、それだけではないが、いいだろう。
メソッドでどのような要求かを伝え、それに対する応答をステータスコードで伝える。もちろんデータのやりとりもあるわけだ。

ネット助手

はいはい、でしたよ。

インター博士

さて、ここで思い出して欲しいのは、セッションという言葉だ。

ネット助手

せっしょん?
OSIモデルのレイヤ5ですか?

インター博士

うむ、第49回で説明したセッション層のセッションだ。
どういう意味だった?

ネット助手

プロセス間の話し合いの管理だと。

インター博士

そうだ。つまり「要求元」プロセスと、「宛先」プロセスがお互いを認識し、データのやりとりを行うわけだ。
データのやりとりは一連の流れとして管理される。

ネット助手

でしたね。

インター博士

セッションの開始と切断は、「データ転送の開始と終了」を意味する。

ネット助手

コネクションは「データ転送用回線の接続・切断」で、複数のコネクションで1つのセッションを作るんでしたよね。

インター博士

そうだ。つまり、データのやりとりはセッション単位で管理される。 逆に言えば、セッションが違えば、管理はできない、ということになるな。

ネット助手

そうなりますね。

インター博士

さて、ここで問題になるのは、HTTPでは1ページのやりとりが1つのセッションなのだよ。

ネット助手

はぁ。

インター博士

何処が問題かわかってないようだな?

ネット助手

ページのやりとりが1セッション。
何か問題が?

インター博士

こういうことだ。

[Figure75-01:セッションの問題]

ネット助手

前のセッションとは別物……、何か問題が?

インター博士

いつも言ってることだが、もうちょっと想像したまえ。
サーバは前のアクセスの状態を記憶できないと言ってるのだぞ。

ネット助手

はぁ。

インター博士

あ〜、じれったい。つまり、こういうことだ。

セッションの問題・2

[Figure74-02:セッションの問題・2]

インター博士

このように、初めてのアクセスのユーザと、2回目以降のアクセスのユーザでページを別にしたい場合、どこで判断するのだ?

ネット助手

あ〜、なるほど。そういえばそうですね。

インター博士

相変わらずその鈍さには感服する

ネット助手

えへへ。

インター博士

褒めてねぇ

ネット助手

はぅっ。

インター博士

ともかくだ、同一のセッションならば「同じ相手からのアクセス」だと認識できるが、一度セッションが切断されてしまうと、前のことは覚えていられないのだよ。ネット君のように

ネット助手

は〜。アクセスしてきたホストが前のホストかどうかわからないのですね、僕のように。
…………僕のように、ってのはとても納得がいかないのですが?

インター博士

そうか? 我ながら賞賛に値する比喩だと思ったのだが。
ともかく、これをHTTPのセッションステートレス問題という。

ネット助手

せっしょんすてーとれす?

インター博士

セッションの状態(ステート)を保持しない(レス)なわけだな。

ネット助手

あ〜、前にアクセスしたという「状態」を覚えていない、という意味ですか。

■ Cookie

インター博士

このサーバは前のセッションと今回のセッションが同一のホストからのものか識別できないというセッションステートレス問題だが。
ショッピングサイトなどのサイトでは結構困るわけだ。

ネット助手

ショッピングサイト?
あ〜、「買い物カゴ」とかですか?

インター博士

うむ。「買い物カゴ」に前のページで買った品物がないと、何が「買い物カゴ」だ、という話になるな。
だが、通常のHTTPではページが切り替わった時点でセッションが切断され、前の状態は保存されなくなる。

ネット助手

ってことは、「買い物カゴ」はページが切り替わるたびに真っ白になるんですね。
それは見事に意味がないですね。

[Figure75-03:買い物カゴで起こりうる事]

インター博士

なので、何とかして「今アクセスしているホストは前回アクセスしてきたホストと同一だ」と識別させなければならない。
さてどうする?

ネット助手

どうすると言われましても。

インター博士

ふむ。例えば、客の顔を覚えられないネット君のような店員がいるビデオレンタル店があるとする。
さて、この店と店員は来た客が会員かどうかどうやって判断する?

ネット助手

「僕のような」という形容詞はどうかと思いますが。
そうですね、普通は会員証を見せてもらいますよね。

インター博士

そう、最初に来た時点で「会員証」を渡し、以降その「会員証」を見せてもらうことで、「前回来た客だ」ということを識別するわけだ。

ネット助手

……つまり、最初のアクセス時に「会員証」を渡して。
それ以降のアクセスでは「会員証」を見せてもらえばいいんですね?

インター博士

そういうことだ。
この「会員証」をCookieと呼ぶ。

ネット助手

くっきー?
あの、お菓子のクッキー?

インター博士

そうだ。ネットスケープ社がそう名付けたのだ。
実を言うと、このCookie、正式な標準規格ではない▼ link

ネット助手

そうなんですか?

インター博士

ネットスケープ社が開発し、その後それが広まって業界標準になったという代物だ。
さて、そのCookieがどのように使われるかだが。▼ link

ネット助手

はい。

インター博士

先ほどの「会員証」の流れを思い出しつつ、以下の図を見てもらおう。

[Figure75-04:Cookie]

ネット助手

は〜。「会員証」を渡す、わけですね。それがCookieだ、と。

インター博士

そうだ。まず、識別用の値などと共にCookieを作るようにサーバからクライアントへレスポンスが返るわけだ。

ネット助手

え〜っと、それって、Cookieを作らせるためだけに送るんですか?

インター博士

ん? あぁ、データを返す時に一緒にだ。
「これが要求したページのデータです。それとこの値のCookieを作ってください」と返すわけだな。

ネット助手

なるほど。

インター博士

つまり、このCookieを使うことにより擬似的にセッションを作り出すことができるわけだ。

ネット助手

擬似的にセッション……。

インター博士

Cookieのおかげで前回のアクセスと、今回のアクセスが同一のホストだとわかるわけだろう?
つまり、前回のセッションの「続き」が可能になるわけだ。

ネット助手

あ、なるほど。2つのセッションがつながってるように見せかけることができるわけですね。

インター博士

そういうことだ。
さて、この時HTTPで使用するのは「Set-Cookie」メッセージヘッダだ。

ネット助手

せっとくっきー?
え〜っと、第73回の一覧表にはなかったですよ?

インター博士

だから、ネットスケープ社が作ったといっただろう。
一方、クライアントからCookieの内容を送る時は「Cookie」メッセージヘッダを使う。

Cookieのメッセージヘッダ

[Figure74-05:Cookieのメッセージヘッダ]

ネット助手

ははぁ。レスポンスの「Set-Cookie」の後ろに書いてある内容が識別情報なんですね。

インター博士

そういうことだ。
次に同じサイトを見に行く場合、リクエストには「Cookie」の後ろにその識別情報を入れるわけだ。

ネット助手

なるほどなるほど。

■ Cookieの中身

インター博士

さて「会員証」たるCookieだが、その中身に何が書かれているかというと。

ネット助手

いうと?

インター博士

1つだけ書くことが決められている。その他はサーバが任意に決める

ネット助手

たった1つだけですか?

インター博士

そうだ。それ以外は任意だ。
その1つの必須のものは、Cookieの名前だ。

ネット助手

名前?

インター博士

うむ。なお、Set-Cookie、Cookieメッセージヘッダには以下のように値が記入される。

  • Set-Cookie:名前 = 値 ; Expire = 値 ; 属性 = 属性値 ; ………
ネット助手

なんとか イコール なんとかの値 セミコロン、ですか?

インター博士

そういうことだ。

ネット助手

へ〜。

インター博士

基本的には以下のようなものをCookieには書くことになっている。
ただし、最初の名前以外はすべて必要なものだけ書けばいいことになっている。

  • 名前
  • 有効期限(Expire)
  • パス属性(path)
  • サーバドメイン名(domain)
  • その他サーバが処理に必要な識別情報
ネット助手

名前、有効期限はわかるけど、パス属性? サーバドメイン名?

インター博士

それについては順に説明していく。
例えば、以下のようになっていた場合。

  • Set-Cookie:userid = 123 ; Expire = Thursday, 30-Jun-2005 00:00:00 GMT ; path = /net/ ; domain = www.3min.net ; username = prof;
インター博士

これを先ほどのもの説明で解説すると。

  • 名前(userid) … 123
  • 有効期限(Expire)… 2005/06/30(木) 0時0分0秒
  • パス属性(path) … /net/
  • サーバドメイン名(domain)… www.3min.net
  • その他サーバが処理に必要な識別情報(username) … prof
インター博士

こうなる。

ネット助手

は〜。
名前は必ずuseridなんですか?

インター博士

いや、名前の名前、つまりCookieの名前と、その値は好きにつけることができる。
この場合名前としてuserid、その値として123とした、ということだな。

ネット助手

その他のサーバが処理に必要な識別情報ってのは1つだけしか駄目なんですか?

インター博士

この例では1つだが、好きなだけつけることができる。
「username = prof ; job = teacher ; country = japan ; …」など可能だ。

ネット助手

処理に必要なら必要な分OKってことですね。

インター博士

そういうことだな。

ネット助手

なるほど。

■ Expire

インター博士

Cookieは、もしCookieの中身にExpireがあった場合、ファイルとして保存される
保存される場所は、InternetExplorerなら、「\Documents and Settings\(ユーザ名)\Local Settings\Temporary Internet Files」になる。

ネット助手

ファイルとして保存されるんですか?
じゃあ、中を見ることができますね。

インター博士

うむ、中を見たい時、手っ取り早いのは以下の方法だな。

Cookieの保存先

[Figure74-06:Cookieの保存先]

ネット助手

インターネットオプションって、IEの「ツール」の「オプション」でしたっけ?

インター博士

露骨な説明ありがとう。たまには助手らしいことをするな。
ま、ともかく「インターネットオプション」で「インターネット一時ファイル」の「設定」の「ファイルの表示」でその保存先フォルダを見ることが出来る。

ネット助手

へ〜………。
なんか、開くと一杯ファイルがありますよ? どれです?

インター博士

「インターネットアドレス」のところが「Cookie」で始まるファイルだ。
このようにExpireが指定されていた場合、保存されることになる。

ネット助手

指定された場合? 指定されない場合は保存されないんですか?

インター博士

そうだ。Expireがない場合はファイルとして保存されずにブラウザが閉じるまでしか使われない。
これはセッションCookieと呼ばれる。

[Figure75-07:セッションCookie]

インター博士

このような動作になる。

ネット助手

つまり、同じブラウザで同じサーバにアクセスしている時だけ使うことができるわけですね?

インター博士

そういうことだな。その一連のやり取り(セッション)だけしか使えないから「セッションCookie」というわけだ。

ネット助手

へ〜。でも、ずっと保存しておいたっていいのに。

インター博士

そう思うのも無理はないが、ファイルとして保存しておいて、後でも再利用可能にしておくとセキュリティ上問題がある。クロスサイトスクリプティングなどによりそのCookieが奪われてしまうことがある。▼ link

ネット助手

盗まれちゃうんですか?

インター博士

そうだ。なので、重要なものを情報としてCookieとして使う場合は、セッションCookieにして保存しないのがお約束だ。

ネット助手

重要なものって?

インター博士

名前、住所、電話番号、クレジットカード番号、パスワード、その他もろもろだな。

ネット助手

あ〜、それは確かに盗まれると困りますよねぇ。

■ PathとDomain

インター博士

さて、Cookieの中身についてもう1つ話そう。
サーバからSet-Cookieとして書かれている情報を、Cookieで送り返すわけなんだが。

ネット助手

はい。

インター博士

どのサーバに送り返すか、という問題点がある。
つまり、Set-Cookieを送ってきたサーバにのみ、Cookieを返さなければならない。

ネット助手

そりゃそうですね。全然関係のないサーバにCookieを送ったって意味ないですもんね。

インター博士

うむ、そうだろう。それを識別する値がDomainなのだよ。
このDomainに書かれたドメイン名を持つサーバに対してのみそのCookieを返す

Cookieの送り先サーバ

[Figure74-08:Cookieの送り先サーバ]

インター博士

上の例の場合、Set-CookieのDomainの値が「www.3min.net」なので、そのサーバにはCookieを送るが、「www.30min.com」には送らない、ということだな。

ネット助手

なるほど。

インター博士

ただし、以下のような場合はOKだ。

Cookieの送り先サーバ・2

[Figure74-09:Cookieの送り先サーバ・2]

ネット助手

Domainが3min.co.jpの場合、www.3min.co.jpとwww2.3min.co.jpならOK?
ドメイン名があってればOKってことですか?

インター博士

ドメイン名があっていれば、というか。
ドメイン名の後ろから確認していって、一致すれば、だな。

ネット助手

ドメイン名を後ろから…、あ〜、なるほど。
なんか後ろから確認していくなんてDNSみたいですね。

インター博士

まぁ、確かに似ているな。
それともう1つある。サーバのドメイン名が同じでも、サイトが違う場合がある。

ネット助手

サイト?

インター博士

つまり、「http://www.3min.net/net/」と「http://www.3min.net/emi/」では別人のサイトの可能性があるだろう?
それなのにサーバのドメイン名が同じだから、とCookieを送ってしまってはまずいだろう。

ネット助手

それもそうですね。

インター博士

よって、Pathに書かれたURIを持つサイトに対してのみそのCookieを返す形にする。

Cookieの送り先サイト

[Figure74-09:Cookieの送り先サイト]

ネット助手

ドメイン名の後ろの部分とPathが一致しないと駄目なんですね。

インター博士

そういうことだ。なお、Pathが「/」だけの場合は、そのサーバすべてのサイトという意味になる。
また、先ほど同様、「Path = /net/」でも、「/net/study」や「/net/diary」のような下位フォルダには送ることになる。

ネット助手

ははぁ、考えられてますねぇ。

インター博士

もし、DomainやPathがSet-Cookieで省略されていた場合、クライアントは保存する際にそのサーバのドメイン名をDomainに、そのサイトをPathに自動的に入れて保存する。

ネット助手

なるほど、省略されたからと言って無差別に送るわけではないんですね。

インター博士

今回はこのぐらいにしておこう。

ネット助手

はい。

インター博士

もうちょっとHTTPの話が続くぞ。

ネット助手

多いですね、HTTP。

インター博士

そうだな、現在最も人気のあるプロトコルだからな。利用法も多いのだよ。
では、また次回。

ネット助手

了解です。 3分間ネットワーキングでした〜♪

セッションステートレス
[Session Stateless]
Cookie
読みは「クッキー」。
本来の意味は「小さなプログラム・データ」の意味。
業界標準
実際はRFC2965で標準化されましたが、こちらはほとんど使われていません。
クロスサイトスクリプティング
[Cross Site Scrpiting]
「XSS」と略すことが多い。
XSSに脆弱なサーバを通して、攻撃者が悪意のあるスクリプトを実行させる方法。
参考リンクも参照のこと。
ネット助手ネット君の今日のポイント
  • HTTPはセッションステートレスである。
    • サーバはアクセスの状態を保存できない。
    • 前回のアクセスと今回のアクセスの関係を識別できない。
  • Cookieを使って擬似的なセッションを作り出すことができる。
    • HTTPレスポンスにSet-Cookieで識別情報を入れる。
    • HTTPリクエストの際、Cookieで識別情報を入れて送り返す。

3 Minutes NetWorking No.75

管理人:aji-ssz(at)selene.is.dream.jp