Webアプリケーションの検査（2）〜 Webサイトのセッションまわりを調べる方法 〜：Webアプリケーションに潜むセキュリティホール（6）

» 2003年10月10日 00時00分 公開
[中村隆之，三井物産セキュアディレクション]

※ご注意

他社および他組織のWebサイトなどへのポートスキャンおよびデータの取得などの行為で得た情報を侵入などに悪用するか、または同じ目的を持つ第三者に提供した時点で違法となります。ご注意ください。

本稿の内容を検証する場合は、必ず影響を及ぼさない限られた環境下で行って下さい。

また、本稿を利用した行為による問題に関しましては、筆者および株式会社アットマーク・アイティは一切責任を負いかねます。ご了承ください。


　前回はWebアプリケーションの検査とはどういったものなのか、ということについて説明した。今回からは、実際にWebアプリケーションの検査に入っていく。前回説明した検査用ツール「Achilles」のインストールは済んでいるだろうか。今回はAchillesを実際に使用するので、まだという方は、前回の説明を見ながらインストールし、使い方に慣れておいていただきたい。

※注

検査について説明していくには、検査対象のWebサイトが必要である。しかし、当然のことながら実際のWebサイトを用いるわけにはいかないので、筆者の手元にあるデモサイトを用いて説明していくことにする。


検査対象とするWebサイト例の仕組みを押さえる

図1 検査対象とするTOPページの画像 図1 検査対象とするTOPページの画像（クリック拡大）

　まずは、今回検査対象とするWebサイトについて説明しておこう。このWebサイトではオンラインショッピングを提供している。主要な機能は以下のとおりである。

  • ユーザー新規登録
図2 新規登録画面1 図2 新規登録画面1
図3 新規登録画面2 図3 新規登録画面2
図4 新規登録画面3 図4 新規登録画面3
  • ログイン
図5 ログイン画面1 図5 ログイン画面1
図6 ログイン画面2 図6 ログイン画面2
  • ショッピング
図7 ショッピング画面1 図7 ショッピング画面1
図8 ショッピング画面2 図8 ショッピング画面2
図9 ショッピング画面3 図9 ショッピング画面3
図10 ショッピング画面4 図10 ショッピング画面4
図11 ショッピング画面5 図11 ショッピング画面5
  • ユーザー情報の参照／変更
図12 ユーザー情報画面1 図12 ユーザー情報画面1
図13 ユーザー情報画面2 図13 ユーザー情報画面2
図14 ユーザー情報画面3 図14 ユーザー情報画面3
図15 ユーザー情報画面4 図15 ユーザー情報画面4
図16 ユーザー情報画面5 図16 ユーザー情報画面5
図17 ユーザー情報画面6 図17 ユーザー情報画面6
  • 掲示板
図18 掲示板画面 図18 掲示板画面
  • 問い合わせ
図19 問い合わせ画面1 図19 問い合わせ画面1
図20 問い合わせ画面2 図20 問い合わせ画面2
  • ログアウト（図1 TOPページと同様）

　全体の画面遷移はこのようになっている。

図21 画面遷移図 図21 画面遷移図（クリック拡大）

何から検査すればいいのか

　さて、Webサイトを検査するわけだが、何から手を付ければよいだろう？ クロスサイトスクリプティング？SQLインジェクション？前回までの説明で、不正な入力として何を入れればよいかは理解しているかと思うが、実際に入力するのはもうちょっと待ってほしい。最初に行うのは、Webサイト全体の構成をしっかりと把握することだ。

●Webサイトの構成を把握する

　広義の意味では、Webサイトを構成するすべてのコンポーネントのことを指すが、範囲が広すぎるため、本稿での「Webサイト構成」とは、ディレクトリ、HTMLファイル、CGI、PHP、JSPなどのアプリケーションのことを指す。

　把握する項目としては以下のようなものがある。

  • 提供されている機能
  • ディレクトリ構成
  • 画面遷移図
  • セッション管理方法
  • 画面遷移条件

