amareloのブログ(仮)

IT系勉強会で感じた想いや知見をメインに書いていきます。

cookieによるセッション管理とcookieの属性について

ウェブ・セキュリティ基礎試験勉強記事の2つ目。今回はcookie(クッキー)によるセッション管理とcookieの属性について書きます。

目次

参考文献

cookieとは

  • ステートレスなHTTPの仕様をそのままに、HTTPの仕様を拡張してWebアプリケーションとWebブラウザの間で情報交換、セッション管理を実現できるようにするための技術。
  • cookieが保持できる値の個数や文字列長には制限があること、利用者本人がcookieの値を参照変更できることから、秘密情報の格納には向かない。

cookieによるセッション管理

以下のような順番でセッション管理をします。

  • Webサーバからのレスポンス時に、WebサーバはCookieにセッションIDを格納します。
  • レスポンスヘッダの[Set-Cookie:]により、Webサーバはブラウザに対してCookie(セッションID)を保存するよう指示します。
  • cookie値を覚えたブラウザは、その後同じサイトにリクエストを送る際に覚えたCookie(セッションID)を送信します。
  • WebサーバはCookieを受け取ると、Cookieに格納されたセッションIDを基にしてメモリ上に持っているクライアントの状態を復元します。

セッション管理の要件

セッションIDは連番などではだめで、以下のような要件があります。

  • 三者がセッションIDを推測できないこと。
  • 三者からセッションIDを強制されないこと。
  • 三者にセッションIDが漏洩しないこと。

実際にはセッションIDの生成を自分たちで開発するのではなく、Webアプリケーション開発ツールにて提供されるセッションIDを利用した方が望ましいです。

セッションID漏洩の原因

セッションIDが漏洩すると他の利用者になりすましされる恐れがあります。セッションIDの漏洩の原因は、以下の通りです。

cookieの属性

cookieの属性は以下の通りです。

属性 意味
Domain ブラウザがcookie値を送信するサーバのドメイン。デフォルトではcookieをセットしたサーバのみに送信される。
Path ブラウザがcookie値を送信するURLディレクト
Expire cookieの有効期限(指定しない場合は、ブラウザ終了まで。)
Secure HTTPSの場合のみcookieを送信
HttpOnly JavaScriptからcookieにアクセス不可にする。

Domain設定

複数のサーバにcookieを送信したい場合は、Domain設定をします。 例えば、[Domain=example.jp]と設定すると、

  • a.example.jp 、b.example.jpにcookieが送信される。
  • a.examle.comには送信されない。
  • c.example.jpにはcookieを送信したくなくても送信されてしまう。

という動きになります。

ドメイン指定によりcookie漏洩(セッションID漏洩)の恐れがありますので、Domain設定は通常は設定しないことが望ましいです。

Secure属性

Secure属性設定を指定すると、HTTPSリクエストにのみcookieを送信します。これがないと、HTTPリクエストにもcookieを送信してしまいます。 平文でセッションIDを送ることになりますので、盗聴のリスクが発生します。

cookieにセキュア属性をつけることで、HTTPリクエストへのcookie送信を止めることができます。 ただ、HTTP/HTTPS混在のWebサイトの場合は、Webアプリケーションが動かなくなる恐れがあります。その場合は、別途トークンをチェックする対策が必要となります。

HttpOnly属性

JavaScriptからcookieにアクセスできないようにするための設定です。 XSSの影響を軽減する効果があります。ただし、根本的な対策にはならないため、XSSそのものの対策はする必要があります。

最後に

今回はcookieについてまとめました。HTTP(S)もcookieについても、この先脆弱性対策について理解するためにはちゃんと理解しておいた方が良いなと改めて思いました。 まだまだ「完全に理解した」わけではないので、たびたび見直しながら学習したいと思いました。