[ThinkIT] 第3回：パラメータからの情報流出 (2/4)

TOP＞設計・移行・活用＞システム全体に渡る連番

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

第３回：パラメータからの情報流出
著者：セントラル・コンピュータ・サービス長谷川武
2005/5/11

前のページ 1 2 3 4 次のページ

システム全体に渡る連番

かつては前のページで解説したような脆弱なサイトが実際にあったが、現在の多くのWebアプリケーションは、クエリーストリングのパラメータにユーザIDを用いたり、ユーザIDのパラメータを書き換えるだけで他人の情報を盗み見ることができるほどずさんな作りにはなっていないはずだ（と願う）。

しかし、リソースがシステム全体に渡る連番で管理されているなどのケースで見落としが起こることがある。先ほどのショッピング明細表示プログラムの仕様を変えて、今度は次のようなURLで呼び出されるものだとしよう。


		https://domain/shopping_detail?orderid=23081

これは、現在のユーザが閲覧しようとしているショッピングの明細は、システム全体で管理されている注文IDの23081番で識別されるものであり、それを表示するという想定である。情報開示を一部の適切な範囲に制限するロジックがプログラムに備わっていないと、下記のようにして全会員のショッピング明細をすべて見られてしまう、という事態が生じる。


		https://domain/shopping_detail?orderid=23081

		https://domain/shopping_detail?orderid=23080

		https://domain/shopping_detail?orderid=23079

		…

Webアプリケーションプログラムはパラメータに悪意の値が与えられてもびくともしないよう作るべきであるが、必要な配慮はそれだけではない。他人に知られると具合が悪い情報をクエリーストリングによって取り扱うのは極力避けなくてはならないのである。

クエリーストリングはいたるところに露出

   クエリーストリングに搭載するパラメータは、ユーザ本人だけでなく複数の人々の目に触れる可能性を持っている。

   ひとつ目のケースは、クエリーストリングがURLの一部なので、Web閲覧の過程でHTTPリクエストが通過するコンピュータのログにそれぞれ記録される、というものである。記録される場所には、プロキシサーバのログ、ファイアウォールのログ、Webサーバのログが含まれる。それぞれのコンピュータ管理者はこれらのログを閲覧する権限と機会を持つから、記録されているURLの一部としてユーザIDとパスワードが含まれたりしていると、その管理者は特定のサイトのアカウントを多数手に入れることになる。

   二つ目のケースは「Referer:」ヘッダによるURL通知である。これは、Webサーバに今送っているリクエストのURLは、どこか別のWebページに記載されていたものを取得して使っていることを通知するものである。Referer:ヘッダの値はURLの形をしていて、ユーザが直前にどのページに居たかを示している。Webサーバはこれを見てページの動きの制御に利用することがある（※注1）。

※注1：このやり方は万全でない。Referer:ヘッダの偽造は可能だから。

Referer:ヘッダによるURLの送出が起こるのは、ユーザがページ上のハイパーリンクをクリックして新たなページにアクセスしようとしているときと、ブラウザがひとつのWebページを完成させる途中で<img>タグ等が示す埋め込み対象を取得するときである。

図2：Referer:ヘッダ

ハイパーリンク先や貼り付ける画像の置き場所が十分信用のおけるサイトである場合はまだよいが、そうでないサイトのページや画像を参照するよう仕向けられていることもあり得る。その場合、URLとクエリーストリングのパラメータが部外者の運営するWebサーバに傍受される怖れがある。

このようにクエリーストリングのパラメータは秘密を守りにくい存在であるから、次のようなものを扱うことは危険である。

ユーザID、パスワード、メールアドレス
各種個人情報、私信メッセージ
学業成績、業務成績、金銭取引内容、病歴、債務状況

フォームの送信メソッド

フォームのデータの送信においてもクエリーストリングによる情報流出が起こる場合がある。それはフォームのメソッドの明示を忘れた場合である。


		<form action="program">

		<item type="text" name="fullname">

		<item type="text" name="address">

		<item type="text" name="telephone">

		<item type="submit">

		</form>

<form>タグにはmethod属性で2種類のメソッド、getとpostのいずれかを指定することができる。これらのメソッドは、WebブラウザからWebサーバへフォームデータを送る際のデータの搭載方法を決めるものである。フォームデータは、method="get"の場合はHTTPリクエストパケットのヘッダ部分のクエリーストリング上に置かれ、method="post"の場合はHTTPリクエストパケットのボディ部分に置かれる。

どちらも指定しなかった場合、method="get"であると解釈される（※注2）。その結果、フォームデータはクエリーストリングを使って送信され、情報流出の危険にさらされる。

※注2：これにはPOSTよりもGETメソッドが先にできたという歴史的な背景がある。

図3：GETリクエストとPOSTリクエスト

前のページ 1 2 3 4 次のページ

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

INDEX
第3回：パラメータからの情報流出
	はじめに
	システム全体に渡る連番
	hiddenフィールド
	HTTP Cookie