Защищенный режим IE + вход по SSL = нет cookie для страниц, не использующих SSL - PullRequest
Новая
       15

Защищенный режим IE + вход по SSL = нет cookie для страниц, не использующих SSL

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

(FWIW, я также разместил этот вопрос в своем блоге: http://blog.wolffmyren.com/2011/07/11/ie-protected-mode-ssl/)

Кто-нибудь знает, как обойти ограничения Internet Explorer в защищенном режиме, не требуя от конечного пользователя добавления нашего сайта всписок доверенных сайтов?

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

Это MSDNВ статье (Что ielowutil.exe имеет отношение к Internet Explorer 8.0?) содержится наиболее актуальная информация, которую я нашел, но в ней обсуждается использование API-интерфейсов Windows, и я ищу решение, которое можно реализовать с помощью ASP.NET,JavaScript или другое хорошо поставленное решение.

Обновление: Мой друг поделился этими ссылками, надеюсь, они помогут:

Ответы [ 2 ]

1 голос
/ 12 июля 2011

Как указывает Бруно, вы должны проверить, установлен ли атрибут SECURE в ваших файлах cookie (используйте инструменты разработчика F12 или Fiddler).Если да, то вы увидите это поведение во ВСЕХ браузерах.

Если нет, то проблема, скорее всего, в том, что вы находитесь в доверенной зоне, а http://whatever.com также нет в доверенной.Зона.Если это ваша конфигурация, то да, именно защищенный режим является основной причиной проблемы, которую я объяснил более подробно здесь:

http://blogs.msdn.com/b/ieinternals/archive/2011/03/10/internet-explorer-beware-cookie-sharing-in-cross-zone-scenarios.aspx

1 голос
/ 12 июля 2011

Похоже, что IIS предоставляет вам безопасные куки-файлы через ваше HTTPS-соединение, что действительно очень разумно.Эти файлы cookie не предназначены для утечки в обычное HTTP-соединение, поэтому вы получаете результат.

Вы можете создать дополнительный незащищенный файл cookie для передачи некоторой информации для аутентификации на сторону HTTP вашего сайта.Однако, как только вы это сделаете, не думайте, что все, что было сделано или отправлено во время обычного HTTP-сеанса, было сделано законным аутентифицированным пользователем, если в какой-то момент вам нужно вернуться к HTTPS.Можно передать токен аутентификации из HTTPS в HTTP, но это не так.(Конечно, вы все равно были бы уязвимы для атак в обычном HTTP, но это может быть приемлемым риском для вашего приложения.)

В этом вопросе есть еще об этой проблеме (что относится к Tomcat, будет то жес любым веб-сервером, включая IIS): Управление сеансами Tomcat - перезапись URL-адреса и переключение с http на https

...