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

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

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

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 для определения каким ролям доступен компонент. Если необходимо сделать доступным компонент или страницу для всех ролей и для неавторизованных пользователей, то используйте символ *.
Falcon Space - функциальная веб-платформа разработки на узком стеке MS SQL/Bootstrap. Вводная по Falcon Space
Насколько полезной была статья?

Google поиск по нашей документации

Falcon Space

Это снижение стоимости владения

за счет меньшего количества людей для поддержки и узкого стека разработки. Про снижение стоимости владения продуктом

Это быстрое внесение изменений

по ходу эксплуатации программы. Как создается функционал на платформе

Это простой удобный интерфейс

адаптация под мобильные устройства. Про юзабилити платформы