簡単な説明：
不適切なアプリケーション検証により、無効なデータが SQL Server 2012 で実行される SQL 更新ステートメントに渡され、アプリケーションによって処理されないサーバー側エラーが発生します。データベースのセキュリティの観点から、これが悪用される可能性はありますか?
バックグラウンド：
私はフルタイムのセキュリティ専門家ではなく、セキュリティ関連の質問があり、できれば簡単な答えが得られることを願っています。「ブラック ボックス」アプローチを使用した「既製品」の Web アプリケーションの潜在的なセキュリティの脆弱性を調査していて、懸念の原因に遭遇しました。アプリケーションは、いくつかの nvarchar フィールドのデータ入力の長さの検証に失敗したようで、入力データを直接データベースに渡します。データがデータ型の長さ制限に違反している場合でも、アプリケーションはすべてが正常にコミットされたと主張します。書き込みを試みるとサーバー側でエラーが発生し、データがデータベースにコミットされないため、これはアプリケーションの検証のみに基づくステートメントであり、データベースからの戻り情報ではないようです。
質問：
無効な SQL 挿入ステートメントから入力データが失われるという明らかな問題を超えて、SQL Server レベルでのデータ型の長さのオーバーフローを悪用して、データベースの読み取りまたは書き込みを行ったり、後続の処理を妨げるメモリ ホギング ループを作成したりできますか?リクエスト？
さまざまなプログラミング言語で、バッファ メモリ オーバーフローが悪用されてアプリケーション レベルでコードが実行される (「スタックを壊す」) 可能性があることを認識しており、SQL Server レベルでの実行が制御されてエラーが発生するだけなのか疑問に思っていました。 SQL Serverレベルでの検証から、または追加のコマンドなどを何らかの方法で含めることができれば、; DELETE FROM USERS;追加の懸念の原因になる可能性があります。
追加情報が必要な場合はお知らせください。これに関する広範なドキュメントがあると思いますが、かなりの検索を行った後、Google または他のスタックの回答から必要なものを見つけることができませんでした。おそらく、答えは単に「SQL Server 2012 には、これを防止するための適切な内部検証がある」ということです。私を正しい方向に向けてください。ありがとうございました！