Проверка доступа пользователей на предмет прав на определенные объекты или записи базы данных
Я веду дружеские дискуссии с разработчиком о ситуации, когда пользователи входят в систему и получают доступ к документам в веб-приложении. Когда мы загружаем документ для просмотра пользователем, у нас есть идентификатор пользователя в сеансе и идентификатор документа, который может быть передан через QueryString.
Чтобы запретить пользователю изменять идентификатор документа в QueryString, я предлагаю, чтобы хранимая процедура, загружающая документ, принимала UserId в качестве параметра для проверки прав на документ.
Мой друг-разработчик предлагает запустить отдельную процедуру для определения прав доступа к документу ранее на странице и просто запустить процедуру для получения документа, когда документ должен быть показан.
Мы что-то упускаем? Что наиболее эффективно и безопасно? Я думал, что передача UserId с DocID в один вызов процедуры для проверки прав и извлечения документа была более эффективным решением.
Ответы 3
UserID должен быть переменной сеанса. Верно. Передайте идентификатор документа в строке запроса. Ага.
Предполагая, что документы хранятся в базе данных, у меня была бы таблица для разрешений: идентификатор записи, идентификатор пользователя и идентификатор документа. Вы выполняете соединение с этой таблицей при вызове документа. Если вы не получите результата, вы не получите документ. Хорошо проиндексируйте все это, и это будет быстро.
I propose that the stored procedure that loads the document take the UserId as a parameter to validate rights to the document.
Я думаю, это правильный путь. Хотя бы по той причине, что так безопаснее. Если вы повторно воспользуетесь этой процедурой, а потом забудете проверить доступ - вы открыли большую дыру. Таким образом становится очевидным и очевидным, что вы не можете получить доступ к документу, если у вас нет доступа.
Строго с точки зрения производительности лучше всего передать UserID вместе с DocumentID в одну хранимую процедуру. У вас есть только один круговой обход сервера базы данных. Кроме того, как указывали другие, если вы будете извлекать этот документ с других страниц или приложений, если вы используете ту же хранимую процедуру, вы гарантируете, что не обойдете безопасность, чтобы сделать это.
Однако есть сценарии, в которых имеет смысл иметь выделенные хранимые процедуры проверки безопасности. Если у вас есть другие ресурсы, которые вы хотите защитить помимо документов, и ваш код проверки нетривиален, вы можете не захотеть дублировать код проверки в каждой хранимой процедуре в своей базе данных. В этом случае может иметь смысл переместить инфраструктуру безопасности на уровень доступа к данным и заставить уровень доступа к данным выполнять вызов db для авторизации доступа перед извлечением запрошенного ресурса. Если вы выберете этот путь, вы не хотите полагаться на разработчика, который всегда должен помнить о необходимости выполнения авторизационного вызова базы данных перед запросом ресурса.