 |
|
|
| 前のページ 1 2 3 4
|
|
| HTTP Cookie
|
HTTP Cookieは、Webサーバが同一のWebクライアントからのリクエストを追跡するために使う小さな目印のデータである。
CookieはまずWebサーバがHTTPレスポンスを通じて発行し、Webブラウザがそれを保持する。WebサーバへHTTPリクエストを送るたびにWebブラウザは預かったCookieをリクエストに含めて送信する。Webサーバはブラウザから送り返されてきたCookieの値を使って処理のコントロールを行うことができる。
Cookieはいわば、Webサーバ側からブラウザにデータを預けておけるポケットのような存在である。Webサーバ側にデータベースやセッション変数（後述）のための資源を用意しなくても、ユーザごとのデータをそれぞれ置いておくことができるので、Perlで書かれたCGIなどでは多用されることがある。
図7：Cookie
|
| Cookieの流出
|
Cookieには暴露傾向がある。情報が流出しやすいのである。それはCookieがWebサーバから発行されるときに付けられるいくつかの属性と関係がある。Cookieの属性は、そのCookieを預かったWebブラウザがどのような通信相手にこのCookieを送り出すべきであるかを指示するものであり、次のものがある。
- domain=ドメイン名 ＜デフォルトはWebサーバのドメイン名＞
- このドメインに属するサーバにHTTPリクエストを出すときにはいつもCookieを送り出せ、という指示。指定が短いほど範囲は広くなる。
- path=パス名 ＜デフォルトは / ＞
- サーバのこのパス上にあるコンテンツをリクエストするときにはいつもCookieを送り出せ、という指示。指定が短いほど範囲は広くなる。
- expires=日付と時刻 ＜デフォルトはブラウザを閉じるまで＞
- いつまでこのCookieが有効かの指示。
- secure または 無指定 ＜デフォルトは無指定＞
- SSL通信のときだけCookieを送り出すべきか否かの指示。
これらの属性を誤って広い範囲に設定してしまうと、そこで指定されたドメイン、パス、有効期間、通信チャネルに向けてHTTPリクエストが送出されるときには、同時にCookieもどんどん送り出される。
他のドメインのサーバや、他のパスに存在するWebアプリケーションは、故意もしくは過失により情報のセキュリティをおびやかす怖れがあり、Cookieの属性はできる限り狭い範囲にとどめておくべきだ。特にpathとsecureは多くの場合デフォルトにしておくべきではない。
またdomainだが、これも慎重に設定したいものである。Cookieのドメインは何にしますか？というシステム構築業者の問いに、ある企業の担当者は「我が社のドメインはxxxxxx.co.jpだからこれで」と企業全体のドメイン範囲をひとつのCookieに与えてしまったという実話がある。社内のどこかに悪意のサーバを立てておけば、重要な内容を持つCookieをいくつも傍受できたことだろう。
|
| Cookieの偽造
|
Cookieの値はいったんブラウザが保持するので、ユーザにはいくらでも改ざんの機会がある。
また、何もないところからCookieの値をねつ造し、Webアプリケーションに送りつけて情報を引き出すといった手口もある。会員の識別情報をCookieに預けていてそれをもとにデータベースを読むといったロジックが存在すると、はじめから情報を読み出す部分が狙われて個人情報が流出する怖れがある。
|
| セッション変数
|
クエリーストリング、hiddenフィールド、HTTP Cookieのいずれも使い方には注意が必要である。他者に知られたくない情報は搭載すべきでないし、ユーザによる改ざんを防ぎたければ入念なデータ検査が必要だ。
こうした問題が起こりにくい形でページ間のデータ受け渡しを実現する方法がある。それはセッション変数である。
|
| セッションメカニズム
|
セッション変数は、最近のWebアプリケーションエンジンの多くが備えているセッションメカニズムが提供する機能のひとつだ。セッションメカニズムは次のように働く。
- Webクライアントからはじめてアクセスが来たとき、Webサーバは新しいセッションの生成を行う。セッションの生成においては、新しいセッションIDを発行しWebクライアントに通知することと、Webサーバ内にそのセッション用のデータ領域を確保することが行われる。
- WebブラウザはWebサーバからセッションIDの発行を受け、その値を保持し続ける。
- WebブラウザはWebサーバへアクセスするたびに預かっているセッションIDを添えてリクエストを発する。Webサーバ側は同一のセッションIDを送ってくるWebクライアントは同一のクライアントであると見なす。
- ユーザがログアウトの意思表示をしたり、ユーザが操作をしないまま一定の時間が経過した場合、それまでのセッションIDを無効とし、そのセッションに対応づけられていたWebサーバ上のデータ領域も解放する。
これを見て、Cookieに似ているなと思われた方もおられるだろう。実はその通りである。CookieはセッションIDの搬送のために考案されたものであり、多くの場合セッション管理にはCookieが使われる。なお、Cookieよりも手間は増えるがCookie以外の方法でセッションIDを搬送することも可能だ。
図8：セッションメカニズム
（画像をクリックすると別ウィンドウに拡大図を表示します）
|
| セッション変数
|
セッション変数はセッションメカニズムによりWebサーバ側に確保されるデータ領域中に置かれる変数のことである。Java Servlet、PHP、Active Server PagesなどのWebアプリケーション開発処理系はみなセッションメカニズムとセッション変数をサポートしている。簡単なAPIを使って、セッション変数への書き込みと読み出しを行うことができる。
はじめからこうした処理系を使っているソフトウェア構築技術者にとっては、セッション変数の使用は特別なことではなく、ごく自然なことになっているとも考えられる。
|
| セッション変数の弱点
|
Webサーバ外部に情報が漏れずユーザから直接改ざんされる怖れのないセッション変数であるが、弱点は存在する。それは「セッション乗っ取り」である。正規ユーザのセッションIDを何らかの方法で入手した攻撃者がそのセッションIDを使ってWebサーバに接続してくると、Webアプリケーションはそれも本物のユーザだと思いアクセスを許してしまう。この問題については次回で詳しく触れる。
|
| まとめ
|
「パラメータからの情報流出」の問題は、Webページ間で受け渡される項目はさまざまなところに露出される傾向があり、改ざんも容易であるために起こる。パラメータを必要以上に露出しているWebサイトは要注意だ。
さて、次回の第4回は、5つの脆弱性カテゴリーの3番目「セッション乗っ取り」を取り上げる。
|
前のページ 1 2 3 4
|
|
|
|
|
著者プロフィール
セントラル・コンピュータ・サービス株式会社 長谷川 武
シニア・セキュリティ・スペシャリスト、IPA 非常勤研究員。2002年にはIPA ISEC『セキュア・プログラミング講座』の制作ディレクターをつとめた。これを契機に、現在は勤務先とそのパートナー企業を通じてセキュアプログラミングセミナー／実習／スキル評価テストといった教育サービスを「TRUSNET(R)アカデミー」として提供している。問い合わせE-mail：info@trusnet.com。
|
|
|
|
|
|
