Пользователь предоставил доступ к хранимой процедуре, но не может выполнить запрос - PullRequest
Новая
       27

Пользователь предоставил доступ к хранимой процедуре, но не может выполнить запрос

1 голос
/ 05 февраля 2009

Я работаю над продуктом, на котором работает SQL-сервер, который позволяет некоторым приложениям входить в систему, и их учетным записям предоставляется разрешение на запуск хранимой процедуры - И НИЧЕГО. Хранимая процедура принадлежит администратору; хранимая процедура принимает запрос и выполняет его, затем результаты возвращаются приложению.

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

Хранимая процедура выполняет переданный запрос, когда я вошел в систему как администратор, но когда я вошел в систему как пользователь с ограниченными правами, он вызывает исключение в операторе execute.

Например: 

EXEC [Admin].[STORED_PROC] @SQL_STATEMENT = 'SELECT * FROM table_x'

STORED_PROC выглядит примерно так: 

BEGIN TRY
   EXEC (@SQL_STATEMENT)
END TRY
BEGIN CATCH
   -- some logging when an exception is caught, and the exception is caught here!!!
END CATCH

В операторе try catch ничего нет, кроме EXEC ... и SQL_STATEMENT работает, когда я вошел в систему как администратор, но не когда я вошел в систему как пользователь.

Может ли кто-нибудь помочь мне выяснить, какие разрешения мне нужно установить, чтобы позволить пользователю выполнять запросы только через сохраненный процесс?

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

Так что да, в действительности необработанные операторы SQL не являются безопасными, и они наносят ущерб цели хранимых процедур, но я не знаю, как зашифровать запросы SQL, которые передаются через ODBC и работают с SQL Server до 2005 года.

В любом случае я пытался установить некоторые минимальные меры безопасности, чтобы хотя бы обеспечить базовую защиту.

Ответы [ 6 ]

6 голосов
/ 05 февраля 2009

Поскольку вы используете динамический sql, SQL-сервер не может определить, какие таблицы вы используете, поэтому вам необходимо предоставить права SELECT для всех таблиц

4 голосов
/ 05 февраля 2009

Разрешение необработанного SQL-кода передаваться в хранимую процедуру, а затем выполняться - это сама суть незащищенности данных.

Безопасность SQL Server структурирована таким образом, что произвольные биты SQL выполняются в своем собственном контексте безопасности. Если у вас нет разрешения на запуск запроса ad hoc, у вас также нет разрешения на его выполнение через хранимую процедуру. В этом SQL Server спасает вас от себя.

4 голосов
/ 05 февраля 2009

Пользователи также должны иметь грант SELECT для таблиц

0 голосов
/ 05 февраля 2009

Это наиболее вероятно из-за различных схем, то есть пользователь, который входит в систему, не является частью схемы администратора, или, по крайней мере, я надеюсь, что нет.

Техника безопасности, которая разрешает тип доступа, который вы хотите получить, то есть разрешить доступ к объектам, принадлежащим той же схеме, называется цепочкой владения.

Этот принцип лучше всего не объясняется в посте.

Вот ссылка от Microsoft, объясняющая эту концепцию.

http://msdn.microsoft.com/en-us/library/ms188676(SQL.90).aspx

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

http://www.sommarskog.se/grantperm.html

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

Ура, Джон

0 голосов
/ 05 февраля 2009

Когда динамический SQL используется через EXEC или sp_executesql в SP, разрешения EXEC на SP не позволяют запускать произвольный код в динамическом sql. Вам либо нужно предоставить SELECT (гадость), либо вы можете выдать себя за другого пользователя, используя EXECUTE AS или SETUSER.

При использовании обычного SQL разрешения EXEC работают нормально, переопределяя несанкционированные SELECT разрешения. Если у вас есть DENY, я считаю, что это превосходит его.

Сказав это, я все еще не уверен, что вы должны использовать EXECUTE AS, когда источником SQL является вне SP (или вне базы данных). Для генерации кода или динамического SQL, который безопасен от внешнего воздействия, EXECUTE AS может быть полезным инструментом

0 голосов
/ 05 февраля 2009

Поскольку ваша система разрешает доступ к хранимым процессам и ничему другому (что хорошо для целей безопасности и не должно изменяться), вы просто не сможете ни при каких обстоятельствах использовать динамический SQL, потому что права не на уровне таблицы, а ваши базы вряд ли это изменится. Это не только для предотвращения атак SQL-инъекций, но и для предотвращения возможного внутреннего мошенничества, поэтому любое рабочее место, которое сочло это важным, не захочет идти на компромисс, чтобы облегчить вам жизнь. Вам просто нужно изменить дизайн, чтобы никогда ничего не делать динамически. У вас нет другого выбора. Если вы пишете проки, чтобы они делали то, что вы хотите, во-первых, вам не нужно отправлять зашифрованный sql.

...