　今回はこの中から「画面遷移図」「セッション管理方法」「画面遷移条件」について説明する。

●画面遷移図を作る

　検査を行ううえで、画面遷移図を作ることは非常に重要である。画面遷移図を作るとWebサイト全体を把握することができ、検査の漏れが少なくなる。今回の検査対象Webサイトの画面遷移図は先ほど挙げたとおりである。もし画面遷移図が存在しない場合は、Webサイトを巡回しながら作成していく。

●セッション管理について調べる

　Webアプリケーションの検査を行ううえでセッション管理の方法を調べる作業は非常に重要である。なぜ最初にセッション管理について調べるのか。前回、自動検査ツールの欠点について説明した。自動検査ツールの巡回機能は、すべての画面を巡回できるとは限らないし、ステータスも考慮してくれない。この欠点を補うために、手動によりセッション管理の方法を調べるわけだ。この情報を使って、すべての画面を巡回し、すべてのステータスで検査を行う。

　セッション管理の方法としては以下の3種類にほぼ分類できる＊1。

＊1

ほかに、BASIC認証やクライアント証明書を使ったものがある


  • URLパラメータ（Query String）を使う方法
  • hiddenを使う方法
  • Cookieを使う方法

　この中のどの方法が使われているのか調べるところから始める。方法は簡単だ。クライアントとサーバの間で、どのようなデータがやりとりされているか見ればいい。ただし、やみくもにデータを見ればいいわけではなく、セッションの状態を見ながら、そのステータスを維持しているパラメータを見つける。一般的に、

  • 認証前の状態
  • 認証後の状態
  • そのほかのステータスが変化したときの状態

で、パラメータを調べるとよいだろう。

●画面遷移条件を調べる

　画面遷移条件とは、次の画面に進むための条件のことをいう。例えば、

  • 画面Aから画面Bに進むには、パラメータ1とパラメータ2の入力が必須
  • この画面以降は、認証済みである必要がある
  • この機能は、処理1が確定していないと実行されない

などである。今回の検査対象Webサイトでは、ショッピング機能のところで、商品の選択を行った後に商品送付先の住所を入力している。そのため、住所入力のところを検査する場合は、あらかじめ商品を選択しておく必要がある。

　さて、理論的な説明はここまでにして、実際にデモサイトを使って話を進めることにしよう。読者はスクリーンショットを見ながら読み進めてほしい。

Webサイトの巡回

　まずはWebサイトにアクセスして、全体を触ってみるところから始める。デモサイトが提供している機能はすでに紹介済みだが、このフェイズでは実際にブラウザでアクセスして、それらの機能を試してみる作業を行う。実際に使ってみることで、どのあたりに脆弱性がありそうか分かってくる。このフェイズで画面遷移図を作っていくといいだろう。

　ここで見ておくべきポイントをいくつか挙げておこう。

  • どんなセッション管理方法を行っているか
  • 未認証状態、認証状態でアクセスできる範囲は？
  • FORMの中にはどんなパラメータがあるか

　では、取りあえず巡回してみよう。Achillesを起動して、

  • 「Intercept mode」
  • 「Intercept Client Data」
  • 「Intercept Server Data（text）」
  • 「Ignore .jpg/.gif」

にチェックを入れて、プロキシをスタートさせる。この状態では、AchillesはすべてのHTTPリクエスト／レスポンスを中継する。

　プロキシの準備が整ったら、Webサイトにアクセスする。最初にアクセスするのは、トップページ（図1：http://www.example.com/index.cgi）だ。

　リクエストを送ると、サーバから次のようなレスポンスが返ってくる。

HTTP/1.1 200 OK
Date: Sun, 28 Sep 2003 16:04:31 GMT
Server: Apache/2.0.40 (Red Hat Linux)
Pragma: no-cache
Set-Cookie: ss=312901200304091387
Connection: close
Content-Type: text/html; charset=euc-jp 
<html>
……（省略）

　ここで、

Set-Cookie: ss=312901200304091387

