TOUCH THE SECURITY Powered by Security Service G

ナレッジ

2018.07.26

ローカルプロキシツールBurpの使い方 その4 ~マクロ機能_ 複数画面とトークンの引継ぎ~

こんにちは、セキュリティサービスGの「シン」です。前回はマクロ機能のCookieの引継ぎの使い方について説明しました。Cookieの引き継ぎ設定を利用すれば基本的にセッションが破棄されずにRepeater機能を利用できますが、セキュリティ対策に厳しいサイトの場合、Cookieの引継ぎだけでは正しくRepeater機能を利用できないサイトがあります。

前回も説明しましたが、セッションが破棄されてしまう問題は、以下のような例があります。

  1. 一定時間の無操作でセッションが破棄される
  2. 不正操作によりセッションが破棄される
  3. 正しい画面遷移でアクセスしないとセッションが破棄される
  4. パラメータにセキュリティトークンが存在する

今回は上記の「3.正しい画面遷移でアクセスしないとセッションが破棄される」と、「4.パラメータにセキュリティトークンが存在する」場合に、Burpのマクロ機能を作成してRepeater機能を利用する方法について説明したいと思います。

1.画面遷移の再現

冒頭で触れた「3.正しい画面遷移でアクセスしないとセッションが破棄される」は、操作しているユーザが正しい画面遷移でアクセスしているかを、サーバ側でチェックしている場合に相当します。

攻撃者が用意した罠リンクなどを第三者に踏ませたりする受動的な攻撃は、正規の画面遷移を経ずに直接該当ページを攻撃する場合が多いので、画面遷移のチェックにより攻撃を未然に防ぐことができることがあります。

その他にも入力したパラメータは確認画面へ遷移した段階でサーバ側に保持させていて、送信完了時には入力した情報はパラメータに含めてないような以下の場合があります。

①申込フォーム(input.php) パラメータ:無し
②申込フォーム>確認画面を押下(confirm.php) パラメータ:有り 申込フォームで入力した情報(パラメータ)をサーバへ送信
③申込フォーム>確認画面>送信ボタン押下(complete.php) パラメータ:無し ※②で入力した情報はサーバ側で保持されている

上記例のように③のリクエストだけを送信しても申込情報が無いのでエラーになるため、①~③までの遷移を再現する必要があります。

2.トークンとCSRFについて

冒頭で触れた「4.パラメータにセキュリティトークンが存在する」は、トークンと言われるPOSTパラメータにユーザのセッションと紐付けされた推測困難なランダムの値を送信して、トークンの整合性をサーバ側でチェックすることで、先ほど説明した受動的な攻撃の防止や、特に強制的な実行を防止(クロスサイトリクエストフォージェリ脆弱性、以後CSRF)するために利用されます。

CSRFについてはWebアプリケーションの仕組みに詳しくないと理解するのが難しい脆弱性なので、先ずはCSRFの仕組みについて簡単に説明します。

CSRFとは、攻撃者が用意したコンテンツ上の罠リンクを踏ませること等をきっかけとして、重要な処理を実行させるようにユーザを誘導する攻撃です。前回の投稿でユーザ識別情報となるセッションIDについて説明しましたが、セッションIDは主にCookieに保存され、サイトアクセス時にサーバへ自動的に送信されて受け取ったセッションIDがどのユーザから送られてきたのかを判別しています。CSRFはこの仕組みを悪用した脆弱性です。

CSRF

CSRFの例。ユーザAがブログサイトFにログイン中で、CookieにはブログサイトFのセッションIDが保存されている。

つまりCookieでセッション管理している場合は、ブログ投稿やユーザ情報変更などの処理を実行する機能において、CSRF対策を行わないと攻撃者が用意した罠をクリックすることで強制的に実行させられてしまうわけです。

トークンの値は実行処理前の画面から発行される場合もあれば、画面遷移ごとに異なった値が発行される場合もあります。

マクロ機能でトークンの引継ぎ設定を行なわないと、Repeater機能を利用する時はログ取得時の過去に使用したトークンが毎回使用されるためエラーになってしまうことがほとんどです。そのためパラメータにトークンが存在する場合、マクロでトークンを引き継ぐ設定をする必要があります。

3.マクロの作成方法

では実際に複数画面遷移の引継ぎとトークンの引継ぎマクロ機能とを作成してみましょう。

以下のような画面遷移フローがあると仮定、対象URLを「6.掲示板に投稿する実行(keijiban_comp.php)」とします。

  1. ログインフォーム(login.php)
  2. ログイン実行(login_top.php)
  3. 掲示板一覧(keijiban_.php)
  4. 掲示板に投稿する(keijiban.php)
  5. 掲示板に投稿する確認(keijiban_comf.php)
  6. 掲示板に投稿する実行(keijiban_comp.php)

ではBurpを起動してください。Burpのトップ画面から「Project options」タブ⇒「Sessions」タブの「Session Handling Rules」の「Add」ボタンをクリックします。

「Rule Description」に適当な名前をつけます(ここではtokenという名前をつけます)。「Scope」タブをクリックします。

