Блог

Главная - Вопросы по программированию - ASP.NET / SQL Server: хранение сложных запросов в базе данных SQL Server

ASP.NET / SQL Server: хранение сложных запросов в базе данных SQL Server

#sql-server

#sql-сервер

Вопрос:

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

Кажется, имеет смысл хранить их в базе данных приложения, где я могу связать их с именами групп, и их легко добавлять / удалять в будущем.

Запросы довольно сложные, хотя и принимают ряд параметров, таких как jQuery в поля даты и из них, текущее имя пользователя и т.д. Таким образом, запрос сконструирован следующим образом:

 MyQuery = "SELECT * FROM Table1 WHERE Username = '"   System...CurrentUser  "' AND Somedate > '"   from.text  '";

Теперь я не уверен, как использовать этот код и создать эквивалентное представление в базе данных. Я думал об использовании определенных идентификаторов, таких как %USERNAME%, %FROMDATE% и т.д. Затем использовать функцию замены строки, но я не уверен, что это перенесет одинарные кавычки.

Будет ли работать что-то вроде Replace("%USERNAME%", "'" CurrentUser "'") ?

Есть идеи получше!

Две вещи:

  1. Ограничить некоторые запросы на основе групп пользователей.
  2. Достаточно легко добавлять / удалять / редактировать запросы в будущем (не жестко закодированные в C #?)

Комментарии:

1. Глупый вопрос: не могли бы вы просто создать их как хранимые процедуры (с параметрами) и обрабатывать разрешения, используя стандартные функции SQL Server??

2. marc_s — это должен быть ответ. Я хотел опубликовать это как ответ сам, но вы меня опередили. Я чувствовал бы себя ничтожеством, если бы опубликовал это в качестве ответа, когда вы уже разместили это в качестве комментария. Также я бы включил ссылку на статью OWASP о внедрении SQL. Опубликуйте это как ответ, и я проголосую за него.

3. databases.about.com/od/sqlserver/a/storedprocedure.htm и owasp.org/index.php/SQL_injection

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

5. Я знаю, что это прозвучит спорно, и я не хотел этого, но это ужасное предположение. Как только вы создаете хранимую процедуру, у вас нет контроля над тем, будет ли будущий разработчик использовать хранимую процедуру. Даже если вы знаете наверняка, все равно лучше иметь привычку всегда кодировать надежно, несмотря ни на что. Безопасное кодирование — это такая же привычка, как и навык, и мышление ДОЛЖНО быть параноидальным. Предположим, что произойдет худшее.

Ответ №1:

Прежде всего: БОЛЬШОЕ ПРЕДУПРЕЖДЕНИЕ: объединение ваших операторов SQL вместе несет в себе большую опасность атак с использованием SQL-инъекций. Вам следует избегать этого метода любой ценой и вместо этого использовать параметризованные запросы.

Во-вторых: не могли бы вы просто создать эти «сложные запросы» в виде хранимых процедур (с параметрами) — это то, в чем хранимые процедуры действительно хороши — инкапсулировать сложные запросы в простой вызов извне.

Затем вы могли бы обрабатывать разрешения, используя стандартные функции SQL Server — предоставить тем пользователям (и / или группам) разрешение на выполнение этой хранимой процедуры, которым разрешено ее вызывать.