セキュリティの観点から、ASP.NET Webサイトのデータベースサーバーユーザーをストアドプロシージャでの実行のみに制限する価値はありますか？
ユーザー入力の検証とパラメーター化されたクエリを通じてSQLインジェクション攻撃を回避する必要があることは明らかです。データベースサーバーには既にファイアウォールがあり、リモート接続がWebサーバーからのみ受け入れられるように制限しています。
また、ASP.NET Webサイトが使用する実際のデータベースユーザーアカウントを、必要なストアドプロシージャのみのEXECUTE権限に制限するために、セキュリティの観点からも価値がありますか？すべてのデータベース対話は、これらのストアドプロシージャを使用して行われます。
これは、攻撃者がデータベース接続にアクセスする方法を見つけた場合でも、攻撃は事前定義されたクエリの実行のみに限定され、オープンエンドのクエリは実行されないように思われます。
これを行う主な（セキュリティ）理由は2つあります。パラメータ化されたクエリを使用することの他に、
- パラメータタイプの適用
- 最小限の特権。
最小特権の原則では、定義されたタスクを実行するために必要なすべてのエンティティ（ユーザーまたはアプリケーション）へのアクセスonlyを許可する必要があります。 WebアプリケーションをSPのみに制限しない場合、アプリケーションは任意のクエリを実行する可能性があります。
これは2つの状況に関連することに注意してください。アプリケーションの脆弱性（SQLインジェクション、またはコードの実行を可能にするその他の脆弱性）を見つけた攻撃者が、悪意のあるSQLクエリを実行するのを防ぎます。 ;安全性が低く、承認されていないショートカットを探している開発者（または悪意のある開発者）のリスクははるかに低いです。
許可only必要なSPに対するEXECUTE権限を付与すると、アプリケーションは事前定義されていないクエリを実行できなくなります。
パラメータタイプを強制する場合、これを他の方法で実装することは可能ですが、これはデータベースにタイプの強制をもたらしますが、データベースサーバーに到達する前です。つまりデータベースで定義された実際にであるタイプを使用し、誤ってパラメーターをスキップしません。
これを適切に行い、いくつかの一般的な間違いを回避するには、次のことを実行する必要があることに注意してください。
- aSP.NETアプリケーションの特定のユーザーアカウントを定義する
- アカウントをcustom DBロールに割り当てます
dboなどの他のすべてのロールからアカウントを削除します。- 作成したカスタムDBロールにEXECUTE権限を付与します
- sP、テーブル、およびその他のDBオブジェクトに対する他のすべての権限を削除します。これには、デフォルトの「パブリック」ロールなどが含まれます。
- カスタムDBロールに他の権限がないことを確認してください。
もちろんです。
ただし、ストアドプロシージャに注意する必要があります。任意のクエリを渡すことができる場合は、同じ位置にとどまります。
ここには厄介な欠点があります。以前はこの種のルールがありましたが、すべてのデータベース要求がストアドプロシージャにうまく収まるわけではありません。そのため、多くの開発者がストアドプロシージャ内でSQLを手動で作成し、そこで実行していました。これにより、醜いコードが多くなり、sp_executsqlは、少なくともその時点では、ストアドプロシージャ内にあるとsaレベルの権限で実行され、SQLプロシージャ内の入力をサニタイズすることは、最新のアプリケーション言語で入力をサニタイズするよりもはるかに醜いです。
これが明らかになった後、テーブルのCRUD操作を許可し、アプリケーションレイヤーでパラメーター化を適用することから始めました。
最小特権の原則がここで思い浮かびますが、今は少し逸話になっています。 PostgreSQLでは（はい、これはSQL Serverの質問ですが、注意が必要な場合があります）非特権ユーザーが悪意のある可能性があるオーバーロードする関数（同じ関数名+パラメーター）を作成する可能性がありますクエリ。特権ユーザーがこのクエリを実行すると、実際には悪意のある機能を使用しているにもかかわらず、デフォルトの追加機能を実行していると思われる場合があります。開発者として、あなたはメンテナンスの悪夢を生み出していることを知っています。なぜなら、書く必要のある「一回限り」のクエリが常にあるからです。ですから、ここに質問があります。それが事前定義されたクエリである場合に新しいユーザーアカウントを作成するときは、追加の保護を提供していません。新しいユーザーのログファイルを常に監視しない限り、攻撃者がシステムを無期限に監視できるようになったため、実際には事態が悪化したと主張することもできます。また、データが変化するため、UPDATEステートメントは、誰かがjavascriptを直接返されるレコードに挿入できるようになるため、新しい最悪の敵になります。私が経験から言っているように、データベースのデータはすでに確保されています。