　この行に注目する。どうやらこのWebサイトではCookieを使っているらしい、ということが分かる。しかし、これがセッション管理用のパラメータであるかどうかはまだ分からない（「ss」という名称は、明らかに怪しいが）。ただ、セッション管理機能を持つ多くの言語（JSP／Servlet、PHP、ASPなど）は、ログイン前からセッション管理を開始する場合があるので、もしかしたらこのデモサイトもセッション管理を開始したのではないか、と考える。ログイン前の状態で「GUESTさんようこそ」（図1）と表示されている点が怪しい。

　ほかのメニュー、例えば、

  • ショッピング（図7：http://www.example.com/shop.cgi）■
  • 掲示板（図18：http://www.example.com/bbs.cgi）■
  • 問い合わせ（図19：http://www.example.com/toiawase.cgi）■

などにアクセスしても、ログイン前では「GUESTさん　ようこそ」と表示される。この時点で、以下のことが分かる。

  • Cookieが発行されて、セッションIDらしきものが入っている
  • ほかのメニューへは何のURLパラメータも付いていない通常のリンクをたどってアクセスする
  • GETによるアクセスなので、hiddenパラメータは使われていない

　以上のことより、もし「GUEST」というステータスを維持しているのであれば、セッション管理方法はCookieであり、パラメータ「ss」がセッション管理用のパラメータである、ということが分かる。

　現在はログインしていない状態なので、取りあえずログインしてみる。アカウントは、あらかじめ登録しておいた「nakanaka」を用いる。

　IDとパスワードをログインフォームに入力して送信する。

図22 IDとパスワードをログインフォームに入力して送信 図22 IDとパスワードをログインフォームに入力して送信

　このとき送信されるリクエスト／レスポンスは以下のようになる。

  • リクエスト
POST /login.cgi HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Host: www.example.com
Content-Length: 26
Cookie: ss=312901200304091387
loginid=nakanaka&password=nakanaka
  • レスポンス
HTTP/1.1 200 OK
Date: Sun, 28 Sep 2003 16:16:31 GMT
Server: Apache/2.0.40 (Red Hat Linux)
Pragma: no-cache
Connection: close
Content-Type: text/html; charset=euc-jp<html>
……（省略）

　ログイン後の画面では「nakanakaさんようこそ」と表示されている（図23）。

図23 ログイン後の画面 図23 ログイン後の画面

　しかし、レスポンスヘッダを見ると分かるように、新規Cookieは発行されていない。また、ログイン後のほかのメニューへのアクセスは、ログイン前と同じく何のURLパラメータも付いていないただのリンクとなっている。よって、セッションを維持するためのパラメータはCookieしかないことが分かるので、セッション管理の方法はCookieということになる。

　もう1つ、セッション管理パラメータを特定する方法があるのでそれを試してみよう。その方法とは、セッションを維持していると思われるパラメータを取り除いてアクセスする、というものだ。もし取り除いたパラメータがセッションを維持しているパラメータだった場合、サーバは未認証状態と認識して、ログイン前の状態、つまり「GUESTさんようこそ」というページを返してくるはずだ。

　今回はCookieが怪しいので、これを消してアクセスしてみる。Cookieを消すといってもブラウザの機能を使って消すのではなく、Achillesを使って行う。

　WebブラウザでTOPページ（図1：http://www.example.com/index.cgi）にアクセスするとAchillesにブラウザからのHTTPリクエストが表示される。ここで、

Cookie: ss=312901200304091387

　この行を消してから「Send」ボタンを押して、サーバにリクエストを送る。すると、サーバから以下のようなレスポンスが返ってくる。

HTTP/1.1 200 OK
Date: Mon, 29 Sep 2003 15:20:20 GMT
Server: Apache/2.0.40 (Red Hat Linux)
Pragma: no-cache
Set-Cookie: ss=213000200320091388
Connection: close
Content-Type: text/html; charset=euc-jp
<html>……（省略）

　Set-Cookieヘッダで、新しい「ss」がセットされている。また、ブラウザに表示されるページも「GUESTさんようこそ」となっている（図24）。

