第4章 4.セッション乗っ取り：https:の適切な適用

本ページの情報は2007年6月時点のものです。
記載の資料は資料公開当時のもので、現在は公開されていないものも含みます。

https:による通信経路の防護

Webアプリケーションには、パスワード入力、個人情報表示、クレジットカード番号の取り扱い等、他人に通信を傍受されたくない場面をもつものがあり、それらのWebページではhttp:ではなくhttps:のスキームをもつ URLが使われる。

経路の守秘性を確保するために、HTTPと共に TLS (Transport Layer Security) のセキュアプロトコルが使われる必要がある。

• 

(1) セキュアプロトコルで守るべきもの

https:のセキュアプロトコルで守るべきものには次の2種類がある。

1. ユーザが目にする重要情報
2. セッションID

パスワード、個人情報、クレジットカード番号、ショッピング明細等、[1] に該当する情報が他人に漏れてはならないのは分かりやすい。

しかし、ユーザの目に触れないところでWebアプリケーションは [2] のセッションIDをブラウザとやり取りしている。

セッションIDが第三者に知られれば、セッション乗っ取りが生じるおそれがある。

暗号通信でセッションID の秘密を守ることも、忘れてはならない対策のひとつである。

セッションIDが漏れる

https:を使っているにもかかわらずセッションIDが第三者に漏えいすることがある。

次のようなケースである。

1. ひとつのホストあるいはディレクトリの中でhttp:のページとhttps:のページの間の相互の行き来がある
   → https:の通信でのみ使うべきCookieの値がhttp:の通信に流出するおそれがある
2. ログイン前のhttp:のページですでにセッションIDが発行されている
   → このセッションIDは第三者に傍受されるおそれがある
3. ユーザがログインした後もログイン前と同じセッションIDが使われる
   → 第三者に傍受されたセッションIDである可能性がある

上記の問題への対症療法的対策としては次の方法がある。

1への対策

https:のみで用いるつもりのCookieには発行時にsecure属性を付ける

2、3への対策

ログインするまでのhttp:のページではセッションIDを発行しないようにするか、またはユーザがログインに成功した時点でそれまでのセッションIDを無効にして新たなセッションIDを発行し直す

https: にまつわる諸対策

セッションID の漏えいを防ぐための、https: にかかわる諸対策として次のものがある。

(1) 上流からのhttps:適用設計

一連のWebコンテンツの中でhttp: のページとhttps: のページが混在することは上記のような問題をはらんでいる。

そもそも問題を生じにくくするには、Webサイトを企画する段階で次のような設計を行う。

1. 暗号通信で保護すべきページを見極める
2. 保護すべきと定めたページはhttps: でのみ閲覧させる
3. これらのページへのアクセスにあたって最初に本人認証を行う
4. 認証の有効性をセッションのメカニズムを用いて複数のページにわたり維持する
5. http: のコンテンツとhttps: のコンテンツは別のホストから提供する
6. https: のコンテンツのhttp: による閲覧を許さない。
   また、http: のコンテンツのhttps: による閲覧を許さない

(2) TLS のバージョン

TLS については、なるべく高いバージョンの仕様を利用する。本稿の執筆時点において、選択肢としてバージョンの高い順に次の 3つがある。

• TLS 1.2
• TLS 1.1
• TLS 1.0

なお、SSL 3.0 および SSL 2.0 については脆弱性が知られており、サーバやブラウザにおいて「使わない」設定にしておくべきである。

(3) サーバ証明書を自己発行しない

本番運用のWebサーバに関しては、サーバ側ディジタル証明書を自己発行すべきでない。

クライアント側でその証明書の正当性を検証しようとしても、当該Webサイトが提供するルート証明書のみにもとづいて検証することになる。

ルート証明書の段階から偽物を作ることで攻撃者は証明書の辻褄を合わせることができ、詐欺サイト等が作られるおそれがある。

(4) Cookieにsecure属性をつける

https: のページで使用するCookieには発行時に secure属性をつける。
secure属性が付けられたCookieは、http:のコンテンツ宛には送られない。

http: のページにおいてもCookieを使用する必要がある場合は、Cookie の値を第三者が傍受し得ることを十分に考慮した上で secure属性のつかない Cookieを発行する。