Cookieでやりとりされるデータは、基本的には単なる文字列データであり、その意味付けや解釈はWebサーバによってのみ行われる。Webブラウザ側では、Webサーバから渡されたCookieデータをWebサーバにそのまま返すだけであり、その内容を解釈したり、改変したりすることはない。
以下に実際のWebブラウザに保存されているCookieデータを表示させた例を示す。
Cookieのデータは、基本的には「名前」とそれに対応する「値(実際には文字列)」、そして「属性」から構成される。
Cookieの規格で決められている仕様や属性を次にまとめておく。
項目 | 内容 |
---|---|
<名前>=<値> | Cookieの<名前>と<値>は=で結合して、Set-Cookie/Cookieヘッダフィールドの先頭にセットする |
Expires=<日時> | Cookieの有効期限(日時で指定。非推奨) |
Max-Age=<値> | Cookieの有効時間(秒単位で指定)。ExpiresもMax-Ageもない場合はWebブラウザのセッション終了まで有効(ブラウザを終了すると削除される) |
Domain=<ドメイン指定> | Cookieが有効なドメイン範囲の指定。指定されたドメインに含まれるならCookieが有効。Domain=がない場合は、現在のホストでのみ有効 |
Path=<パス指定> | Cookieが有効なパス範囲の指定。Path=がない場合は、現在のパス(URL)でのみ有効 |
Secure | HTTPS通信時にのみ有効。HTTPでの通信時には送信されない |
HttpOnly | これを付けておくと、HTTPプロトコルのCookieヘッダフィールドでのみ参照可能になる(JavaScriptのdocument.cookieなどから参照できなくなる)。セキュリティのために使われる |
主なCookie属性値 値の後に属性が続く場合は、「;」(半角のセミコロン)で区切られて並ぶ。 |
Cookieの名前や値をどう設定するかは、アプリケーションの設計者が決めることである。名前からその機能が推測できることもあるため、より安全なWebサイトにするためにはサイト全体をHTTPS化して通信内容を暗号化し、通信路上のCookie情報も保護すべきだろう。
上表のうち、特に重要な属性について、もう少し説明しておこう。
Webブラウザが受け取ったCookieデータは、基本的には、同じパス(URL)で次にGET要求などを実行するときにのみ返信される。
だが現実のWebサイトでは、最初にログインページ(例:https://example.com/login)で取得したCookieを、サイト内の他の場所(例:https://site1.example.com/app)へアクセスする場合にも使うだろう。しかし他の組織のサイトへアクセスする場合にCookieを渡してしまっては困る。
このような、いろいろなケースに対応するため、Cookieデータには、それを渡すドメインやパスの範囲を指定する属性が用意されている。それが「Domain=〜」と「Path=〜」である。先ほどのGoogle ChromeのCookie画面では、「ドメイン:」や「パス:」でこれらの情報を確認できる。
Domain=は、Cookieがどのドメイン内で有効かを表す指定である。例えば「Domain=example.com」とすると、example.comか、そのサブドメイン(例:www.example.comやapp.example.com)へアクセスする場合にも送信される。
Path=は、Cookieがどのパス(URL)内で有効かを表す指定である。例えば「Path=/」とすると、https://example.com/loginで取得したCookieはサイト全体で有効になる(例えばhttps://example.com/やhttps://example.com/app2などでも利用される)。
Cookieにはファーストパーティーやサードパーティーという分類がある。
「ファーストパーティーCookie(1st party cookie)」とは、アクセスしたドメインから発行されたCookieのことである。例えばhttps://example.com/にアクセスした時に得られた、domain=example.comという属性を持つCookieはファーストパーティーCookieである。
これに対して「サードパーティーCookie(3rd party cookie)」とは、アクセスしたドメインとは別のドメインから発行されたCookieのことを指す。例えばhttps://example.com/で表示されるコンテンツの中に、別のドメイン(https://ad.foobar-corp.com/)にある外部Webサーバで生成される広告が表示されているとする。その広告Webサーバから発行された(属性domain=foobar-corp.comの)CookieをサードパーティーCookieと言う。
この広告Webサーバが別のWebサイト(例:https://example.co.jp/)でも使われているとする。するとWebブラウザは、最初のWebサイトを訪れたときに受け取ったサードパーティーCookieを、その広告Webサーバに返す。その結果、同じユーザーが2つのサイトを使っていることが(広告Webサーバ側に)知られることになる。あるショッピングサイトで買い物をした結果、別のサイトを訪問しても同じようなお勧め商品が表示されることがあるが、それはこのサードパーティーCookieが使われているからである。
サードパーティーCookieはWebブラウザの設定で禁止できるようになっていることが多い。ただし、広告以外にも使われているため(例:多くのドメイン名が1つのWebサイト内に混在している場合など)、一律に全て禁止すると、通常のWebサイトアクセスもできなくなることがあるので注意する。
一度取得したCookieのデータは、その有効期限が切れるまでは有効である。そのため、他のWebブラウザに移行したり、他のPC上のWebブラウザに読み込ませたりしても、そのまま使える(ことが多い)。
例えばInternet ExplorerにはCookieデータのエクスポートやインポート機能が用意されているので([ファイル]−[インポートとエクスポート]メニュー)、これを使ってCookie情報を移行できる。もし移行せずにInternet Explorerを起動すると、サイトによってはまたログイン操作をやり直す必要がある。
Cookie情報はWebサイトごとに固有であり、あるサイトのCookieが他のWebサイトに渡されることはないはずである。だがWebブラウザの脆弱(ぜいじゃく)性などによってCookie情報が漏えいしてしまうことがある。
Cookie関連の脆弱(ぜいじゃく)性や攻撃手法としては例えば次のようなものがある。
■XSS(クロスサイトスクリプティング)
サイトの境界を越えてCookieの値を読み出せてしまう脆弱性。Cookieの値を読み出すようなJavaScriptコード(先の表「主なCookie属性値」のHttpOnlyの項目参照)をWebサイトに送り込んで実行させると、他のサイトのCookie情報(セッションIDなど)を窃取できる。
■HTTPヘッダインジェクション
WebサーバがHTTPの応答を返すとき、ヘッダ内容にSet-Cookie応答ヘッダを強制的に付加(=インジェクション、注入)し、任意のCookie情報を生成・送信する、という攻撃手法のこと。
いずれも十分な対策をWebサーバやWebブラウザ、Webアプリなどに施せば防げる脆弱性である。システムの管理者は常に脆弱性情報などに注意を払い、安全なシステムを構築しなければならない。
本記事ではHTTPのCookieについて見てきた。ステートレスなHTTPプロトコルにおいて、セッション管理などの機能を実現するCookieは現在のWebシステムには欠かせないものである。管理者はその機能や意味をしておきたい。
Copyright© Digital Advantage Corp. All Rights Reserved.