　以上のことから、このWebサイトではセッション管理にCookieを使用しており、パラメータ「ss」がセッション管理用のパラメータである、ということが分かる。

図24 ログイン前の状態に戻ってしまう 図24 ログイン前の状態に戻ってしまう

セッションIDの強度を調べる

　セッション管理方法が分かったら、今度はセッションIDの強度を調べてみよう。セッションIDの強度を調べるには、セッションIDを数多く入手する必要がある。セッションIDが発行される場所、タイミングについては先ほど説明したとおりである。Cookieがない状態でTOPページにアクセスすれば発行される。セッションIDを集めるには、セッションIDが発行される個所に繰り返しアクセスすればいい。

　数個ならともかく、数十個、数百個集めるには、手動では非常に時間が掛かってしまう。このような単純な作業は自動化してしまおう。Perlを使って書くとリスト1のようになる。PerlにはHTTP関連の処理を扱うモジュールがたくさんあるので、それらを使うとほんの数行で済んでしまうので、自由に使えるようになると非常に便利だ。

use HTTP::Request;
use LWP::UserAgent;
　
my $ua = LWP::UserAgent->new;
my $request = HTTP::Request->new(GET => 'http://www.example.com/index.cgi');while(1){
my $response = $ua->request($request);
print $response->header('Set-Cookie'),"\n";
sleep 1;
}
リスト1 Perlを使ったセッションID入手例

　以下はこのスクリプトを使って得られたセッションIDである。

ss=440100200329101469
ss=450100200329101470
ss=460100200329101471
ss=480100200329101472
ss=490100200329101473
ss=500100200329101474
ss=520100200329101475
ss=530100200329101476
ss=540100200329101477
ss=560100200329101478
ss=580100200329101479
ss=590100200329101480
ss=000100200330101481
ss=010100200330101482
ss=020100200330101483
ss=040100200330101484
ss=050100200330101485
ss=060100200330101486

　これを見て、すぐに規則性が分かるだろうか。各セッションIDの左2けたの数字を見てほしい。59から00に変わっているのが分かるだろうか。

　秒以外にも日時が隠されているので、探してみてほしい。ちなみに、このセッションIDを発行した日時は「2003年10月1日 0時30分」である。

　正解は次のとおりだ。

[秒]　[日]　[時]　[年]　[分]　[月]　[通し番号]

　セッションIDの生成方法が分かってしまえば、他人のセッションIDを推測し、なりすましを行うことが可能になる（セッションハイジャック）。

　今回はWebサイトのセッションまわりを調べる方法について説明した。検査を行うに当たって、今回説明した部分は非常に重要であるのでしっかりと理解していただきたい。

←「第5回」へ

「第7回」へ→


著者紹介

中村隆之（なかむらたかゆき）

三井物産セキュアディレクション勤務。 セキュリティコンサルタントとして主にWebアプリケーションのセキュリティ検査に従事しており、大手ポータルサイト、オンラインバンキングなどの数多くの 検査実績を持つ。また、セキュアネットワーク及び暗号関連の研究に携わり、大手製造、官公庁、金融機関へのセキュリティシステム導入など数多くの実績を持つ。

三井物産セキュアディレクション

主に、不正アクセス監視サービス、セキュリティ検査、セキュリティポリシー策定支援などのサービス提供している。また、セキュリティに関する教育サービスも実施中。


「Webアプリケーションに潜むセキュリティホール」バックナンバー

Copyright © ITmedia, Inc. All Rights Reserved.

スポンサーからのお知らせPR

注目のテーマ

Microsoft ＆ Windows最前線2025
AI for エンジニアリング
ローコード／ノーコード セントラル by ＠IT - ITエンジニアがビジネスの中心で活躍する組織へ
Cloud Native Central by ＠IT - スケーラブルな能力を組織に
システム開発ノウハウ 【発注ナビ】PR
あなたにおすすめの記事PR

@ITについて

RSSについて

アイティメディアIDについて

メールマガジン登録

＠ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。