Роли пользователей - почему бы не сохранить сессию?

Я переношу приложение ASP.NET в MVC и должен хранить два элемента, относящихся к аутентифицированному пользователю: список ролей и список видимых идентификаторов элементов, чтобы определить, что пользователь может или не может видеть.

Мы использовали WSE с веб-службой в прошлом, и это сделало вещи невероятно сложными и невозможными для правильной отладки. Теперь мы бросаем веб-сервис, который я искал, чтобы резко упростить решение, просто чтобы сохранить эти вещи в сеансе. Коллега предложил использовать роли и поставщиков членства, но, глядя на это, я обнаружил ряд проблем:

a) Он страдает от аналогичных, но разных проблем для WSE в том, что он должен использоваться очень ограниченным способом, но это сложно сделать даже для написания тестов;

b) Единственная опция кэширования для RolesProvider основана на файлах cookie, которые мы отклонили по соображениям безопасности;

c) Он не вводит никаких осложнений и дополнительного нежелательного багажа;

Все, что мы хотим сделать, в двух словах, это хранить две строковые переменные в сеансе пользователя или что-то эквивалентное безопасным образом и ссылаться на них, когда нам нужно. То, что, похоже, составляет десять минут, до сих пор занималось несколькими днями расследования и усугубляло проблему, которую мы теперь обнаружили, что идентификаторы сеансов могут, по-видимому, подделываться, см.

http://blogs.sans.org/appsecstreetfighter/2009/06/14/session-attacks-and-aspnet-part-1/

Мне осталось думать, что нет простого способа сделать эту очень простую работу, но я считаю, что невозможно поверить.

Может ли кто-нибудь:

a) предоставить простую информацию о том, как сделать сеансы ASP.NET MVC безопасными, поскольку я всегда считал, что они были?

b) предложить другой простой способ сохранить эти две строковые переменные для зарегистрированных в ролях пользователя и т.д., не заменяя один сложный кошмар другим, как описано выше?

Спасибо.

Ответы

Ответ 1

Сохранение информации о роли пользователя в сеансе на стороне сервера является безопасным, если сеанс не может быть захвачен. Повторяя это более широко, не имеет значения, где информация о роли пользователя сохраняется, если аутентифицированный сеанс захвачен.

Я советую не вкладывать слишком много веры в статью, к которой вы привязались, но интересный отчет о урожайности 2002 года, связанный с вашей ссылкой. Вот мои путевки:

  • Не принимайте идентификаторы сеансов, встроенные в URL-адреса.

  • Сфокусируйте свое время на устранении угроз сценариев межсайтового сценария, то есть сканируйте все предоставленные пользователем данные и проанализируйте исполняемый файл java script.

  • Выдавать файлы cookie для полных доменов (например, myapp.mydomain.com)

  • Размещение вашего домена у оператора DNS высокого класса, например. тот, который разрешает только изменения DNS с предустановленного удаленного IP-адреса.

  • Не выставляйте файлы cookie с постоянным сеансом.

  • Переиздайте файл cookie сеанса, если кто-то прибыл на страницу входа с идентификатором сеанса, уже связанным с аутентифицированным сеансом.

  • Лучше все равно всегда выдавать новый cookie сеанса при успешной аутентификации и отказываться от предыдущего сеанса. (Может ли это быть настроено в IIS?)

Ответ 2

Единственный способ сделать безопасную cinnection - использовать SSL. Все, что меньше, и вам просто нужно сделать оценку, когда она "достаточно безопасна".

Переменная сеанса отлично работает для хранения значения, за исключением того, что веб-сервер может быть повторно использован и затем, что приведет к потере сеанса. Когда это произойдет, вам придется повторно аутентифицировать пользователя и снова установить переменную сеанса.

Сама переменная сеанса полностью безопасна в том смысле, что она никогда не покидает сервер, если вы специально не копируете его в ответ.

Ответ 3

Рассматривали ли вы настройку настраиваемого тега авторизации в MVC. Я привел пример этого в другом question.

При первоначальной авторизации (экран входа в систему или начало сеанса) вы также можете ввести значение сеанса с IP-адресом. Затем в вашей пользовательской авторизации вы также можете проверить, что IP-адрес еще совпадает. Это поможет убедиться, что кто-то не "крадет" сеанс человека. Каждый раз, когда вы получаете доступ к данным сеанса, обязательно проверяйте IP-адрес реквестера и проверяйте его.

Ответ 4

Вы пытаетесь контролировать доступ к функциям на уровне клиента? Это единственная причина, по которой я буду раскрывать роли и элементы для управления функциями на стороне клиента.

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

4Guys, похоже, показывает, как управлять функциями с ролями.

Ответ 5

Подходом, который я использовал в прошлом, является использование симметричного шифрования файла cookie наряду с SSL. Шифруйте информацию пользователя в ответе и расшифруйте его в запросе. Я не утверждаю, что это безопасно или на 100% безопасно, и я бы не хотел делать это в банковском приложении, но он достаточно хорош для многих целей.

Основная проблема с переменными сеанса заключается в том, что если вы храните их inProc, а не сохраняете их, тогда вам нужно применить "липкие" сеансы к балансировке нагрузки в среде веб-фермы. Guffa правильно, что без этой постоянной сессии переменные сессии будут иногда потеряны, что приведет к плохому опыту пользователя.

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

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

Ответ 6

Мой очевидный вопрос: почему вы хотите сохранить роль пользователя в сеансе?

Вот мой ответ на ваш вопрос, как это помогает. Я приложил небольшое демо-приложение, чтобы вы могли взглянуть на мои вопросы и понять их. Когда вы открываете этот проект в визуальной студии, нажмите на вкладку проекта сверху и выберите конфигурацию asp.net. На странице, которая будет отображаться, вы можете создавать материалы для администрирования пользователей.

Вам нужно каким-то образом защитить роли пользователя? Ответ на этот вопрос заключается в том, что вам не нужно беспокоиться о сохранении роли для любого пользователя, когда у нас есть структура членства asp.net, профили и роли, чтобы помочь нам в этом. Все, что вам нужно сделать, это создать роль в базе данных aspnet и назначить эту роль пользователю.

Далее вы хотите сохранить две строки некорректно. Я предлагаю вам профиль пользователя для хранения пользовательской информации. Таким образом, у вас есть информация, доступная вам, когда вы захотите, из класса profilecommon.

Также см. прилагаемое демо-приложение, помещенное в конце моего блога http://blogs.bootcampedu.com/blog/post/Reply-to-httpstackoverflowcomquestions1672007user-roles-why-not-store-in-session.aspx

Ответ 7

Просто подскажите, вы можете использовать эту небольшую библиотеку:

http://www.codeproject.com/KB/aspnet/Univar.aspx

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