TOP＞設計・移行・活用＞ はじめに




脆弱なWebアプリケーション
脆弱なWebアプリケーション

第４回：セッション乗っ取り
 著者：セントラル・コンピュータ・サービス  長谷川 武
2005/5/18
1   2  3  4  次のページ
はじめに

   今回はWebアプリケーションの脆弱性における3番目のカテゴリー「セッション乗っ取り」について解説する。
※注意： この記事にはWebアプリケーションの脆弱性を解説する必要上、攻撃手口に関する情報が含まれています。これらの手口を他者が運営するWebサイトに向けて仕掛けると、最悪の場合刑事罰および損害賠償請求の対象となります。脆弱性の調査・検証は、必ずご自身の管理下のコンピュータシステムおよびローカルエリアネットワークで行ってください。この記事を参考にした行為により問題が生じても、筆者およびThinkIT編集局は一切責任を負いません。


セッション

   Webアプリケーションのセッションとは、複数のWebページにまたがる会話処理のことである。たとえば「商品を選ぶ」「配達先を指定する」「カードで決済する」といった会話処理の流れがその例である。これらのページ間では適切に情報が引き継がれてゆくが、それは一連のHTTPリクエストが同一のWebクライアントから送られてきたことを認識するためのロジックがWebサーバ側のプログラムに組み込まれているからだ。

   Webアクセスに使われるHTTP（HyperText Transfer Protocol）そのものにはセッション管理を積極的に行うためのしくみがない。そのため、セッションの管理はWebアプリケーションが担うべき重要な役割のひとつとなっている。

   セッションの管理は、セッションIDと呼ばれる識別情報をWebアプリケーションがブラウザに預けることによって行われる。ブラウザは、Webサイトにアクセスする際、毎回このセッションIDを添えてHTTPリクエストを送る。Webアプリケーションは、同じセッションIDのHTTPリクエストを送ってくる相手を同一のWebクライアントと見なす。

セッションメカニズム
図1：セッションメカニズム
（画像をクリックすると別ウィンドウに拡大図を表示します）
セッションIDの搬送方法とリクエストフォージェリー

   セッションIDを搬送する代表的な方法には、URLリライティング、HTTP Cookie、hiddenフィールドの3種類がある。
名称 実装方法 メリット デメリット
URLリライティング Webサーバ側プログラムがブラウザに送るHTMLソース内のすべてのURLにセッションIDパラメータを付ける HTTP Cookieが使えない端末もサポートできる セッションIDがクエリーストリングで運ばれることになり、3つの方法の中では最もセッションIDが漏れやすい
HTTP Cookie Webサーバ側プログラムがSet-Cookie:ヘッダを使ってHTTP Cookieを発行する。Cookieはブラウザから自動でサーバに送り返される プログラミングの手間が少ない リクエストフォージェリー攻撃を受けやすい。クロスサイトスクリプティング攻撃の標的になりやすい
hiddenフィールド Webサーバ側プログラムがブラウザに送るHTMLソース内にフォームを設け、hiddenフィールドにセッションIDの値を埋め込む。ページ遷移はすべてフォームデータの送信の形で行われるようにする リクエストフォージェリー攻撃を受けにくい。3つの方法の中では最もセッションIDが漏れにくい ページ遷移をすべてフォームで記述する必要があり、自然なハイパーリンクの実現にはJavaScriptの使用が必須となる

表1：セッションIDの搬送方法
   1つ目のURLリライティングは、ブラウザに送るHTMLソースをその都度書き換えて、すべてのパイパーリンクやフォームデータ送付先のURLにセッションIDを表す特別なパラメータを付加する方法である。例えば次のようなHTMLソースになる。

