После входа в систему, должны ли все страницы быть https?

Question

Это будет немного сложно объяснить, но я постараюсь изо всех сил.

Существует веб-сайт, на котором есть форма входа в систему на каждой странице с полями имени пользователя и пароля. Эти страницы не используют SSL. После того, как пользователь заполнит имя пользователя/пароль и отправит форму, форма отправляется на страницу аутентификации https.

У меня есть несколько вопросов об этой ситуации.

1. При отправке формы на страницу https зашифрованы данные? Или только после перехода с https-страницы (я предполагаю, что это только происходит)?
2. Если ответ на номер один - это лестница, значит ли это, что мне нужно будет использовать https для всех страниц, потому что отсюда переадресовывается форма входа?
3. После аутентификации пользователя с помощью https пользователь может быть перенаправлен обратно на http и продолжить использование данных сеанса? Или пользователь должен оставаться в https?
4. Лучше/хуже оставить пользователя в https?

Большое спасибо за помощь!
Метрополис

ЗАКЛЮЧЕНИЕ

Итак, после того, как думать об этом некоторое время я решил просто сделать все это по протоколу HTTPS. @Mathew + @Rook, ваши ответы были отличными, и я думаю, что вы оба делаете большие очки. Если бы я был в другой ситуации, я, возможно, делал это по-другому, но вот мои причины для создания всего https.

1. Управление запросами на страницы будет проще, так как мне остается только оставаться в https.
2. Im не слишком озабочены Performace (в другой ситуации я, возможно, был)
3. мне не нужно будет удивляться, если данные пользователей обеспечено как во всех местах
4. я буду следовать директиве OWASP, как Грач заявил

Answer 1

Согласно The OWASP top 10 ни в коем случае не может использоваться аутентифицированный идентификатор сеанса по протоколу HTTP. Таким образом, вы создаете сеанс по протоколу HTTP, а затем этот сеанс становится аутентифицированным, тогда вы нарушили Top 10 OWASP, и вы позволяете вашим пользователям быть восприимчивыми к атаке.

Я рекомендую установить secure flag on your cookie. Это ужасное имя для этой функции, но заставляет файлы cookie быть только https. Это не следует путать с «Httponly cookie», который является другим флагом, который помогает смягчить влияние xss.

Чтобы убедиться, что ваши пользователи в безопасности, я постоянно использовал HTTPS. ssl - очень легкий протокол, если вы сталкиваетесь с проблемами ресурсов, а затем подумайте о цепочке https-политик.

Answer 2

1. Да. Если URL-адрес действия - https, данные формы зашифровываются.
2. Из-за # 1 вам не нужно делать страницу https, но вы можете получать предупреждения о смешанном содержании. И, конечно же, злоумышленник «человек в середине» может манипулировать страницей входа, чтобы указать на другой URL-адрес действия.
3. Это решение для вас. Очевидно, что любые данные, передаваемые через HTTP, будь то файлы cookie (включая файлы cookie cookie) или пользовательские данные, могут быть перехвачены и обработаны.
4. Опять же, это компромисс, основанный на производительности и безопасности.

Answer 3

В дополнение к тому, что говорит Ладья, подав форму с HTTP на HTTPS риск для нескольких причин:

1. Там нет иконки «замок» на странице, где люди типа в их имя пользователя и пароль, поэтому у них нет способа узнать, что их данные зашифрованы (кроме как «доверять вам»)
2. Если кто-то угнал вашу страницу, ваши пользователи не смогут узнать, что они собираются ввести их имя пользователя и пароль и перенаправить на вредоносную страницу (это в некотором смысле следствие № 1).

Это гораздо проще, чем атака HTTP куки перехвата, так что это на самом деле еще больший риск ...

Но точка ладья важна: вы должны никогда соединение HTTP и HTTPS трафик. На наших сайтах, как только вы вошли в систему, все - это https с этого момента.

Answer 4

Помимо предыдущих ответов, поскольку люди склонны идти от HTTPS к HTTP по соображениям производительности, this article about HTTPS at Google может представлять интерес. Его основным сообщением является:

SSL/TLS не является вычислительным дорогим.