HTTPクッキーの属性について

HTTPの属性について、詳しく調べる必要があったため、その備忘録。

WEBアプリケーションのセキュリティに関しては、下記の本で学んだため、再度、本書を本棚より引っ張りだした。

HTTPプロトコルは、サーバ側では状態を保持しない（ステートレス）なものであるため、アプリケーションで状態を保持したい要求が発生する。

例えば、下記用のもの。

・オンラインのショッピングサイトで、商品カタログから「購入」ボタンを押した商品を覚えておく。
・ログインした後で、認証状態を覚えておく。

など。

上記のように、アプリケーションの状態を覚えておくことをセッション管理と呼ぶ（と思う）このセッション管理をHTTPで実現する目的でクッキー(Cookie)という仕組みが導入された。

下記のような、cakePHPを利用したWEBアプリケーションのログイン画面があったとして、ログインを実行する。

ログインアクションを実行した際のHTTPリスクエスとレスポンスヘッダは下記のようになる。(Fiddlerで確認）

このとき、サーバ側でログインの状態を覚えておくようにレスポンスヘッダーに「Set-Cookie」でクッキーをブラウザに設定される。

ログイン後の画面。

ログイン以降は、設定されたクッキーを今度は、リクエストヘッダーの「Cookie」ヘッダに設定し、リクエストされることで、アプリケーション上で状態（認証状況など）が覚えられる。

クッキーを発行する際は、様々なオプションの属性を設定可能。主な属性は下記のとおり。

属性	意味
Domain	ブラウザがクッキー値を送信するサーバのドメイン
Path	ブラウザがクッキー値を送信するURLのでディレクトリ
Expires	クッキー値有効期限。指定しない場合はブラウザの終了まで
Secure	SSLの場合のみクッキーを送信する
HttpOnly	この属性が指定されたクッキーはJavaScriptからアクセスできない

このうち、セキュリティ上重要な属性は、Domain、Secure、HttpOnly

クッキーは、デフォルトでは、クッキーをセットしたサーバにのみ送信される。

セキュリティ上これが最も安全となるが、複数のサーバに送信されるクッキーを生成したい場合は、 Domain属性を指定可能。

例えば、「Domain=example.jp」という属性を指定したクッキーがどのサーバに送信されるかは下記のとおり。

異なるドメインに対するクッキーが設定できると、セッションIDの固定化攻撃などの手段として、利用されるので、通常、最も送信範囲が狭くなる「Domain属性をしていない」状態が良いとされる。

Secureをつけたクッキーは、SSL通信の場合のみサーバに送信される。

一方Secure属性のついていないクッキーは、SSL通信かどうかに関係なく、常にサーバに送信される。

ただし、httpsとhttpが混在するサイトでは、セッションIDに対して、クッキーのセキュア属性を指定すると、httpの場合、クッキーが送信されなくなるため、アプリケーションが動作しなくなることがあるので、注意する。

HttpOnly属性は、JavaScriptからアクセスできないクッキーを設定する。

クッキーとして、格納されたセッションIDを盗み出す攻撃に典型例はクロスサイトスクリプティング攻撃により、JavaScriptを悪用してクッキーを盗み出すというものがある。

HttpOnly属性をつけることで、クロスサイトスクリプティングを完全に防ぐことはできないが、攻撃を難しくすることはできるため、セッションIDには、HttpOnly属性をつけるとよいとされる。

My Tracking