0

バイナリを作成するために書かれた C++ コードの静的解析を強化しようとしています。ただし、このビルドは完了するまでに数時間 (場合によっては 1 日以上) かかります。

これを回避するために、ターゲットとして使用する偽のアーカイブを作成して、すべての .o ファイルを単独でビルドしてみました。このアプローチの利点は、私たちのチームがコードを所有していないため、ビルドする必要がなく、リンク時間を節約できることです。これを行うと、ビルド時間が大幅に短縮されます。

しかし、私のチームの 1 人は、これは私たちの所有外のコードとの相互作用を見逃しているため、誤検知や誤検知につながる可能性があると感じています。彼が挙げた例は、私たちの所有外のライブラリへの API 呼び出し間の共有オブジェクトについてでした。つまり、ドメイン外のオブジェクトの操作を知ることができなくなります。しかし、すべてのファイル所有者が自分のコードに対して同じことを行う場合、これは処理されませんか?

私のアプローチが正しいかどうかアドバイスしてください。

4

1 に答える 1

1

あなたのアプローチは誤検知につながる可能性がありますが、さらに悪いことに、誤検知の可能性が高く、リスク評価が低すぎる可能性があります。

データ フロー アナライザーは、グローバルな手続き間の汚染伝播分析を使用して、ソース(ユーザー入力) とシンク(危険な関数呼び出し) の間のデータの流れを検出します。

データ フロー アナライザーがシンクを見つけられない場合、アナライザーはこの汚染伝播の追跡を停止し、脆弱性を見逃して別の場所に移動します (偽陰性)。

次の疑似コードは、PII 露出とSQL インジェクションの両方の例です。

public static void main(String args[]) throws Exception {
  ResultSet results = SQLInj(args);
  System.out.println(results.Password);
}

public static ResultSet SQLInj(String args[]) {
  String query = "SELECT * FROM user_data WHERE last_name = '" + args[1] + "'";
  Statement statement = connection.createStatement();
  ResultSet results = statement.executeQuery(query);
}

ソースはmain- >args[]で、シンクはSQLInj->executeQuery()です。

関数SQLInjがスキャンされていないコード (チームのコードではない) にある場合、データ フロー アナライザーはシンクを見つけられないため、SQL インジェクションの問題は見つかりません。PII エクスポージャーは、セマンティック アナライザーが「password」という単語を検索することで検出できますが、信頼度ははるかに低くなります。

于 2013-04-02T17:43:55.783 に答える