 |
||||||||||||||||
|
||||||||||||||||
| 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種類がある。 |
||||||||||||||||
|
||||||||||||||||
|
表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を発行する処理を行えばよいため、プログラミングが楽である。ただしその分、弱点も持つことになる。  図2：Cookie HTTP Cookieはその性質上、正規のリンクだけでなく、罠のリンクを通じてのアクセスであっても、アクセス先が所定のWebサイトであればブラウザから自動で送出される。そのため、正規のセッションが保たれた中で、ユーザの意図しない画面遷移と処理が行われてしまうのである。 3番目のhiddenフィールドにセッションIDを搭載する方式は、こうした問題への対策としてしばしば提唱されるようになってきた。この方式では、ページの呼び出しのたびにセッションIDを持つ項目が送出されるよう、毎回フォームのHTMLタグを構成する必要がある。攻撃者がどこかに偽のリンクを用意したとしても、そこに正規のセッションIDの値を持つフォーム項目を設けることができなければ、罠は機能しない。 hiddenフィールドでセッションIDを搬送する方式では、各ページにフォームタグを組み込む必要があり、HTMLの記述が煩雑になる。そのため、リクエストフォージェリー攻撃を避けたい重要な場面に限ってhiddenフィールドによるセッションIDの「補強」を行うといった対策のしかたもある。 |
||||||||||||||||
| セッション乗っ取り | ||||||||||||||||
|
Webアプリケーションとブラウザの間でやり取りされるセッションIDが第三者に知られてしまうと、その第三者も正規ユーザとまったく同じアクセスを手にすることができる。 他人のセッションIDの値を何らかの方法で突き止め、それを自分で使うことによって他人のセッションの続きを横取りするのがセッション乗っ取りである。 セッション乗っ取りが攻撃者にとって「効果的」である理由は、セッションが開始される時点で正規のユーザが通過したであろう「ユーザ認証」あるいは「ログイン」の関門と対決することなく、すでに他人が確保したWebクライアントとしての権限を横取りできるところにある。 |
||||||||||||||||
|
1 2 3 4 次のページ |
||||||||||||||||
|
|
||||||||||||||||
|
|
||||||||||||||||
|
||||||||||||||||
|
|
||||||||||||||||
|
||||||||||||||||
|
|
||||||||||||||||
|
||||||||||||||||
-
-
連載
