1

セキュリティ認証を取得するために、Veracode によってスキャンされている .Net 4.0 プロジェクトがあります。

静的スキャン中に次の脆弱性が発見されました: SQL コマンドで使用される特殊要素の不適切な中和 (「SQL インジェクション」) (CWE ID 89) https://cwe.mitre.org/data/definitions/89 で詳細を参照してください。 html

Dapper を参照していると思われるレポートの詳細ファイルと行番号:

OurOwnDll.dll dev/.../dapper net40/sqlmapper.cs 1138

App_Browsers.dll dev/.../sqlmapperasync.cs 126

OurOwnDll は Dapper を使用しています。

App_Browsers.dll どこから来たのかはわかりませんが、サイト プロジェクトに関連しているようで、asp.net のブラウザ機能の検出に関連しているようです。

この脆弱性を防ぐ方法があれば教えてください。

4

1 に答える 1

0

私は VeraCode に精通していませんが、@Kristen Waite Jukowski が指摘したように、クエリの一部がパラメーター化されていないことが原因である可能性があります。この場合、クエリは SQL インジェクションに対して脆弱であると正しく識別されています。

あるいは、同様の質問(同じ問題に関連しているが OrmLite に関するもの) がこれに光を当てる可能性があります。OrmLite と同様に、dapper はパラメーター化されていない入力(文字列連結など) で構成できる未加工の SQL クエリを作成する機能を提供するため、特定のプロジェクトのすべてのクエリが現在完全にパラメータ化されています。その質問に対する答え (あなたのケースでは実行できないかもしれません) は、既存の ORM を Entity Framework に置き換えることでした:

VeraCode を使用したコードの読み取り中に推奨される適切な修復は、ServiceStack ORM を EntityFramework 6.1 に置き換えることでした。

その質問のコメントから：

違いは EF にあります。実行コンテキストは IDbCommand を実装しますが、動的 SQL を許可できる CreateDataAdapter およびその他の API は例外をスローするように実装されています。EF には、最初に OWASP と同様のフィルタリング メカニズムを経由せずに動的 SQL を許可するコード パスはありません。

于 2015-09-15T09:44:12.790 に答える