prototype pollution static analysis
1.0.0
この研究は、2018年に最初に発見された「新しい」タイプのセキュリティの脆弱性であるプロトタイプ汚染の脆弱性に焦点を当てています。この脆弱性は、JavaScriptのプロトタイプ指向設計を活用します。他のほとんどのオブジェクトがプロパティとメソッドを継承するオブジェクトなどのネイティブオブジェクトのプロトタイプを変更することにより、特定のアプリケーションのロジックに応じて、他のほぼすべてのWeb脆弱性にエスカレートすることが可能になります。
GitHub Advisoryやその他のソースなどの脆弱性データベースを検索する実際の単語プロトタイプ汚染脆弱性の例を含むJavaScriptコードを収集しました。収集された例が実際に脆弱であることを確認するために、脆弱な機能ごとに簡単な概念のエクスプロイトを書きました。脆弱なアプリケーションに対して検討された静的分析ツールを実行しました。脆弱性データセットの中で、脆弱性につながるさまざまなコードパターンを説明するために詳細に分析したいくつかのケーススタディを選択しました。これらのケーススタディは、各ツールの長所と制限を強調できる興味深い結果を示すために選択されました。
Odgen/Objlupansysプロトタイプチェーンに基づいてオブジェクトのルックアップを成功させるオブジェクト依存グラフに基づく新しいアプローチは、ほぼすべての脆弱性のケースを検出できます。ただし、現在の実験的実装は、いくつかのコードパターンに遭遇すると、バグの影響を受けます。また、大規模なパッケージまたは特定のパターンを分析する際に、深刻なパフォーマンスの問題に苦しんでいます。また、先行する脆弱な機能のパッチバージョンに対して実行された場合、虚偽の陽性にフラグを立てる傾向があります。
SEMGREPルールは、非常に高い偽陽性率を持たなくても、このケースを含めることの違いにより、直接割り当てなどのすべてのケースをカバーするものではありません。 SEMGREPエンジンは、限られた陽性データフロー分析のみを提供し、予想どおり、異なる機能に分布する脆弱性を常に検出することはできません（たとえば、間接的な再帰コールなど）。ほとんどの緩和手法は考慮されていないため、ルールは、先行する脆弱な機能のパッチ付きバージョンに対して実行されたときに多くの誤検知をフラグします。
CodeQLは、収集されたほぼすべての脆弱性の例を識別できます。考慮されるクエリはよく書かれているように見えますが、遭遇する問題は閉じたソースエンジンの制限の可能性が最も高いです。誤った郵便に関する関係については、ほとんどの緩和手法が考慮されるため、CODEQLクエリは他のツールよりも大幅に優れたパフォーマンスを発揮します。
論文PDFの詳細
