初めまして、昨年度年よりプロフェッショナルサービス事業部に配属となりましたセキュリティ診断エンジニアです。
本稿では、Webセキュリティ初心者によるWebセキュリティ初心者に向けた手動診断の進め方や考え方をご紹介したいと思います。
なお、今回ご紹介する内容が正解というわけではなく、あくまで無数にある内の一つとして参考にしていただければ幸いです。

はじめに

弊社では入社後にトレーニング研修というものを行います。研修は研修用の資料を用いて行い、HTTPの基礎から各脆弱性の詳細な解説が記載されています。しかし、内容の密度や質の違いはあれどインターネット上にも同様の情報は探せばいくらでもありますが、実際に診断を行う際の流れについて紹介している記事はあまり見かけません。

もちろん、そういった内容は攻撃の助長になってしまったり、ある程度理解している方からすれば自明の内容であり、あえて記事にすることもないというのも一理あります。それでも、私を含めて「各脆弱性はわかったし再現方法もある程度理解したけど、実際にどうやって診断したらいいの？」という初心者の方も少なからずいるかと思います。

そこで、今回は（強制ブラウジング）Forceful Browsingを題材に診断の流れの一例を実際にWebサイトの診断を行いながら解説していきます。

脆弱性診断の流れ

まず、診断の流れとして大まかに以下のような流れで進めていきます。

対象サイトの調査 -> 各機能の内包していそうな脆弱性の列挙 -> 診断実施

流れにしてみるととても単純であることがわかります。では、この流れにしたがって実際にショッピングサイトを模した簡単なWebサイト(以降やられサイト)へ診断を行っていきますが、これから実際に診断を進めていく前に、やられサイトについて本稿での定義をご説明します。

Web診断の学習を行う際に、インターネット上に公開されているショッピングサイトやブログサイトなどの実稼働しているサイトに対して行うと、法律に引っ掛かってしまい、いわゆるクラッカーになってしまいます。(クラッカーについての説明は割愛します)

そこで、実際に攻撃を行うことを前提として自前のサーバで構築したり、場合によっては学習用として善意のユーザによってインターネット上に公開されているサーバである「やられサイト」と呼ばれるWebサイトが必要となります。このやられサイト上で検証や学習を行うことで、法律に引っ掛かることなく思う存分攻撃を行うことが出来ます。

また、こうしたやられサイトを自前で構築する際に、一から開発するのも良いですが、こちらも善意のユーザにより公開されているやられサイトのプログラムや、それらを簡単に導入してすぐに学習を開始できるような方法が存在しています。

少し脱線しましたが話を戻して、まず初めに行う必要がある手順が「診断対象のサイトの調査」です。ここで必要な観点としては、対象のサイトが持つ機能の把握とその機能を実行した際の結果、そしてその機能を誰が使用できるか、ということです。もちろんそれだけではありませんが、今回の題材である「Forceful Browsing」に関していえばこのような観点で充分でしょう。

さて、実際に機能を列挙する方法ですが、色々な方法がありもちろんBurp Suiteのスキャナのように自動でリクエストの一覧を取得してくれるものもあります。しかし、結局は人の手で挙動を確認する必要があるため基本は手動で巡回してツールはその補助として取りこぼしの確認を行う、といった方法がオススメです。

また、記憶力の良い人であれば話は別ですが、大抵の場合すべての機能を把握するというのは難しいため、巡回時に発見した機能はExcelでまとめたりしますが、ISTEというとても優秀なBurp Extenderがありますので、こちらを駆使してリスト化することで作業効率が大幅に上げることが出来るためお勧めです。(本稿でもISTEを使用しています)

やられサイトについて

今回診断を進めていくサイトの機能一覧は以下になります。

• トップページ
• ログイン/ログアウト
• 会員登録
• 商品購入
• 購入履歴

また、やられサイト上では「管理者」と「ストアマネージャー」という2種類の特権ユーザが存在しており、特権ユーザでのみアクセス可能な機能が存在しています。

• 商品編集・登録(管理者・ストアマネージャ)
• デバッグ機能(管理者のみ)

診断

やられサイトに対して巡回が完了したという前提で、先ほどの機能一覧を基に実際に各機能の動作を確認していきます。なお、本来はすべての機能に対して診断を実施するべきですが、今回は脆弱性の存在する箇所のみに絞っています。
まず初めに、やられサイトにアクセスした上でログインを行った際のトップページが以下になります。

さらに、「Item List」から商品ページに飛んでみると、商品の詳細が表示されます。

この画面をよく見ると、URLのPathの中に商品IDと思われる数値が含まれています。
つまり、このIDを変更することで他の商品も参照できることになり、例えば未発売の商品のページを開けるかもしれません。
確認のために他の商品詳細ページへアクセスした際のPathも調査してみると、予想通り数値は商品IDであり、連番であることがわかります。

