Различия в зрелости сеанса ASP

Question

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

Я понимаю, что сеанс хранится на стороне сервера и не доступен непосредственно клиенту при нормальных обстоятельствах. Другие механизмы персистентности ASP.net могут быть теоретически проиграны, by modifying viewstate or cookie values на стороне клиента, но эти недостатки реализации криптографии не должны выставлять состояние сеанса.

Какую степень контроля над вашим сервером злоумышленник должен будет изменять данные в состоянии сеанса клиентов? Предположим, у них есть sessionID и cookie ASPAUTH.

Например:

• А удаленная атака, как модифицированный POST или другой вызов обработчика на страницы?

• Может ли злоумышленник с программным доступом к IIS (WMI mabey?) иметь доступ и изменять состояние сеанса в той же или другой памяти пула приложений?

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

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

Answer 1

Поскольку мы точно не знаем, как реализован ваш код, все, что мы можем сделать, это догадываться.

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

1. Сессионные файлы cookie по умолчанию не шифруются и передаются как обычный текст.
2. Атаки с фиксацией сеанса легко выполнить
3. Если файл cookie сеанса захвачен или даже угадал, то не имеет значения, что такое учетная запись пользователя, они получат любые права безопасности, которые вы назначаете через этот файл cookie.
4. Сессия нестабильна, и IIS может убивать сеансы всякий раз, когда это кажется, поэтому вы попадаете в ситуацию, когда пользователь все еще регистрируется, но их сеанс теряется из-за многих возможных причин. Так что теперь их безопасность также нестабильна.

Есть много других, более подходящих способов сделать то, что вы хотите, Сеанс НИКОГДА не подходящий метод.

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

• Используя поле данных пользователя билета FormsAuthentication для хранения информации
• Использование пользовательского иска в претензии аутентификации на основе, как ASP.NET Identity, WIF или IdentityServer.
• Использование кэша asp.net для хранения временной информации на основе идентификации (не сеанса) и добавления тайм-аута выключения кэша.
• и многое другое ...

Answer 2

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

Несколько ссылок вы должны принимать во внимание ...

Защита состояния сеанса http://msdn.microsoft.com/en-us/library/ms178201%28v=vs.140%29.aspx

http://www.dotnetnoob.com/2013/07/ramping-up-aspnet-session-security.html

http://www.codeproject.com/Articles/210993/Session-Fixation-vulnerability-in-ASP-NET

http://www.dotnetfunda.com/articles/show/730/session-security-in-aspnet

Я согласен с видом Erik.

Отношения