My Photo

« クッキーの不適切な利用 | Main | 秀丸エディタのマクロにおける配列 »

December 22, 2013

クッキーのSecure属性不備

発生箇所 セッションIDを踏めてクッキーを発行している箇所すべて
影響を受けるページ HTTPS通信を利用し、かつ認証のあるページすべて
影響の種類 成りすまし
利用者の関与の度合い HTTPSのみのサイトの場合は必要(リンクのクリックなど)
HTTPとHTTPS混在のサイトでは不要

概要

クッキーにはSecureという属性があり、これを指定したクッキーはHTTPSの場合のみブラウザからサーバに送信される。アプリケーションがHTTPS通信を利用していても、Secure属性のついていないクッキーは平文で送信される場合があり盗聴される可能性がある。
HTTPとHTTPSの混在するサイトでは、セッションIDに対してクッキーのSecure属性を設定するとアプリケーションが動かなくなる場合がある。その場合、セッションIDとは別にトークンをSecure属性付きクッキーとして発行して、ページ毎に確認する方法がある。

攻撃手法

次の手順で平文のクッキーがネットワーク上に流れる。

まず、HTTPSでかつSecure属性のつかないクッキーを発行するページを閲覧し、ブラウザーにクッキーをセットする。例としてURLは https://www.example.jp/set_non_secure_cookie.php とする。
次に罠ページを閲覧する。罠ページには下記のような見えないimgタグ(幅と高さが0)が含まれている。

<img src="http://www.example.jp:443/trap/ width="0" height="0" />

URLで指定されたポート番号443はHTTPSのデフォルトポートだが、スキームが「http:」と指定されているのでこのリクエストは暗号化されずに送信される。ブラウザにクッキーを送信させるのが目的なので、URLの画像はなくても攻撃は成立する。
攻撃者がこの暗号化されていないクッキーを盗聴できる場合、セッションハイジャックに悪用できる。

脆弱性の原因

直接の原因は単にSecure属性を付けていないというだけのことだが、Secure属性を付けない主な原因は以下の2種類があると思われる。

  • 開発者がSecure属性について知らない。
  • Secure属性を付けるとアプリケーションが動かなくなる。

クッキーにSecure属性が付けられないアプリケーション

Webアプリケーションの中にはHTTPとHHTPSの両方を使うものがある。多くのショッピングサイトは、カタログページで商品を選ぶ際にはHTTPを、商品を選び終わって決済する段階ではHTTPSを利用する。
HTTPとHTTPSが混在するWebアプリケーションの場合、セッションIDを保持するクッキーにSecure属性を設定することは困難である。仮にセッションIDのクッキーにSecure属性を付けると、HTTPのページではセッションIDのクッキーが受け取れないのでセッション管理機構が使えなくなる。HTTP側のページでもショッピングバスケットの実現などにセッション管理機構は利用したいので、HTTPSを利用するサイトの多くがセッションIDのクッキーに対してSecure属性を付けていないのが現状である。

対策

セッションIDのクッキーにSecure属性を付ける

クッキーのSecure属性不備の対策はクッキーにSecure属性を付けることである。
PHPではphp.iniに以下の設定をする。

session.cookie_secure = On

Aapache Tomcatの場合、HTTPS接続されたリクエストに対して、セッションIDのクッキーには自動的にSecure属性が設定される。

トークンを用いた対策

セッションIDを保持するクッキーにSecure属性が付けられない場合、トークンを利用してセッションハイジャックを防止する方法がある。
トークンを保持するクッキーにSecure属性を付けることによって、HTTPページとHTTPSページでセッションを共有しつつ、仮にセッションIDを盗聴された場合でもHTTPSページはセッションハイジャックを防止できる。
トークンを設定するコードのサンプル。

// /dev/urandomによる擬似乱数発生器
function getToken() {
	$s = file_get_contents('/dev/urandom', false, NULL, 0, 24);
	return base64_encode($s);
}

// ここまでで認証が成功していると想定

session_start();
session_regenerate_id(true);	// セッションIDの再生成
$token = getToken();	// トークンの生成
// トークンクッキーはSecure属性を付けて発行する
setcookie('token', $token, 0, '', '', true, true);
$_SESSION['token'] = $token;

トークンを確認するコードのサンプル。

session_start();
// ユーザIDの確認(省略)

// トークンの確認
$token = $_COOKIE['token'];
if (!$token || $token != $_SESSION['token']) {
	die('認証エラー。トークンが不正です。');
}

HTTPSでトークン設定のページにアクセスしトークン確認のページに遷移すると、トークンの確認に成功する。
HTTP(非SSL)で同じ遷移をすると、トークンのクッキーはSecure属性付きなのでトークン確認のコードはトークンを受け取れず、トークン確認は失敗する。

トークンにより安全性が確保できる理由

  • トークンは認証成功時に一度だけサーバから出力される。
  • トークンはHTTPSのページで生成される(サーバ→ブラウザ)
  • トークンは確実に暗号化されてブラウザから送信される(ブラウザ→サーバ)
  • HTTPSのページを閲覧するにはトークンが必須。

すなわち、トークンがサーバとブラウザの双方向で確実に暗号化されること、HTTPSのページを閲覧するには第三者の知り得ないトークンが必要であることから安全性が確保されていることになる。

参考文献:体系的に学ぶWebアプリケーションの作り方 4.8.2 クッキーのセキュア属性不備

体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践
徳丸 浩

ソフトバンククリエイティブ 2011-03-03
売り上げランキング : 4070

Amazonで詳しく見る
by G-Tools

« クッキーの不適切な利用 | Main | 秀丸エディタのマクロにおける配列 »

PHP」カテゴリの記事

セキュリティ」カテゴリの記事

Comments

Post a comment

(Not displayed with comment.)

TrackBack

TrackBack URL for this entry:
http://app.cocolog-nifty.com/t/trackback/26461/58802951

Listed below are links to weblogs that reference クッキーのSecure属性不備:

« クッキーの不適切な利用 | Main | 秀丸エディタのマクロにおける配列 »

March 2017
Sun Mon Tue Wed Thu Fri Sat
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31  
無料ブログはココログ

日本blog村

  • にほんブログ村 IT技術ブログへ
  • にほんブログ村 アニメブログへ
  • にほんブログ村 サッカーブログ アルビレックス新潟へ

好きな音楽家

メモ

XI-Prof