久しぶりに記事を更新したいと思います。本日は、Webアプリケーションについての思考実験をしてみたいと思います。
既にご存知の通り、Webアプリケーション診断の脆弱性スキャナとして、様々な製品が登場しています。
- IBM AppScan
- HP WebInspect
- Rapid7 AppSpider
これらの製品は、XSS（Cross Site Scripting）やSQLインジェクションといった「機械が発見を得意とする脆弱性」には非常に有効ですが、Webアプリケーションの脆弱性には「機械が発見を苦手とする脆弱性」もいくつか存在します。
今回は、「機械が発見を苦手とする脆弱性」を補う方法を検討します。
機械が発見を苦手とする脆弱性
その代表的な脆弱性が、「アクセスコントロールの不備」や「ビジネス・ロジックの悪用」に関する脆弱性です。
アクセス・コントロールの不備
アクセス・コントロールの不備とは、「本来閲覧権限のないデータを閲覧可能である」、あるいは「本来利用できない権限の機能を利用できる」という脆弱性です。アクセスコントロールの脆弱性は、大きく２種類に分類されます。
- 横のアクセスコントロール不備
- 縦のアクセスコントロール不備
横のアクセス・コントロール不備
例えば、ECサイトなどで、ユーザAがパラメータを改竄することでユーザBさんの購入履歴を盗み見ることができる場合など、同じ権限レベルで他のユーザのデータが閲覧できてしまうことを横のアクセス・コントロール不備といいます。日本では、なりすましの脆弱性と呼ばれます。
縦のアクセス・コントロール不備
例えば、一般ユーザが管理者のみが利用できる承認機能を利用できてしまう場合など、低い権限レベルのユーザが高い権限レベルのデータ・機能を利用できてしまう場合、縦のアクセス・コントロール不備といいます。日本では、若干複雑で認証がされていない状態で特定の機能を悪用できてしまうことを認証回避の脆弱性、認証がされた低い権限レベルから高い権限レベルのデータ・機能にアクセスできる場合、権限昇格の脆弱性と呼ばれたりします。（人により使い方は異なるので、私の個人的な分類です。）
ビジネス・ロジックの悪用
機械では発見しづらい脆弱性として、「ビジネス・ロジックの悪用」という脆弱性があります。一般にシステムとは、ビジネスの流れをモデル化してビジネスルール・ワークフローを機械化したものだと定義されます。そのモデル化の不備を悪用した場合、本来の意図とは違う結果を出力されてしまいます。
例えば、ECサイトなどでは、商品の購入数を９個などと指定し、その個数と商品単価を掛け合わせて支払い金額を算出するなんてことは一般的です。
じゃがいも（１００円）×９個 = ９００円
カレー（２００円） ×６個 = １２００円
→合計２１００円
しかし、もし個数に負の値を指定できれば、合計金額を改竄することができてしまうかも知れません。
じゃがいも（１００円）×ー９個 = ー９００円
カレー（２００円） ×６個 = １２００円
→合計３００円
さすがにこのような例を持つアプリケーションはないでしょうが、これは購入時に指定する商品個数が正の値であるというビジネスルールのモデル化に失敗しているからにほかなりません。
これに限らず、本来人間が処理すれば普通は気付くような問題でも、システムは自分で考えて処理をせず記述された通りに動くため、このような脆弱性悪用が成立してしまいます。
なぜ機械は、これらの脆弱性の発見を苦手とするか？
これらの脆弱性を機械が苦手とする理由は簡単です。
脆弱性スキャナは一般にブラック・ボックステストと呼ばれ、システムの仕様を知らない状態で検査を行います。そのため、機械ではこれらの脆弱性を攻撃したときに、結果が問題ないのか、脆弱性と考えるべきなのか判断できないという点です。言い換えれば、攻撃成功時のパターンを記述・訓練することが難しく、システムを正確に理解している人でないと判断ができないという点です。
上記の例でいえば、300円という値が問題ある値なのか、その判断基準を機械に教えない限り、機械は判断することができません。また、あるデータがパラメータ改竄により閲覧できたことが果たして仕様と照らし合わせて問題があるのかないのか、仕様を正確にツールに教えない限り判断ができません。
NRIセキュアのレポートでも、「危険度の高い脆弱性の約３／４は、機械化された検査では発見できない」と指摘をしています。そのため、個々のアプリケーションの仕様を踏まえた検査が専門家の検査が必要になってきます。
www.itmedia.co.jp
本題：クラウドソーシングで機械化された検査の欠点は補えるか？
さて、ここからが本題の思考実験です。
課題：
「アクセス・コントロールの不備」や「ビジネスロジックの不備」については、仕様を理解し、かつ脆弱性の発見手法や様々な攻撃パターンを経験した専門家でないと発見できないという前提があります。しかし、専門家のコスト（特に両面に熟知した専門家）のコストは非常に高く、おいそれと気軽に活用できないという問題がありません。
特に、システム変更の動きが早いオンラインゲームやネットサービス系ではそのたびに専門家を雇っていたりすることは難しいでしょうし、専門家を社員として雇える企業も限られていると思います。
要素分解して考えてみる
前のポイントをまとめてみると、アクセス・コントロールの脆弱性発見には、「脆弱性の発見手法の理解」×「システム仕様の理解」が欠かせないという点が上げられます。
図示すると、以下の通りのイメージですね。
では、これらを要素分解して、専門家以外の人で同じことを実現できないか、検討してみたいと思います。
要素１：「脆弱性の発見手法の理解」について
脆弱性の発見のためのパラメータ改竄は、脆弱性スキャナは非常に得意としています。HTTPの内容を解析し、送信されているパラメータの値を改竄するだけなので数値をずらすなどは機械でも簡単に可能です。ツールで発見が難しいのは、脆弱性が存在するか否か判断することが難しいだけであって、攻撃自体はツール化すること事態は可能です。そう考えると、脆弱性の発見手法のノウハウさえ、ツールに書き込んでしまえば、ある程度機械に任せることができるのではないかと考えられます。
要素２：「システム仕様の理解」について
システムの仕様自体は別にセキュリティの専門家でなくても知っている人はいます。
代表的なレイは、普段からシステムを利用しているユーザです。普段から利用しているユーザであれば、どんなデータが見えたらおかしいか、どんな機能が使えたらよくないのか判断できるノウハウを持っていると言ってもよいはずです。
より専門的には、このような人たちをレイ・エキスパート（Lay Expert・素人の熟達者）とよんでおり、様々な分野で彼らの知見を活用すべきという議論がありますが、それと同じ考え方です。
「ツールによる脆弱性攻撃」×「レイ・エキスパートの判断」
さて、これらを組み合わせると以外にも「アクセス・コントロールの不備」なども専門家の手を借りずにテストできるのではないでしょうか？
例えば、以下のような流れで検査はできないでしょうか。
- ユーザ（レイ・エキスパート）のブラウザのプラグインか何かをいれてもらい、通常通りシステムを使ってもらう。
- そのプラグインが通常遷移の途中で、急に一部のパラメータを改竄してリクエストを送信する（改竄により攻撃を試行する）。
- プラグインが、ポップアップなどをあげユーザに「想定した結果が表示されていますか？」などと聞き、YES / NO形式などで回答してもらう（レイ・エキスパートに判断をしてもらう）
こんな流れでやっていけば、専門家を使わずとも検査ができるのではないでしょうか。当然、レイ・エキスパートはセキュリティ診断の専門家ではありませんので、間違えることもありますし、勘違いの可能性もあります。そのため、ある程度複数回の試行をする必要があると思います。ある程度の試行回数をするために、クラウド・ソーシングという形を使うというのが解決策になるのではないかと考えています。あるいは、ヘビー・ユーザにツールをいれてもらい、回答するたびにポイントなどをあげるなんていうのも有効かも知れません。
図示すると、以下の形になります。
まとめ
もともと、大学院の研究の一環として検討していたテーマなのですが、意外とこの仕組みを作ることが難しく、時間がかかりそうであまり進んでいないテーマです。（本来は査読なし論文にまとめて論文を出すべきなんですが、いかんせん仕組みができていないのでデータがなく、まだアイディア段階なので公開して誰かの役にたてばよいのではないかと考えています。）
