公開日:2007年6月28日
独立行政法人情報処理推進機構
セキュリティセンター
本ページの情報は2007年6月時点のものです。
記載の資料は資料公開当時のもので、現在は公開されていないものも含みます。
Webアプリケーションには、パスワード入力、個人情報表示、クレジットカード番号の取り扱い等、他人に通信を傍受されたくない場面をもつものがあり、それらのWebページではhttp:ではなくhttps:のスキームをもつ URLが使われる。
経路の守秘性を確保するために、HTTPと共に TLS (Transport Layer Security) のセキュアプロトコルが使われる必要がある。
https:のセキュアプロトコルで守るべきものには次の2種類がある。
パスワード、個人情報、クレジットカード番号、ショッピング明細等、[1] に該当する情報が他人に漏れてはならないのは分かりやすい。
しかし、ユーザの目に触れないところでWebアプリケーションは [2] のセッションIDをブラウザとやり取りしている。
セッションIDが第三者に知られれば、セッション乗っ取りが生じるおそれがある。
暗号通信でセッションID の秘密を守ることも、忘れてはならない対策のひとつである。
https:を使っているにもかかわらずセッションIDが第三者に漏えいすることがある。
次のようなケースである。
上記の問題への対症療法的対策としては次の方法がある。
https:のみで用いるつもりのCookieには発行時にsecure属性を付ける
ログインするまでのhttp:のページではセッションIDを発行しないようにするか、またはユーザがログインに成功した時点でそれまでのセッションIDを無効にして新たなセッションIDを発行し直す
セッションID の漏えいを防ぐための、https: にかかわる諸対策として次のものがある。
一連のWebコンテンツの中でhttp: のページとhttps: のページが混在することは上記のような問題をはらんでいる。
そもそも問題を生じにくくするには、Webサイトを企画する段階で次のような設計を行う。
TLS については、なるべく高いバージョンの仕様を利用する。本稿の執筆時点において、選択肢としてバージョンの高い順に次の 3つがある。
なお、SSL 3.0 および SSL 2.0 については脆弱性が知られており、サーバやブラウザにおいて「使わない」設定にしておくべきである。
本番運用のWebサーバに関しては、サーバ側ディジタル証明書を自己発行すべきでない。
クライアント側でその証明書の正当性を検証しようとしても、当該Webサイトが提供するルート証明書のみにもとづいて検証することになる。
ルート証明書の段階から偽物を作ることで攻撃者は証明書の辻褄を合わせることができ、詐欺サイト等が作られるおそれがある。
https: のページで使用するCookieには発行時に secure属性をつける。
secure属性が付けられたCookieは、http:のコンテンツ宛には送られない。
http: のページにおいてもCookieを使用する必要がある場合は、Cookie の値を第三者が傍受し得ることを十分に考慮した上で secure属性のつかない Cookieを発行する。