私の会社には、すべての実動サイトが AppScan セキュリティー・スキャンに合格するという要件があります。SharePoint のインストールをスキャンすると、ソフトウェアがブラインド SQL インジェクションの脆弱性を検出することがあります。これは誤検知であると確信しています。AppScan はおそらく、HTTP 応答内の他のアクティビティをブラインド インジェクションの成功として解釈しています。しかし、これが事実であることを証明することは困難です。
MOSS 07 と WSS 3.0 の両方の SharePoint は、バックグラウンドでのみストアド プロシージャを使用していると思われます。Microsoft からこの趣旨のドキュメントがあるかどうか、さらに、ストアド プロシージャのいずれかが動的に生成された SQL を使用しているかどうかを知っている人はいますか? すべてが sproc であり、いずれも動的ではない場合、SharePoint に SQL インジェクションの脆弱性がないという十分な証拠が得られます。
それらはすべてストアド プロシージャではありません。特に、クロスリスト結合のようなものは、恐ろしい構文を生成します。例として、この記事の SQL トレース ウィンドウを見てください。また、ユーザー コントロールと API 呼び出しの両方を開発者が作成できるため、カスタム モジュールを使用している場合に SQL インジェクションの影響を受けないという保証はありません。
私の推測では、SharePoint は常に、少なくとも名前付きパラメーターを使用します。ただし、最適なオプションは、SQL トレースを実行して結果を比較することです。また、十分な規模の顧客である場合は、ローカルの MSFT エバンジェリストに電話して (またはconnect.microsoft.comに質問を投稿して)、応答が得られるかどうかを確認してみてください。
ありがとう。自分でプロファイラーを調べたところ、いくつかのことがわかりました。SharePoint はストアド プロシージャのみを実行しているようです。純粋な SQL のビットが時折ありますが、これらは "exec sp_oledb_ro_usrname" と "select collationname(...)" に限定されているようです。すべてですが、そのようにプロファイラーに出てくるだけです...?
SharePoint は sp_executesql を使用することがありますが、これはパラメーター化された呼び出しであるため、おそらくインジェクションから安全です。
応答遅延に基づく、比較的新しいブラインド SQL インジェクション ベクトルがいくつかあります。たとえば、WAITFOR DELAY. 少なくとも sqlmap と BurpSuite はそれらを使用します (おそらく他のものも)。
ただし、これらのベクトルは誤検知を起こしやすい傾向があります。トリガーは HTTP 応答の遅延であり、インターネット経由でスキャンしている場合は、他の何千もの理由で発生する可能性があるからです。LAN経由でこれらを取得した場合、私はより疑わしいですが、サーバー側で考えられる他の遅延原因を調査します. 何度も独立して試行して一貫して遅延が発生する場合にのみ、脆弱性に対処している可能性があります。
また、SharePoint は多くの脆弱性スキャナーで古い FrontPage の脆弱性をトリガーすることが多いことにも注意してください。これは誤検知でもあります。詳細については、この記事「セキュリティ スキャナーの結果に含まれる SharePoint および FrontPage Server Extensions」を参照してください。