この記事はIPFactory Advent Calendar 24日目の記事です。
こんにちは、futabatoです。
先日の記事で言及していたCSRF脆弱性検出アプローチに機械学習を取り入れている論文を見つけていたので、論文メモとしてBlogに残しておきます。
まだまだWebセキュリティの用語をきちんと理解できていない部分があるので、ところどころ論文に書いてあることを直訳したが故に変な表現になっている部分があるかと思います。
論文の概要
Calzavara, Stefano, et al. "Machine learning for web vulnerability detection: the case of cross-site request forgery." IEEE Security & Privacy 18.3 (2020): 8-16.
この論文では、Cross-Site Request Forgery(CSRF)の脆弱性をBlackBoxで検出する手法を解説しています。
機械学習によってCSRFの脆弱性がBlackboxで検出できるようになったかというとそうではなく、実際に脆弱性が存在しているのかを判断しているのは分類後の処理です。
機械学習が解いているタスクは「HTTPリクエストをセキュリティ上センシティブなリクエストであるかどうかの分類する問題」で、一般的なWebアプリケーションから収集したHTTPリクエストから教師あり学習で分類器を作成しています。
上記の方法論はBlackBox型のCSRF検出ツールMitchに取り入れられています。
Abstract
In this article, we propose a methodology to leverage Machine Learning (ML) for the detection of web application vulnerabilities. Web applications are particularly challenging to analyse, due to their diversity and the widespread adoption of custom programming practices. ML is thus very helpful for web application security: it can take advantage of manually labeled data to bring the human understanding of the web application semantics into automated analysis tools. We use our methodology in the design of Mitch, the first ML solution for the black-box detection of Cross-Site Request Forgery (CSRF) vulnerabilities. Mitch allowed us to identify 35 new CSRFs on 20 major websites and 3 new CSRFs on production software.
Example: Cross-Site Request Forgery (CSRF)
CSRFはユーザーが認証されている脆弱なWebアプリケーションに対して、攻撃者が制御している不要なHTTPリクエストを送信させるものです。
CSRFの特徴は悪意のあるリクエストがユーザのブラウザを経由してWebアプリケーションに送られるため、ユーザが実際に操作した正規のリクエストと見分けがつかないことです。
Preventing CSRF
CSRF脆弱性を対策するためには、いわゆる"重要な処理"の前に正規のリクエストであるかどうかを確認する必要があります。
ユーザーとのやりとりを増やしてもUXが悪くならないのであれば、再認証を強制したり、ワンタイムパスワードやCAPTCHAを利用することで、Cross-Siteのリクエストが気づかれずに通ってしまうのを防ぐことができます。
また、Samesite属性というものがあり、Cross-Siteのリクエストでのクッキーの付与を防ぐことができるようです。
Samesite cookiesはCSRFの根本的な原因を解決するものなので、新規のWebアプリケーションには強く推奨されます。
しかしながらこの防御策はまだ普及しておらず、既存のWebアプリケーションは通常、以下のいずれかの技術を用いてCross-Siteのリクエストをフィルタリングしているようです。
RefererやOriginなどの標準的なHTTPリクエストヘッダの値をチェックし、リクエストを発信しているページを確認する。X-Requested-Withのような、Cross-Siteからは設定できないカスタムHTTPリクエストヘッダの存在を確認する。- センシティブなフォームに設定した、予測不可能なアンチCSRFトークンの存在を確認する。
最近の論文では、これらの異なるソリューションの長所と短所が議論されています。
上記3つの方法には、セキュリティチェックを慎重かつ細かく配置しなければならないという制限があります。
例えば、UXを損なうことなく完全な保護を実現するためには、アンチCSRFtokenをセキュリティ上重要なHTTPリクエストのすべてに、そしてそれ以外には付けないようにする必要があります。
結局のところ、CSRF 対策の最適な配置を見つけることが一般的に Web 開発者にとって困難な作業です。
最近のWebアプリケーションの開発フレームワークでは自動化されたサポートが提供されていますが、それでもCSRFの脆弱性は日常的に発見されています。
このため、効果的なCSRF検出ツールの必要性が高まっています。
しかし、どのHTTPリクエストが実際にセキュリティ的にセンシティブであるかどうかを機械的に検出する方法がない場合には、どうすればCSRF検出のための自動化されたツールを提供することができるでしょうか。
（ここで機械学習が使えます！って言いたいんだと思います）
Method
この論文が提示した方法論は、次のように要約できます。
教師あり学習により、HTTPリクエスト、HTTPレスポンス、Cookieなどの選択されたWebのオブジェクトを、Webアプリケーションのセマンティクスに基づいて分類する分類器を自動的に学習させます。 CSRFを検出する場合であれば、分類器はセキュリティ上センシティブなHTTPリクエストを識別するために利用されます。
分類器によって返される可能性のある各クラスについて、脆弱性検出のためのヒューリスティックを定義します。 例えば、センシティブでないリクエストはCSRFのために悪用されることはないので、直ちに非脆弱性としてマークすることができます。
例えばWebブラウザの拡張機能として提供された分類器を使って、対象となる各Webオブジェクトで実行する適切な脆弱性検出ヒューリスティックを選択します。
Mitch
Mitchは、CSRFの脆弱性をBlackboxで検出するツールです。 これまでのセクションで紹介した方法論に基づいて設計されており、Webブラウザの拡張機能としてGitHubに公開されています。
(論文が言うにはBlackBoxで検出できる初のツールらしい)
Overview
Mitchは、セキュリティテストが行われるWebサイトで、2つのテストアカウント（ここではAliceとBobとします）を所持していることを前提にしています。
これは、攻撃者（Alice）が自分のセッションで機密性の高いHTTPリクエストを検査し、被害者（Bob）のWebブラウザでそのようなリクエストを偽造するというシナリオをシミュレートするために使用します。
偽造されたリクエストにAliceのセッションに関連する情報が含まれていた場合には、Bobに対するCSRF攻撃ができない可能性があるため、2つのテストアカウントを持つことはツールの精度を高めるために重要です。
例えば、WebサイトがアンチCSRFトークンを使って適切にCSRF脆弱性を防御している場合、AliceのリクエストはBobのセッションで拒否されます。 CSRFを検出するために2つのテストアカウントを使用することは、すでに以前の研究で提唱されており、テスト戦略の一部となっています。
Mitchのアーキテクチャを以下の図に示します。
Mitchをブラウザにインストールした後、セキュリティテスト担当者は、まずAliceとしてWebサイトを閲覧します。
分類器によって機密性が高いと検出されたすべての HTTP リクエストについて、Mitch は対応する HTTP レスポンスのコンテンツを保存します。
Webサイトの閲覧後は、Mitchは収集したセンシティブなHTTPリクエストを使用して拡張オリジン(?, extension origin)に新しいHTML要素を生成して再現できるようにします。
次に、セキュリティテストの担当者はBobとしてWeb サイトで認証を行い、Mitch は生成されたHTMLを利用して、検出されたセンシティブなリクエストをCross-Siteから自動的に再現し、CSRF 攻撃をシミュレートします。
最後に、AliceとBobで収集したレスポンスを比較します。
Bobが受け取ったレスポンスがAliceが受け取ったものと一致した場合、AliceがBobのセッションに対して有効なリクエストを偽造できたことを意味します。
Challenges
現実的にはいくつか課題があるようです。
課題とその解決策についても言及されています。
HTTPレスポンスの変化
HTTPレスポンスが動的に生成され、同じ操作を複数回行った場合でも現実的には異なるレスポンスが返ってくる可能性があります。
そのため、Mitchでは非類似HTTPレスポンス(dissimilar HTTP responses)という概念を構築しています。
一般にHTTPレスポンスの非類似性は、失敗を表すStatus CodeやContent-Typeが異なることなどにより、類似性よりもはるかに容易に確認できるます（例えば、401 Unauthorizedや403 Forbiddenは、不正アクセスを表すもの）。
Bobの応答がAliceの応答と異なると、AliceのリクエストがBobのセッ ションで失敗した可能性が高く、それはCSRF防御機構の存在を示しているかもしれません。セッション状態の変化
WebサイトにおけるAliceとBobの状態は異なるかもしれないので、Bobが受け取ったレスポンスをAliceが受け取ったものと照合することは、CSRFの脆弱性を検出する不適切な方法かもしれません。
例えば、Bobはファイルfooへのアクセス権を持っていないので、機密性の高い操作を実行できないかもしれませんが、ファイルbarをターゲットにした場合、CSRF攻撃は機能可能性はあります。
Bobが受け取ったレスポンスとAliceが受け取ったレスポンスを比較したとき、Mitchはその違いをBobのリクエストがCSRF防御機構の利用によってAliceのリクエストとは異なる結果になったという決定的な証拠としてすぐには考えません。むしろ、AliceとBobのセッションの状態の違いによって異なる結果が生じる可能性があるため、MitchはAliceのオリジナルのリクエストを新しいAliceのセッションで再現します。Aliceが受け取った新しいレスポンスがオリジナルのものと異なる場合に、リクエストの処理にセッション依存の情報が必要であると考えられ、CSRF対策トークンが採用されている可能性があると判断しています。分類エラー
非常に正確な分類器であっても、センシティブでないリクエストを誤ってセンシティブなものとして分類してしまう可能性はあります。
この場合、CSRFの脆弱性は存在せず、AliceとBobのセッションで一致するレスポンスがあっても、警告を発するべきではないはずです。
分類器によって生成された誤検出の可能性を判断するために、MitchはAliceのオリジナルリクエストを、最初にWebサイトで認証することなく、セッション外で再現します。取得したレスポンスが元のレスポンスと異なる場合に、要求された操作の実行には認証されたコンテキストが必要ということからCSRFが存在する潜在的な可能性があることが確認されます。
Machine Learning Classifier
ここにはMitchが利用している分類器についての言及がありますが、各特徴量についての定義が書いてあるだけで特にメモとしても残しておく必要のないものなので、割愛します。
独自に構築されたデータセットから分類器を作成する話は以下の論文に書かれていそうなので、次回の記事にしたいと思います。
若干歯切れの悪い形にはなってしまっていますが、これ以降特に論文メモにしておく情報がないのでここで終えたいと思います。
最後までご覧いただきありがとうございました。
この記事はIPFactory Advent Calendar 24日目の記事です。
昨日23日はdaiki0508くんによる「BackDoorAPK解析してみた」でした。
