Предчувствие безопасности Hibernate: Hibernate против хранимых процедур

Question

В компании, с которой я работаю, нам часто приходится интегрироваться с инфраструктурой клиента. Недавно, услышав, что мы используем Hibernate, у одного клиента возникло следующее беспокойство: так как пользователь, под которым Hibernate подключается к базе данных, имеет прямой доступ к таблицам, а Hibernate генерирует SQL динамически, то такой пользователь может делать что угодно в базе данных.

Если бы у пользователя было только разрешение на выполнение хранимых процедур, то SP могли бы ограничивать данные, но, что более важно, типы запросов, которые он может выдавать в базу данных: в основном, нет динамического и внедренного SQL. Таким образом, если существует хранимая процедура, которая удаляет строку, злоумышленник, получивший учетные данные пользователя, сможет удалить одну строку за один раз, но не сможет выдать DELETE *. Я знаю, что Hibernate также может отображать представления, но опять-таки это ограничивает данные, а не операции, которые может выполнять пользователь. Hibernate также может выполнять SP, но это в значительной степени превосходит цель использования Hibernate и подразумевает полное переписывание приложения.

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

Answer 1

1. NHibernate может отображаться в sprocs вместо таблиц
2. Вы можете отобразить операции чтения в таблицы / представления и операции вставки / обновления / удаления в sprocs, если хотите
3. NHibernate генерирует параметризованный SQL, т. Е. Нет шансов внедрения SQL
4. Полномочия пользователя всегда могут быть ограничены определенными операциями над определенными таблицами, если вы решите отобразить таблицы и / или представления
5. Большинство проектов, использующих sprocs, начинаются с создания процедур CRUD для каждой таблицы и назначения разрешений на выполнение для всех них - это не намного безопаснее, чем разрешение доступа к таблице

Answer 2

Я бы предположил, что Hibernate использует параматеризованные запросы. Это должно облегчить большую часть заботы о внедрении SQL. Вы также можете запретить учетной записи пользователя делать все в базе данных. В конце концов, это не обязательно должен быть аккаунт SA.

Answer 3

Hibernate может быть менее безопасным, чем использование хранимых процедур, поскольку теоретически администраторы БД могут ограничивать доступ пользователя только к вызову хранимых процедур, а не прямой доступ к базовым структурам данных.

На практике и по моему опыту крайне редко этот стиль безопасности реализуется осмысленно. Если хранимая процедура написана для каждой операции CRUD, и пользователю предоставляется доступ ко всем хранимым процедурам, между ними нет реальной разницы и просто предоставление прав самим базовым структурам.

Если компания проверяется на соответствие требованиям SOX или безопасности, они могут потерять доступ к хранимым процедурам.

Можно использовать Hibernate над хранимыми процедурами, но это похоже на боль в заднице .

Answer 4

Hibernate, конечно, просто слой ORM над SQL.

Добавьте свойство show_sql = true, покажите им, что генерируется sql, и они точно увидят, что он делает (параметризованные запросы, как упоминалось).

Answer 5

Если я не ошибаюсь, NHibernate использует параметризованные sql запросы. Это остановит инъекцию.