Обмен рисками безопасности cookie ASP.NET_SessionId и .ASPXAUTH

Question

Мы разрабатываем решение SAAS для крупной компании, в которой врачи могут просматривать пациентов и делать мутации, заказывать продукты, предоставлять лицензии. Этот проект предназначен для 4 отдельных компаний под одной зонтичной компанией. Для каждой компании мы разработали портал. Все порталы используют один и тот же код, но имеют строгую разделенную базу данных, поскольку база данных содержит всю информацию о пациенте. Мы используем Sitecore в качестве CMS.

Клиент решил использовать виртуальные папки вместо поддоменов для производственной среды. Например, наш URL-адрес для развертывания: acc-portal1.umbrella.com. Для производственной среды им нужен URL-адрес, например: acc.umbrella.com/portal1. Один сертификат SSL используется для всех порталов и запросов.

Для аутентификации пользователей используется поставщик членства (проверка подлинности форм). Пользователи не могут входить в систему с той же учетной записью, например, в Portal1 и Portal3 из-за использования разделенных баз данных. Поскольку мы используем проверку форм, используется cookie «.ASPXAUTH». Конечно, также используется cookie «ASP.NET_SessionId».

Поскольку клиент хочет использовать виртуальные папки вместо поддоменов, куки-файлы разделяются на всех порталах. Можно установить «путь» на узле в web.config, но этот путь динамически читается Sitecore и разрешен в конвейере. Я не нашел способ переопределить этот путь после его загрузки в web.config. Также я не нашел способ изменить путь к файлу cookie ASP.NET_SessionId.

Мой вопрос: является ли (безопасностью) риск поделиться этими кукисами на нескольких порталах (помните, что они должны быть полностью разделены)? Есть ли другие проблемы, которые может вызвать эта установка?

Надеюсь, кто-то может помочь!

Answer 1

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

Мой совет должен состоять в том, чтобы сохранить имя арендатора (portal1) в разделе пользовательских данных cookie для проверки подлинности форм. Вы устанавливаете пользовательские данные при выпуске cookie форм.

Затем создайте пользовательский модуль или просто обработчик события Application_AuthorizeRequest, где идентификатор уже установлен на основе файла cookie.

В вашем обработчике вы расшифровываете билет проверки подлинности форм из файла cookie, извлекаете данные пользователя и сравниваете с фактическим URL. Если есть совпадение - ничего не происходит. Если нет совпадения, это означает, что пользователь аутентифицирован на одном портале, но пытается получить доступ к другому. Вы можете мягко очистить ответ и сделать сообщение «ну, этот портал не предназначен для вас» или просто зарегистрировать пользователя.