URLスコープの「Include all URLs」を選択します。これを選択することで全てのURLにこの機能が適用されます。続いて「Tools Scope」にマクロを適用したい機能にチェックを入れてください。ここでチェックを入れた機能が今回作成したマクロが実行されます。デフォルトで既に設定されていると思いますが、今回の場合はRepeaterにチェックが入っていれば大丈夫です。

一つ前の画面の「Details」タブへ戻り、「Rule Actios」の「Add」ボタンの一覧から「Run a Macro」を選択します。

「Select macro」⇒「Add」ボタンをクリックします。

「Macro Recorder」が起動するので、引き継ぎたい画面をキャプチャしていきます。「Intercept is on」を押下して「Intercept off」にします。

ブラウザのプロキシ設定をBurpで設定されているアドレスとポートに設定して、画面遷移フローの6までアクセスしていきます。以下のようにMacroRecorderにアクセスしたログが出力されるので、引き継ぎたい画面のログを選択してOKを押下します(この例では「5.掲示板に投稿する確認(keijiban_comf.php)」までの5つのログを選択しています)。

まずは前回説明した、ログイン実行時に新たに発行されるCookieの引継ぎ設定です。ログイン実行のログを選択して、「Configure item」ボタンをクリックします。
※ログイン実行時および取得したログに新しいCookieの発行が無い場合、この設定をする必要はありませんので4.トークンの引継ぎ方法に進んでください。

「Cookie handling」の上の項目にだけチェックを入れてOKボタンをクリックします。これを選択すると、レスポンスで新たに発行されたセッションIDのCookieを引き継いでくれます。

4.トークンの引継ぎ方法

続いてトークンの引継ぎ設定方法です。

トークンが発行されている場合、レスポンスにトークンが存在するログを選択して「Configure item」ボタンをクリックします。

まず「Parameter name」の入力フォームにトークンのパラメータ名を入力します。

続いて「Define start and end」の箇所に引き継ぎたいパラメータ値の箇所を指定します。

  • Start after expression: パラメータ値の直前の文字列を指定
  • End at delimiter: パラメータ値の直後の文字列を指定

(例)トークンの発行されている箇所が <input type="hidden" name="token" value="XXXXXX"> の場合

  • Start after expression: <input type="hidden" name="token" value=" を入力
  • End at delimiter: "> を入力

すると以下の図のように引き継ぎたいパラメータ値がハイライトされます。
※HTMLレスポンスボディから直接トークンの値を選択した場合でも設定可能です。

OKボタンを押下します。

「Configure Macro Item」のCustom parameter locations in response欄にトークンの引継ぎ設定されていることが確認できます。

以降はすべてOKボタンを押下してTOP画面へ戻ります。

5.マクロを利用

では作成したマクロを使用してみましょう。

機能を利用するには「Project Options」タブ⇒「Sessions」タブ内の「Session Handling Rules」の一覧から先ほど作成した「token」にチェックを入れます。

診断対象のリクエストをBurpで記録して、「Proxy」タブの「HTTP history」タブの一覧から選択して、右クリックして「Send to Repeater」をクリックします。
リクエストが反映されたら「Go」ボタンを押下してください。押下すると以下の対象画面のリクエストが送信される前に、作成したマクロが送信されます。「Go」ボタンを押すたびにパラメータtokenの値が書き換わっていることが確認できます。

補足

トークンの設定方法は他にもあり、以下のような方法でも設定可能です。

「Project Options」タブ⇒「Sessions」タブ内の「Session Handling Rules」の一覧から先ほど作成したものからEditボタンを押下して、以下の画面で「Rule Actions」にて作成したマクロからEditボタンを押下します。

以下の画面で「Update Current request with parameters matched from final macro response」チェックを入れて「Update all parameter except for」を選択した場合、input type属性のパラメータは自動的に引き継がれるようになります。

  • Update all parameter except for: Editボタンから設定したものを除いた全てのパラメータを自動的に引き継ぐ。
  • Update only the following parameters: Editボタンから設定したパラメータだけを自動的に引き継ぐ。

トークンの設定は初めからこの設定でいいのでは?と疑問に思った方もいるかと思います。この設定はinput type属性のパラメータ値のみ引き継いでくれるものであるため、JavascriptやURLのGETパラメータなどのパラメータ値は引継いでくれません。そのためinput type属性以外のパラメータ値は4.トークンの引継ぎ方法で説明した方法でパラメータの引継ぎ設定を行なってください。

6.まとめ

第4回目はマクロ機能の複数画面とトークンの引継ぎ方法を使ってRepeater機能を利用する方法について説明しました。

Cookieの引継ぎ、画面遷移の再現、トークンの引継ぎのマクロ設定ができれば、よほど特殊な作りをしているシステムでない限りエラーにならずにRepeater機能を利用できると思います。

次回の掲載内容はBurpの「Intruder」という機能について説明したいと思います。Intruderは、パラメータの値に挿入したい値を自動で挿入してくれて、なおかつ脆弱性が存在するかの判定(自ら検出トリガーを設定する必要がある)も行なってくれる非常に便利な機能です。この機能はセキュリティチェックしたいパラメータが非常に多い時や、様々な脆弱性チェックをしたいが、チェックしたい項目が多すぎて時間がかかりすぎてしまう時に便利です。

記事一覧に戻る