Каковы наилучшие практики для обеспечения безопасности при использовании NHibernate?

Question

Традиционалисты утверждают, что хранимые процедуры обеспечивают лучшую безопасность, чем если бы вы использовали каркас объектно-реляционного сопоставления (ORM), такой как NHibernate.

Чтобы противостоять этому аргументу, какие существуют подходы, которые можно использовать с NHibernate для обеспечения надлежащей защиты (например, предотвращения внедрения SQL и т. Д.)?

( Пожалуйста, предоставьте только один подход к ответу )

Answer 1

Защитите свои строки подключения.

Начиная с .NET 2.0 и NHibernate 1.2, в ваших конфигурационных файлах легко использовать зашифрованные строки подключения (и другие настройки приложения). Сохраните строку подключения в блоке <connectionStrings>, затем используйте свойство NHibernate connection.connection_string_name вместо connection.connection_string. Если вы работаете с веб-сайтом, а не с приложением Windows, вы можете использовать инструмент командной строки aspnet_regiis для шифрования блока <connectionStrings>, оставляя остальные настройки NHibernate в виде текста для простого редактирования.

Другая стратегия заключается в использовании встроенной аутентификации для подключения к базе данных, если ваша платформа базы данных поддерживает это. Таким образом, вы (надеюсь) не сохраняете учетные данные в виде открытого текста в вашем конфигурационном файле.

Answer 2

На самом деле, NHibernate может быть уязвим для внедрения SQL, если вы используете SQL или HQL для построения своих запросов. Убедитесь, что вы используете параметризованные запросы, если вам нужно это сделать, в противном случае вы настраиваете себя на боль.

Answer 3

Использовать выделенную заблокированную учетную запись SQL

Answer 4

Один из аргументов, которые я слышал в пользу sprocs по сравнению с ORM, заключается в том, что они не хотят, чтобы люди делали , что они хотят в базе данных. Они запрещают выбирать / вставлять / обновлять / удалять сами таблицы. Каждое действие контролируется с помощью процедуры, которая рассматривается администратором базы данных. Я могу понять, откуда взялась эта мысль ... особенно, когда у вас есть кучка любителей, все в своих руках в вашей базе данных.

Но времена изменились, а NHibernate изменился. Это невероятно зрелый. В большинстве случаев он будет писать лучше SQL, чем ваш DBA:).

Вы все еще должны защищать себя от глупостей. Как говорит человек-паук, «с большой силой приходит большая ответственность»

Я думаю, что гораздо более уместно предоставить NHibernate надлежащий доступ к базе данных и контролировать действия с помощью других средств, таких как ведение журнала аудита и регулярное резервное копирование. Если кто-то делает глупость, вы всегда можете прийти в себя.

Answer 5

Большинство ORM обрабатывают внедрение SQL, создавая параметризованные запросы. В NHibernate, если вы используете LINQ to NHibernate или Criteria / Query over методы написания запросов, запросы автоматически параметризуются, если вы сами динамически создаете HQL / SQL-запросы, вы более уязвимы и должны помнить, что ваш запросы должны быть параметризованы.

Answer 6

http://weblogs.asp.net/fbouma/archive/2003/11/18/38178.aspx

Answer 7

В OWASP упоминается одна из форм уязвимости внедрения SQL в контексте инструментов ORM (и в качестве примера приводится внедрение HQL): http://www.owasp.org/index.php/Interpreter_Injection#ORM_Injection