Подготовка моего сайта ASP.NET/MVC для использования SSL?

Я собираюсь установить SSL cert на моем хостинге.

Я понимаю, что (и исправьте меня, если я ошибаюсь...):

Должен ли я беспокоиться о том, чтобы делать что-то дополнительное с этими вещами, чтобы убедиться, что я правильно использую SSL? Я не уверен, что мне нужно что-то изменить с логикой, связанной с:

Кроме того, я планирую добавить [RequiresHttps] только на странице корзины покупок, проверки, входа, учетной записи и администрирования. Я хочу оставить страницы просмотра/покупки товаров на Http, так как я слышал, что для использования Https требуется больше накладных расходов. Является ли это нормальным/приемлемым/нормально?

Еще один вопрос... Я знаю, что ASP.NET хранит некоторые данные для входа в виде файла cookie Auth. Это нормально, что пользователь входит в систему на странице Https, но затем может вернуться и просмотреть страницу Http? Мне интересно, создает ли это нарушение безопасности, так как пользователь снова войдет в систему и просмотрит его в Http. Это разрушает точку использования SSL?

Я вроде как новичок в этом... так что помощь будет оценена.

Ответы

Ответ 1

Начиная с ваших вопросов, на одном, (1) да ничто не остановит вас на для использования на тех же страницах http ether https.

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

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

Cookies

Когда файл cookie связан с учетными данными пользователя, вам необходимо заставить его передавать только защищенную страницу. Это означает, что если вы установите cookie с https, этот файл cookie НЕ передается на небезопасной странице, так что оставайтесь в безопасности, а человек посередине не может его украсть. Совет здесь состоит в том, что этот файл cookie не может быть прочитан на http-страницах, поэтому вы можете знать, что пользователь A или B только на защищенной странице.

Корзина - Продукты

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

Auth cookie

Если вы настроили его только как защищенное, то эти файлы cookie не отображаются/читаются/существуют на незащищенной странице. Это проблема, если вы не защищаете ее.

Response.Cookies[s].Secure = true;

Несколько слов

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

Небезопасным файлом cookie является, например, тот, который соединяет все продукты в корзине или, может быть, историю пользователя (какие продукты видят). Это также то, что нам действительно неинтересно, если кто-то это получает, потому что даже прокси-сервер может видеть по URL-адресу историю пользователя или то, что видит пользователь.

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