第4章 セッション対策
セッション乗っ取り：#3 https:の適切な適用
https:による通信経路の防護
Webアプリケーションには、パスワード入力、個人情報表示、クレジットカード番号の取り扱い等、他人に通信を傍受されたくない場面をもつものがあり、それらのWebページではhttp:ではなくhttps:のスキームをもつURLが使われる。
経路の守秘性を確保するために、HTTPと共に、SSL (Secure Socket Layer) あるいは TLS (Transport Layer Security) のセキュアプロトコルが使われる必要がある。
(1) セキュアプロトコルで守るべきもの
https:のセキュアプロトコルで守るべきものには次の2種類がある。
- ユーザが目にする重要情報
- セッションID
パスワード、個人情報、クレジットカード番号、ショッピング明細等、[1]に該当する情報が他人に漏れてはならないのは分かりやすい。
しかし、ユーザの目に触れないところでWebアプリケーションは [2]のセッションIDをブラウザとやり取りしている。
セッションIDが第三者に知られれば、セッション乗っ取りが生じるおそれがある。
暗号通信でセッションIDの秘密を守ることも、忘れてはならない対策のひとつである。
セッションIDが漏れる
https:を使っているにもかかわらずセッションIDが第三者に漏えいすることがある。
次のようなケースである。
- ひとつのホストあるいはディレクトリの中でhttp:のページとhttps:のページの間の相互の行き来がある
→ https:の通信でのみ使うべきCookieの値がhttp:の通信に流出するおそれがある - ログイン前のhttp:のページですでにセッションIDが発行されている
→ このセッションIDは第三者に傍受されるおそれがある - ユーザがログインした後もログイン前と同じセッションIDが使われる
→ 第三者に傍受されたセッションIDである可能性がある
上記の問題への対症療法的対策としては次の方法がある。
- 1 への対策
- https:のみで用いるつもりのCookieには発行時にsecure属性を付ける
- 2、3への対策
- ログインするまでのhttp:のページではセッションIDを発行しないようにするか、またはユーザがログインに成功した時点でそれまでのセッションIDを無効にして新たなセッションIDを発行し直す
https:にまつわる諸対策
セッションIDの漏えいを防ぐための、https:にかかわる諸対策として次のものがある。
(1) 上流からのhttps:適用設計
一連のWebコンテンツの中でhttp:のページとhttps:のページが混在することは上記のような問題をはらんでいる。
そもそも問題を生じにくくするには、Webサイトを企画する段階で次のような設計を行う。
- 暗号通信で保護すべきページを見極める
- 保護すべきと定めたページはhttps:でのみ閲覧させる
- これらのページへのアクセスにあたって最初に本人認証を行う
- 認証の有効性をセッションのメカニズムを用いて複数のページにわたり維持する
- http:のコンテンツとhttps:のコンテンツは別のホストから提供する
- https:のコンテンツのhttp:による閲覧を許さない。
また、http:のコンテンツのhttps:による閲覧を許さない
(2) SSL、TLSのバージョン
SSL、TLSはなるべく高いバージョンのものを使用する。
本稿を書いている時点での選択肢としてはバージョンの高い順に次の3つがある。
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を発行する。
