TOP設計・移行・活用> 後を絶たないクロスサイト脆弱性




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

第4回:セッション乗っ取り
著者:セントラル・コンピュータ・サービス  長谷川 武
2005/5/18
前のページ  1  2  3  4
後を絶たないクロスサイト脆弱性

   クロスサイトスクリプティング脆弱性への対処には必ずしも高度な技術を要しない。その一方でこの脆弱性が後を絶たないのも事実である。その理由は、入力データをエコーバックする処理はプログラムのそこら中で行われていることと、少しでも見落としがあればそれが即脆弱性となる点である。

   見落としの例としてエラーメッセージがある。
page?phone=ABC

   例えば上記のような入力に対して、次のメッセージが表示される場面があったとする。

エラー。あなたの入力した ABC という値は電話番号として適切でありません。

   ここで、入力データはどうせエラーなのだからそのまま表示してしまえばいい、と考えるとそれは大きな間違いである。

page?phone=<script>…</script>

   攻撃者は上記のような入力データを仕立ててわざとこのエラーメッセージが出るよう仕向け、まんまと攻撃スクリプトを送り込んでしまう。入力データをそのままエコーバックしてはいけない、という注意事項に例外はないのである。


セッションIDの強制

   セッションIDに対する攻撃の3番目「強制」は、セッションフィクセーション(Session Fixation)とも呼ばれる攻撃手法である。ここで攻撃者は推定したり傍受するのではなく、すでに自分が知っているセッションIDの値を被害者に使わせることにより、被害者のセッションへのアクセスをはじめから押さえてしまうというものだ。

   セッションIDはWebサーバ側が発行し、Webサーバへアクセスするたびにその値をブラウザが送り出すのが原則である。ところが、WebアプリケーションやWebアプリケーションエンジンの中には、自分が発行したものではないセッションIDの値をブラウザが送ってきても、それを有効なセッションIDとして許してしまうものがある。

   その中の代表格はPHPの処理系である。例えば下記のURLのように、明示的にPHPSESSIDパラメータを付けてリクエストを送ってみる。

http://foo/bar.php?PHPSESSID=3333

   すると、このリクエストに対する応答のヘッダには下記の内容が含まれる。

Set-Cookie: PHPSESSID=3333; …

   つまり、ブラウザから与えた値がセッションIDとして採用されてしまう。

   これのどこが具合が悪いかと言うと、攻撃者は上記のセッションIDを仕込んだハイパーリンクを踏ませることによって、被害者を罠にかけることができるからだ。このセッションIDが使われたままユーザがログイン手続きを行い、デリケートなページにアクセスした場合、攻撃者もそれらのページを見て回る自由を得るのである。


堅いエンジンもご用心

   多くの処理系では、ブラウザが勝手に送ってきた値を正規のセッションIDとして採用しないことが多いが、それでも用心が必要だ。攻撃者自身がWebサイトから正規にセッションIDの発行を受けておき、それを罠のページを通じて被害者のブラウザに送り込む手口があるからである。

   その状況で被害者が当該サイトにログインすると、そのユーザのプライベートなページは攻撃者からもアクセスできるようになる。


セッションIDを付け替える

   セッションフィクセーション攻撃を積極的に避けようとするには、ユーザがログインした際にまったく新しいセッションIDを発行することである。ユーザがログイン手続きをパスしたのを機に、それまでのセッションIDは捨ててしまうのがうまいやり方だ。


セッションのライフサイクル

   今回はセッションIDの攻略を中心に取り上げたが、セキュリティ対策を講じる上ではユーザアカウントやセッションのライフサイクルも視野に入れておく必要がある。たとえば次のような事項だ。

  • ユーザIDやパスワードの発行ルールに弱点はないか
  • ログイン(ユーザ認証)処理に弱点はないか
  • ログアウトがタイムリーに行われるようになっているか
  • ユーザが明示的にログアウトしなかったときにもセッションが安全に打ち切られるか
  • ユーザがパスワードを忘れたときの救済措置(パスワードリマインダー)が親切すぎないか
  • ユーザが退会した後アカウントが安全に処分されるか

   もしこれらの中に弱い箇所があれば、攻撃者はそこを破って他人の資格でシステムへのアクセスを手にすることになる。


まとめ

   正規ユーザのセッションを攻撃者に乗っ取られないようにすることは、Webサーバとブラウザの間でやり取りされるセッションIDという小さなデータを攻撃者の魔の手からいかに遠ざけておけるか、という点にかかっている。

   セッションIDを守るには、予測困難な値の生成、IDの付け替え、SSLの使用、Cookieのsecure属性、クロスサイトスクリプティング対策など、多くの工夫が必要だ。また、セッションを乗っ取らないまま被害をおよぼすリクエストフォージェリー攻撃にも用心する必要がある。

   さて、次回の第5回は、5つの脆弱性カテゴリーの4番目「インジェクション攻撃」を取り上げる。

前のページ  1  2  3  4


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


INDEX
第4回:セッション乗っ取り
  はじめに
  セッションIDへの攻撃
  クロスサイトスクリプティング
後を絶たないクロスサイト脆弱性