そこで、例えば一覧に表示されていない商品IDを指定するとどうなるでしょうか。
試しに商品ID「7」でアクセスしてみると、正常に商品ページが表示されていることがわかります。

この商品は既に在庫がなく一覧に表示されていないのにも関わらず、商品IDを直接指定することで本来表示されることを想定していないページを発見することが出来ます。
しかし、ここまで極端なIDの振り方をするWebサイトはない(と願いたい)ため、実際にこういったページを完全に手動で発見することは難しいです。そういった場合は、BurpのIntruderという機能を使用することでこの手順をある程度自動化できます。

Burp Intruderを使用して調査を行った結果が以下になります。

今回は単純な連番の数値でしたが、実際のシステムでは数値ではない場合や連番ではなく乱数 を基にして生成した推測しにくい文字列や数値を使用しているなど様々なため、環境に合わせたペイロードを作成する必要があります。

次に、商品を購入した際に記録される「購入履歴」機能について調査を行います。実際に何件か購入した際に出力される購入履歴は以下のようになります。

今回はデモのためわかりやすくするために単純な連番の数値を使用していますが、画面のIDを指定することでそれぞれの購入履歴を参照することが可能です。実際にアクセスすると、以下のような画面が表示されます。URLに注目すると、先ほどの商品詳細と同様にIDをそのまま指定すると参照出来ることがわかります。

つまり、先ほどと同様の手順でアクセスすることで、本来できるはずのない他人の購入履歴を勝手に覗き見ることが出来てしまう、なんてこともあり得るかもしれません。
実際にIntruderを用いて試してみると、以下のような結果のように401エラー、つまりは認証エラーによりアクセスできなかった旨が返ってきてしまうため、アクセス制御が正常に行われていることがわかります。

つまり、他ユーザの購入履歴を直接アクセスして取得することはできないということになります。
しかし、先ほどの正規アクセスした際の購入履歴詳細を再度確認すると、購入履歴をPDFで出力する機能があることがわかり、さらに購入履歴のIDと一致する数値を指定しています。

実際にアクセスしてみると、IDを指定しているのはあくまで表面上のURLであり、実際にはリダイレクト先で別のIDを指定することで購入履歴をダウンロードしていることがわかります。
すこしわかりずらいですが、下のHTTP Historyの内容をよく見ると、「http://example.local:5000/receipt/7」というURLにアクセスすることで購入履歴をダウンロードしているようにみえます。
しかし、実際にはただリダイレクトしているだけであり、そのリダイレクト先のURLである「http://example.local:5000/receipt/dcbd57dd...」というURLからダウンロードしています。

ここまでで購入履歴を取得するための流れは把握できたので、次にそれらのリクエストをRepeaterへ送信して診断を実施してみます。
購入履歴IDを指定しているリクエストのID、先ほどの例でいうところの「/receipt/7」の7という値を他人のIDに書き換えて送信してみると、正常にアクセス制御が行われているためか認証エラーが表示されてしまいます。

次に、リダイレクト先の実際にファイルをダウンロードしているリクエストに対しても同様に診断を行いたいのですが、これまでと異なり連番や推測が容易な値ではなくランダムまたはハッシュ化した値をIDとして使用しているため、単純に他人のIDと想定される値を指定して診断を行うことが出来ません。
そこで、今回は別のアカウントでログインした上で生成される、別の購入履歴をダウンロードする際のIDを利用して行います。
先述の方法で取得した別のアカウントにて生成されたIDに書き換えてリクエストを送信した結果が以下になります。

ダウンロードを行うURLを直接指定することで別ユーザの購入履歴をダウンロードすることが出来ました。
このように、入り口となる機能においてはアクセス制御が行われていても実際の機能実行や参照時にはアクセス制御が行われていないという可能性が存在するため、実際に診断を実施する際にも大切な観点となります。

ここまでは実際に導線が存在する、「サービスとして公開している機能」に対しての診断を行ってきました。しかし、Webサイトは必ずしも意図したものだけを公開しているわけではなく、例えばコンフィグファイルやGitを使用していれば.gitなどが見つかる場合もあります。また、その他にも開発者や管理者がメンテなどの目的で公開しているデバッグ機能が一般ユーザにも使用できてしまうというケースも存在します。
さらに、複数の権限が存在していたり、複数のECサイトをホスティングしているサイトの管理を行うサイトマネージャーと、そのすべての管理権限を持つスーパーユーザの区別が出来ていないなどのアクセス制御が不適切なケースも存在します。

前置きが長くなってしまいましたが、今度は管理機能に対して診断を行うデモとして、商品管理機能について診断を行っていきたいと思います。

ストアマネージャ権限をもつユーザでログインすると、商品一覧に編集機能へのリンクが増えていることがわかります。

編集機能へアクセスすると、商品名や金額、在庫数などの値を変更できることができます。

