Безопасность данных сайта и разграничение доступа

Как в базе проверить принадлежность юзера на роль

Используем функцию 

dbo.sec_hasAccessByUsersRoles(@username, '', [role]) = '1' 

Примечание: 

Если roles указано * - то доступ дается для всех, кто авторизован в системе

Если roles указано all - доступ дается всем пользователям (в том числе неавторизованным). 

В остальных случаях указывайте роли доступа через запятую. Пример: admin, manager - доступ имеют только пользователи, у которых есть роль manager или admin

Безопасность входных данных!

1. КРАЙНЕ ВАЖНО!!! Не доверяйте данным, которые приходят в sql  снаружи (например, переменные itemID в форме). Их можно подделать и отправить совершенно любые данные. Обязательно проверяйте доступ у пользователя по username и его ролям + специфичные ограничения в запросах: 

select * from pg_pages where forEditor='1' and id = @itemID 

Здесь мы находим по входящему itemID, но при этом обрезаем данные по дополнительному условию (только для редактора можно взять данные по страницам в данном случае). 

2. Используйте для компонентов начальные настройки безопасности по роли (поля users, roles у страниц, таблиц, форм и др. компонентов).

3. Чтобы избежать XSS атаки, используйте функцию dbo.as_antiXSS(str), чтобы избежать ввода злоумышленником скриптов через поля ввода.  

Пример использования:

select dbo.as_antiXSS('asd')

В этом случае входные данные будут обработаны и любой HTML будет декодирован. 

Подробнее про XSS

Примечание: по умолчанию защита от XSS включена во всех компонентах для неадминистративных ролей и неавторизованных пользователей.

Также в appsettings.json в параметре disableAntiXSSRoles вы можете установить какие роли могут беспрепятственно сохранять HTML в системе. По умолчанию это роли admin, siteManager, editor. Таким образом если обычный пользователь попробует записать скрипт. 

Разграничение доступа и проверка прав доступа на действия в системе

Для элементов (таблицы, формы, метрики и др) указываются user, roles поля, на основании которых делается первичная базовая проверка доступа к объекту. 

Более детальная проверка должна выполняться в хранимой процедуре на основе входящего параметра @username

Вспомогательные SQL функции для проверки доступа 

• bit sec_isUserInRole(username, role) - входит ли пользователь в данную роль? 
• bit sec_hasRight(username, right) - есть ли у пользователя данное право? (права задаются по ролям в панели управления)
• table sec_getUserRoles(username) - возвращает роли пользователя
• bit sec_hasAccessByUsersRoles(username, users, roles) - проверка на соответствие пользователя спискам users, roles
• также для отдельных сущностей в системе должны быть созданы дополнительные функции проверки прав вида sec_[entity]_hasRight(right, username, itemID). То есть в ней должна быть выполнена проверка права с кодом right у данного пользователя username к данной сущности с itemID. 

Примечание

• При кастомной дополнительной разработке в плане функций доступа используйте подсистему Security (SecurityManager) со следующими функциями: IsUserInRole, GetUserRoles, HasRight, HasEntityRight.
• В большинстве случаев необходимо указывать у компонентов roles для определения каким ролям доступен компонент. Если необходимо сделать доступным компонент или страницу для всех ролей и для неавторизованных пользователей, то используйте all.