<a href="NextPage?x=3&y=4;jsessionid=123456">リンク</a>

   上記のHTMLタグの中にある「;jsessionid=123456」の部分である。ユーザがハイパーリンクをクリックして次のページに進む際、URLにセッションIDが埋め込まれているためサーバ側はWebクライアントを常に適切に識別できる。

   ただし、このやり方ではクエリーストリングにセッションIDが搭載されることになり、前回の「パラメータからの情報流出」でも触れたように、さまざまな箇所にパラメータの値が流出していく怖れがある。そのため、第二世代の携帯電話端末などHTTP Cookieが使えない端末をどうしてもサポートしなくてはならない状況下などに使用を限定したほうがよいだろう。

   2番目のHTTP Cookieは、元々セッション管理の目的でHTTPの拡張機能としてNetscape社が提案したものであり、現在広く使われている方式である。HTTP Cookieは対象Webサーバへのアクセスが行われるたびに毎回ブラウザから送り出される約束になっているので、サーバ側では一度だけCookieを発行する処理を行えばよいため、プログラミングが楽である。ただしその分、弱点も持つことになる。

Cookie
図2：Cookie
   HTTP CookieによるセッションIDの搬送は、リクエストフォージェリー（より正確にはクロスサイトリクエストフォージェリー）と呼ばれる攻撃に対して不利になる。この攻撃は、別のサイトに用意した罠のリンクを踏ませるなどして、ショッピングの最終決済や退会など、セッション内の重要な処理ページを呼び出すよう被害者ユーザを誘導し、被害を及ぼすものだ。

   HTTP Cookieはその性質上、正規のリンクだけでなく、罠のリンクを通じてのアクセスであっても、アクセス先が所定のWebサイトであればブラウザから自動で送出される。そのため、正規のセッションが保たれた中で、ユーザの意図しない画面遷移と処理が行われてしまうのである。

   3番目のhiddenフィールドにセッションIDを搭載する方式は、こうした問題への対策としてしばしば提唱されるようになってきた。この方式では、ページの呼び出しのたびにセッションIDを持つ項目が送出されるよう、毎回フォームのHTMLタグを構成する必要がある。攻撃者がどこかに偽のリンクを用意したとしても、そこに正規のセッションIDの値を持つフォーム項目を設けることができなければ、罠は機能しない。

   hiddenフィールドでセッションIDを搬送する方式では、各ページにフォームタグを組み込む必要があり、HTMLの記述が煩雑になる。そのため、リクエストフォージェリー攻撃を避けたい重要な場面に限ってhiddenフィールドによるセッションIDの「補強」を行うといった対策のしかたもある。
セッション乗っ取り

   Webアプリケーションとブラウザの間でやり取りされるセッションIDが第三者に知られてしまうと、その第三者も正規ユーザとまったく同じアクセスを手にすることができる。

   他人のセッションIDの値を何らかの方法で突き止め、それを自分で使うことによって他人のセッションの続きを横取りするのがセッション乗っ取りである。

   セッション乗っ取りが攻撃者にとって「効果的」である理由は、セッションが開始される時点で正規のユーザが通過したであろう「ユーザ認証」あるいは「ログイン」の関門と対決することなく、すでに他人が確保したWebクライアントとしての権限を横取りできるところにある。
1   2  3  4  次のページ

セントラル・コンピュータ・サービス株式会社
 著者プロフィール
セントラル・コンピュータ・サービス株式会社  長谷川 武
シニア・セキュリティ・スペシャリスト、IPA　非常勤研究員。2002年にはIPA ISEC『セキュア・プログラミング講座』の制作ディレクターをつとめた。これを契機に、現在は勤務先とそのパートナー企業を通じてセキュアプログラミングセミナー／実習／スキル評価テストといった教育サービスを「TRUSNET(R)アカデミー」として提供している。問い合わせE-mail：info@trusnet.com。


この記事の評価をお聞かせください
 ボタンをクリックしますとウインドウが開きます。
 ご意見、ご要望にお応えします！ インプレスIT INSIDE
INDEX
第4回：セッション乗っ取り
はじめに
  セッションIDへの攻撃
  クロスサイトスクリプティング
  後を絶たないクロスサイト脆弱性
脆弱なWebアプリケーション
第1回 Webアプリケーションの脆弱性
第2回 ファイル流出
第3回 パラメータからの情報流出
第4回 セッション乗っ取り
第5回 インジェクション攻撃
第6回 各種の問題

Think IT 過去人気記事

Think IT
注目おすすめ情報

Think IT人気ライター BEST 5

People
IT製品/サービス資料ダウンロード
    おすすめのホワイトペーパー情報を準備中です