asp.net использует requireSSL и все еще сможет проверить, прошел ли пользователь аутентификацию на страницах без SSL - PullRequest
2 голосов
/ 28 декабря 2010

У меня есть веб-приложение (asp.net 3.5) со смешанным SSL.Все связанные с аккаунтом страницы доставляются по SSL.В основном все остальные страницы доставляются через не-ssl.Для автоматического переключения между HTTPS и HTTP я использую этот компонент .В последнее время появилась новость, касающаяся возможности захвата пользовательских сеансов в незащищенных сетях Wi-Fi.Это должно быть возможно путем перехвата Cookie, который передается по соединениям не-ssl.

Это заставило меня пересмотреть мой выбор безопасности в этом веб-приложении.Я (снова) взял эту статью из MSDN и попробовал свойство requireSSL = true в моей проверке подлинности с помощью форм.Еще до того, как я запустил веб-приложение, я понял, что мой User.Identity будет нулевым на страницах, отличных от SSL, потому что cookie-файл, содержащий эту информацию, не отправляется от и в веб-браузер.

Мне нужен механизм, которыйАутентифицирует пользователя через соединение SSL ... и запоминает эту информацию для аутентификации, даже на страницах, отличных от SSL.

При поиске SO я обнаружил это сообщение .Мне кажется, что это хорошее решение.Но мне интересно, можно ли найти решение для хранения информации для входа в Sessionstate?Я подумываю о перехвате Application_AuthenticateRequest в Global.asax.Проверьте, безопасно ли соединение, и проверьте authcookie или Session.Я не знаю точно, как я собираюсь реализовать это еще.Может быть, вы можете подумать со мной об этом?

Ответы [ 2 ]

3 голосов
/ 13 апреля 2011

К сожалению, у вас есть противоречивые требования.У вас не может быть безопасного сеанса через не-SSL, поэтому я бы хотел оспорить ваше базовое предположение: почему бы не использовать весь сайт SSL?

2 голосов
/ 29 июля 2011

Из часто задаваемых вопросов MVC (на аналогичный вопрос ответил гуру безопасности Леви) с просьбой указать атрибут, не использующий SSL.

• Атрибут [RequireHttps] можно использовать в типе контроллера или методе действия, чтобы сказать «к нему можно получить доступ только через SSL». Не-SSL запросы к контроллеру или действию будут перенаправлены на версию SSL (если HTTP GET) или отклонены (если HTTP POST). Вы можете переопределить RequireHttpsAttribute и изменить это поведение, если хотите. Нет встроенного атрибута [RequireHttp], который делает обратное, но вы можете легко создать свой собственный, если хотите.

Существуют также перегрузки Html.ActionLink (), которые принимают параметр протокола; вы можете явно указать "http" или "https" в качестве протокола. Вот документация MSDN об одной такой перегрузке. Если вы не указываете протокол или вызываете перегрузку, у которой нет параметра протокола, предполагается, что вы хотите, чтобы канал имел тот же протокол, что и текущий запрос.

Причина, по которой у нас нет атрибута [RequireHttp] в MVC, заключается в том, что в этом нет особой выгоды. Это не так интересно, как [RequireHttps], и это побуждает пользователей поступать неправильно. Например, многие веб-сайты входят в систему через SSL и перенаправляют обратно на HTTP после того, как вы вошли в систему, что абсолютно неправильно. Ваш файл cookie для входа в систему так же секретен, как и ваше имя пользователя + пароль, и теперь вы отправляете его в открытом виде по сети. Кроме того, вы уже нашли время, чтобы выполнить квитирование и защитить канал (что является основной причиной того, что HTTPS медленнее, чем HTTP) перед запуском конвейера MVC, поэтому [RequireHttp] не будет выполнять текущий запрос или будущее запросы гораздо быстрее.

...