伝統主義者は、ストアドプロシージャは、NHibernateなどのオブジェクトリレーショナルマッピング(ORM)フレームワークを使用する場合よりも優れたセキュリティを提供すると主張しています。
その議論に対抗するために、適切なセキュリティが実施されていることを確認するためにNHibernateで使用できるいくつかのアプローチは何ですか(たとえば、SQLインジェクションの防止など)?
(回答ごとに1つのアプローチのみを提供してください)
伝統主義者は、ストアドプロシージャは、NHibernateなどのオブジェクトリレーショナルマッピング(ORM)フレームワークを使用する場合よりも優れたセキュリティを提供すると主張しています。
その議論に対抗するために、適切なセキュリティが実施されていることを確認するためにNHibernateで使用できるいくつかのアプローチは何ですか(たとえば、SQLインジェクションの防止など)?
(回答ごとに1つのアプローチのみを提供してください)
接続文字列を保護します。
.NET 2.0 および NHibernate 1.2 では、構成ファイルで暗号化された接続文字列 (およびその他のアプリケーション設定) を簡単に使用できます。接続文字列をブロックに格納してから、 の代わりに<connectionStrings>
NHibernateconnection.connection_string_name
プロパティを使用しconnection.connection_string
ます。Windows アプリではなく Web サイトを実行している場合は、aspnet_regiis
コマンド ライン ツールを使用してブロックを暗号化し<connectionStrings>
、残りの NHibernate 設定を編集しやすいようにプレーンテキストのままにしておくことができます。
もう 1 つの戦略は、データベース プラットフォームがサポートしている場合、データベース接続に統合認証を使用することです。そうすれば、(うまくいけば)構成ファイルに資格情報をプレーンテキストで保存しなくなります。
実際、SQL または HQL を使用してクエリを作成する場合、NHibernate は SQL インジェクションに対して脆弱になる可能性があります。これを行う必要がある場合は、必ずパラメーター化されたクエリを使用してください。そうしないと、苦痛の世界に身を置くことになります。
ロックダウンされた専用の SQL アカウントを使用する
ORM よりも sprocs を支持する意見の 1 つは、データベース内でユーザーがやりたいことを実行することを望んでいないというものです。テーブル自体の選択/挿入/更新/削除を禁止します。すべてのアクションは、DBA によってレビューされる手順によって制御されます。この考え方がどこから来るのかは理解できます...特に、データベース に手を入れているアマチュアがたくさんいる場合はなおさらです。
しかし、時代は変わり、NHibernate は異なります。それは信じられないほど成熟しています。ほとんどの場合、DBA よりも優れた SQL を記述できます :)。
あなたはまだ愚かなことから身を守る必要があります。スパイダーマンが言うように「大いなる力には大いなる責任が伴う」
NHibernate にデータベースへの適切なアクセス権を与え、監査ログや定期的なバックアップなどの他の手段でアクションを制御する方がはるかに適切だと思います。誰かが愚かなことをしたとしても、あなたはいつでも立ち直ることができます。
ほとんどの ORM は、パラメーター化されたクエリを作成することで SQL インジェクションを処理します。NHibernate では、LINQ to NHibernate またはクエリの記述方法で Criteria/Query を使用している場合、クエリは自動的にパラメーター化されます。自分で HQL/SQL クエリを動的に作成している場合は、より脆弱であり、クエリはパラメータ化する必要があります。
OWASP は、ORM ツールのコンテキストで SQL インジェクションの脆弱性の 1 つの形式について言及しています (また、例として HQL インジェクションを示しています): http://www.owasp.org/index.php/Interpreter_Injection#ORM_Injection