TOUCH THE SECURITY Powered by Security Service G
こんにちは、セキュリティサービスGの「シン」です。前回はBurpのRepeater機能について説明しましたが、Repeater機能を利用していても途中でセッションが破棄されてしまい、ログイン画面へリダイレクトされたりやエラー画面が表示されて正しいレスポンスが得られないことがあると説明しました。
第三回目となる今回は、Repeater機能を利用するなかで、うまくこれに対処する方法の紹介です。
まず何故セッションが破棄されてしまう場合があるのか、以下のような例があります。
- 一定時間の無操作でセッションが破棄される。
- 不正操作によりセッションが破棄される。
- 正しい画面遷移でアクセスしないとセッションが破棄される。
- パラメータにセキュリティトークンが存在する。
1については定期的にBurpで操作することで対処できますが、2～4などのケースにおいては特殊な操作が必要です。そこで登場するのが「マクロ機能」です。
1.Burpのマクロ機能の例
先ずマクロ機能で何かできるのか、ここでは3点のみ挙げておきます。
| Cookieの引き継ぎ | 対象URLへアクセスする前にログイン実行を行い、ログイン認証状態となるCookieが引き継がれ、セッションが常に有効な状態にします。 |
|---|---|
| 画面遷移の再現 | 対象URLまでの画面遷移を再現して、セッションが常に有効な状態にします。 | 可変パラメータの引継ぎ | 主にクロスサイトリクエストフォージェリ対策に使われるセキュリティトークンのパラメータを引継ぎ、セッションが常に有効な状態にします。 |
尚、今回からCookieとセッションの二つが重要な要素になるので、Cookieとセッションとは何か、以下に簡単に説明します。
2.Cookieとは
Webサーバから送られたユーザ情報やショッピングのカート情報などの情報を利用者のWebブラウザに保存し、以降のWebサイトへのアクセスで自動的に送信する仕組みです。
Cookie による追跡は、ブラウザを閉じるまで行われるものもあれば、ブラウザを閉じてもPCをシャットダウンしてもCookie を削除するまで有効なものもあります。
3.セッションとは
セッション管理とは管理番号のようなものを発行することで、複数にわたる通信間の関連性の管理を実現するもの。この仕組みをセッション管理と呼びます。
-
セッション管理を利用する代表的な例
- ログイン認証状態の管理
- ショッピングのカート情報
- 画面遷移状態の管理
上記の図の④でセッションが開始され、サーバから送信された整理番号がクライアントのブラウザのCookieに保存されます※。その整理番号をセッションIDと呼びます。
※セッション管理方法はCookie以外にも、POSTパラメータでセッション管理をしている場合もあります。
4.マクロ機能によるCookieの引継ぎ
では実際にマクロ機能を使い、1.Burpのマクロ機能の例で挙げた、「Cookieの引継ぎ」を実践してみましょう。以下のような画面遷移フローがあると仮定、対象URLを 5.掲示板に投稿する確認 とします。
上記の画面遷移フローから、ログイン認証状態になるセッションIDが発行され、そのセッションIDがCookieに保存されるのは 2.ログイン実行(login_top.php) になります。
ではBurpを起動してください。Burpのトップ画面から「Project options」タブ⇒「Sessions」タブの「Session Handling Rules」の「Add」ボタンをクリックします。
「Rule Description」に適当な名前をつけます。ここではloginという名前にします。「Scope」タブをクリックします。
URLスコープの「Include all URLs」を選択します。これを選択することで全てのURLにこの機能が適用されます。
続いて「Tools Scope」にマクロを適用したい機能にチェックを入れてください。ここでチェックを入れた機能が今回作成したマクロが実行されます。デフォルトで既に設定されていると思いますが、今回の場合はRepeaterにチェックが入っていれば大丈夫です。
一つ前の画面の「Details」タブへ戻り、「Rule Actios」の「Add」ボタンの一覧から「Run a Macro」を選択します。
「Select macro」⇒「Add」ボタンをクリックします。
「Macro Recorder」が起動し、ここでセッションIDが発行されるログを取得します。「Intercept is on」を押下して「Intercept off」にします。
ブラウザのプロキシ設定をBurpで設定されているアドレスとポートに設定して、対象サイトへアクセスします。
画面遷移フロー2のログイン実行(login_top.php)を操作すると、以下のようにログが出力されます。ログインを実行しているログ(login_top.php)を選択してOKボタンをクリックします。
「Macro Editor」にログが反映されます。「Macro description」には適当な名前を入力します。ここでは「login」という名前にします。
「Configure item」ボタンをクリックします。
「Cookie handling」の上の項目にだけチェックを入れてOKボタンをクリックします。これを選択すると、レスポンスで新たに発行されたセッションIDのCookieを引き継いでくれます。
作成が完了しました。「OK」ボタンを押して終了します。
5.マクロ機能の呼び出し方
マクロ機能を利用するには「Project Options」タブ⇒「Session Handling Rules」の一覧から、先ほど作成した「login」にチェックを入れます。
診断対象のリクエストをBurpで記録して、「Proxy」タブの「HTTP history」タブの一覧から選択。右クリックして「Send to Repeater」をクリックします。
リクエストが反映されたら「Go」ボタンを押下してください。押下すると、以下の対象画面のリクエストが送信される前に、作成したマクロが送信されます。「Go」ボタンを押すたびにセッションID(PHPSESSID)のCookieの値が書き換わっていることが確認できます。
6.まとめ
第三回目はマクロ機能のCookieの引継ぎの使い方について説明しました。サーバ側で画面遷移状態をチェックしていないサイト、またはパラメータにセキュリティトークンが存在しない画面であれば、基本的にCookieの引継ぎのマクロ機能だけで問題なく繰り返してRepeater機能を実行できると思います。
次回は、1.Burpのマクロ機能の例で挙げた「画面遷移の再現（正しい画面遷移でアクセスしないとセッションが破棄される場合の対策）」及び「可変パラメータの引継ぎ（パラメータにセキュリティトークンが存在する場合の対策）」について触れてみたいと思います。