この機能を使用することが出来るのは、冒頭でも挙げたように管理者もしくはストアマネージャ権限をもつユーザのみを想定しています。では、本当にそれ以外の権限でアクセスできないか確認してみます。
一旦ログアウトする、もしくは別のブラウザで一般権限のユーザでログインして先ほどの管理ページへのURLをコピーして直接アクセスしてみます。

「Taro Yamada」というユーザは管理者でもなければストアマネージャでもありませんが、編集画面へアクセス出来てしまいました。
このように、例え導線がなくともリンクさえわかってしまえば機能へアクセス出来てしまうため、購入履歴のダウンロード機能や非表示の商品ページと同様に「導線がない＝安全」という考えは間違っており、診断する上でもこうした観点で行うことで越権行為が可能な機能を発見できる場合があります。

次に、デバッグ機能といえば様々な機能が思い浮かぶと思いますが、このサイトでは以下のようなSQLを直接実行できるプロンプトが用意されています。

見ていただければわかる通り、この機能は本来管理者のみが実行可能であり、ストアマネージャであってもこの機能へのアクセスは禁止されている想定です。
ここまでの流れと同様に、まずは一般ユーザ権限でアクセスしてみると、一見正しくアクセス制限がなされているように見えます。

しかし、ストアマネージャ権限でアクセスしてみると仕様に反してアクセス出来てしまっています。

このようになる原因は、一般ユーザ権限でのアクセスは拒否する実装にはなっているものの、ストアマネージャ権限でのアクセスを適切に処理出来ていないことが挙げられます。
実際に、当該機能のアクセス権限の処理を抜粋したものが以下になります。

「g.user.authority」にはログインしているユーザの権限情報が格納されており、格納されている数値によって権限を判別しています。

ここで問題となるのは、本来「g.user.authority <= 1」もしくは「g.user.authority < 2」とするべきところを「g.user.authority < 1」としてしまっているため、ストアマネージャより低い権限のアクセスを拒否と解釈してしまい本来アクセスできないはずのストアマネージャからアクセス出来てしまっています。

ここまでずさんな権限管理をしていることはあまりないと信じたいですが、こういった実装をしているサイトが存在していることは事実であり、アクセス制御に漏れや抜けがあるといったケースは十分に考えられます。
まさに、先ほど見てきた購入履歴の閲覧機能がその一例で、入り口である閲覧履歴画面は適切にアクセス制御が行われていても、その先の購入履歴のダウンロード機能ではアクセス制御が漏れていたために機能を悪用されてしまいました。

このように、診断を行う際には複数の権限のユーザを利用できる場合にはすべての権限で調査を行うべきであり、開発者としてもこういった点は特に注意して検証するべき観点です。
具体的には、これまでに紹介してきた機能においてのアクセス権限の検証は当然として、データベース上のテーブルそのものへのアクセス権限や、テーブル内においてもユーザごとに参照権限を持たせるべきものが無いか、もし存在する場合には参照できる権限を厳密に定義づけする必要があるため、コードだけではなく設計レベルから十分に権限チェックが行われているかを検討した上で開発を行う必要があります。

ここまでのデモではあくまでIDを知ることができる前提であったり、このIDを予測あるいは知るすべがなければ実際に悪用できない、つまりはURLを知らなければアクセスできないので安全だと考えてしまう方も少なくないと思います。
確かに、脆弱性が存在していてもこのURLを予測できなければアクセスできませんが、もしこの生成ロジックを見つけることができた場合その限りではありません。
実際に、PDFのダウンロード機能において生成しているIDは各購入履歴のIDとユーザID、合計額を基にMD5でハッシュ化した値という極めて単純なロジックで生成されています。

どこかの誰かが過去に購入したであろう購入履歴を闇雲に探しても有効なIDを見つけられる可能性は限りなく低いですが、あるIDと同値となるMD5ハッシュを生成するロジックそのもの割り出すのであれば成功する可能性は高くなります。

つまり、生成ロジックさえわかってしまえばあとはそのロジックにしたがって有効な値をひたすらに生成しながらアクセス試行するだけのため、予測が難しいトークンやURLパスを用いていてもセキュリティ対策にはなりません。
逆に言えば、診断を行う側としてはそのような考えからアクセス制御を適切に行っていない箇所を見つけ出す必要があります。
したがって、可能であれば権限ごとやアカウント毎の認証情報でのアクセスの試行や、そもそも権限を持たないいわゆるゲスト権限でのアクセス時にアクセス制御をバイパスしてデータの参照や機能の実行が出来ないかを調査する必要があります。

結び

今回のデモサイトのような極端なつくりをしているサイトというのは非常に稀だと思いますが、考え方としては共通しており、基本的には本来の仕様に反した情報の参照や機能の実行が行えないか、アクセス制御に抜け漏れがありサイトが想定している通りの挙動となっているかを確認する必要があります。