まとめ
- DAST / SASTの非互換性。
- IAST：流行語と現実。
- 第三の方法。
前述したように 、SASTおよびDAST脆弱性検索システムには長所と短所の両方があるため、アプリケーションセキュリティ分析を自動化するための最適なアプローチを見つける問題はその関連性を失わない。 過去数年間で、この問題を解決するための少なくとも3つのアプローチが開発されました。
方法＃1
最初のサーフェスベースの方法は、DASTとSASTの結果を相関させて共有することです。 理論的には、このアプローチにより、静的解析の結果により動的解析の対象範囲を拡大し、誤検知の数を減らすことができます。 それがIBMの道でした。
これは、メソッドが何らかの方法で動作する方法です
しかし、このアプローチのメリットが誇張されていることがすぐに明らかになりました。 コンテキストを理解せずにSASTからDASTに追加のエントリポイントを転送すると（または、用語を使用する場合は追加の条件）、多くの場合、作業時間が長くなります。 SASTが10000のURLとパラメーターの組み合わせを検出し、DASTに渡したが、そのうちの9990が許可を必要とすることを想像してください。 SASTがDASTに認証が必要であることと、この認証を取得する方法を「説明」しない場合、スキャナーはこれらのURLを愚かにたたき、その操作時間は1000倍になります。 結果に大きな変化はありません。
しかし、これは最も重要なことではありません。 主な問題は、I / Oに対するDASTとSASTの非互換性です。 実際、ほとんどの場合、静的アナライザーの出力で次の情報を取得します。36行目では入力フィルタリングが不十分であり、XSSの実装が可能です。 DASTの場合、ネイティブHTTPリクエストはla / path / api？パラメーター= [XSS]＆topic = importantは脆弱性のタイプを示し、フィルタリング機能を考慮して、ファザーに多くの値があることが望ましいです。
XSSのどこかに... DASTに転送する必要があります！ しかし、どのように？
重要なトピック=重要なパラメータにも注意してください。 これは、ファザーが目的の脆弱なAPIに到達するために満たさなければならない条件です。 path / path / apiにアクセスする際にパラメーターに脆弱性が存在するということは事実ではありませんか？パラメーター= [XSS]＆トピック=その他。 静的アナライザーはこの情報をどこで取得しますか？ 明確ではありません...
複雑さは、フレームワーク、Webサーバー設定、その他の混乱を招く要素だけでなく、 mod_rewriteなどのさまざまなモジュールによって追加されます。
方法＃2
2番目のアプローチは、IAST（インタラクティブまたは本質的なアプリケーションセキュリティテスト）などの現象の世界での出現に関連していました。 本質的に、これは動的分析の拡張であり、アプリケーションのサーバー部分の実行をトレースすることで構成されます（DASTを使用したファジング中）。 これを行うには、Webサーバーインストルメンテーション、フレームワークまたは実行可能コード、または組み込みのトレースメカニズムを使用します。
格納されたXSSとそのSpyFilterトレース
そのため、SQLインジェクションを検索するには、SQL Server Profilerまたは同様のユーティリティの結果を使用すると非常に便利です。フィルタリング機能を介して実際にサーバーに「飛んだ」ものを直接見ることができます。
私は再び少しIASTをやり直したようです...
このメソッドにより、アプリケーションのエントリポイントとソースコードのタイミング（URLからソースへのマッピング）の対応の問題を解決できることが重要です。 これは簡単なことではありません。3段階で行われ、サーバーは計装する必要がありますが、何らかの方法で実装されます。
ハイブリッド分析 HP Look（RAST = IAST）
ただし、IASTには欠点もあります。 まず第一に、Webサーバー（DBMS、フレームワーク）の動的インスツルメンテーションのためのコードインスツルメンテーションおよび（または）エージェントのインストールの必要性。 明らかに、この状況は産業用システムにとって望ましくなく、互換性とパフォーマンスに関しては疑問が生じる場合があります。
また、現在の状態のIASTはDASTの拡張であり（偶然、 Gartnerによって明確に示されています）、このメソッドのプラス面だけでなくマイナス面も継承します。 もちろん、純粋なIASTについてのうわさはありますが、これは侵入検知システムとファイアウォールの可能性が高く、成功した一連の状況下で脆弱性を識別することもできます（これについてはすぐに説明します）。
ノートのトピックに戻ります。 IASTを仲介として使用すると、SASTとDASTの間の互換性の問題が部分的に解決されますが、部分的に解決されます。 場合によっては（特に適切なSASTを使用して）、すべてが非常にうまくいくことがあります。
コベリティ+ NTOSpider-より良い組み合わせ！
ハイブリッド分析の批判は、Chris Eng（ ハイブリッド分析の現実の量、Chris Eng）のレポートに示されています。 彼のレポートの多くは、SASTとDASTの結果の単純な相関、およびIASTを使用したハイブリッド分析に関連していることに注意してください。
方法＃3
アプローチの明らかな煩わしさには、より優れたソリューションが必要です。 そして、そのような決定の出現が近づいていますが、まだどこにあるかは明らかではありません。 彼にとって、対応する言葉はまだ発明されていませんが、科学出版物ではその側面はますます発見されています。 その本質は、中間リンクを必要とせずに静的分析と動的分析を組み合わせることにあります。 つまり、基礎は同じままですが、同時に、潜在的により完全なものとしての静的分析がメイン分析として使用されます。 この問題を解決するために、SASTはDASTが理解できる方法で検証用のデータを準備できる必要があります。 たとえば、必要な追加条件とファジングのパラメーター値のセットを示すHTTP要求の形式。 これを行うことができます：
エクスプロイト、 バックドア 、および
または：
これは二重盲検SQLインジェクションです。時間ベースが必要です...
これを達成する方法は別のメモのトピックですが、ここでは不可能なことは何もありません。 ところで、このアプローチにより、SASTとWeb Application Firewallの統合という別のタスクを実装できます。これは、検出された脆弱性を迅速に閉じるために非常に便利です。
PS誤った印象を与えないために、私たちはまったくIASTに反対していないことに注意すべきです。 「I> S + D！」などの文言に対する反応が鋭さです。このテクノロジーには明確なニッチがあります。 さらに、このメソッドを使用すると、ファッショナブルではない連続監視の概念を実装できます。 しかし、IASTに似た結果を得るには、アプリケーション全体をファジングする必要はありません。また、文字通りの意味で実行する必要がない場合もあります。 しかし、これについては、すでに述べたように-後で。
Positive Technologies Application Inspectorチーム