Постоянство сеанса SSL и безопасные куки

Question

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

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

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

Мое исследование до сих пор показало это , в котором, по сути, сказано: "храни свой хэш токена аутентификации с помощью ключа сеанса SSL."

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

это сценарий, который я представляю:

1. Сеанс SSL установлен и ключ согласован.
2. Клиент аутентифицируется на сервере на уровне приложения (т.е. через имя пользователя и пароль).
3. Сервер записывает защищенный файл cookie, содержащий ключ сеанса SSL.
4. Произошло что-то , которое вызывает повторное согласование сеанса. Например, я думаю, что IE делает это на таймере с или без причины.
5. Клиент отправляет запрос на сервер, содержащий старый сеансовый ключ (поскольку на уровне приложения не было известно о повторном согласовании на уровне приложения, не было возможности записать новый, обновленный хеш-код клиенту ).
6. Сервер отклоняет учетные данные клиента из-за ошибки совпадения хэшей и т. Д.

Это реальная проблема или это неправильное понимание с моей стороны из-за (по меньшей мере) неполного понимания того, как работает SSL?

Answer 1

См. Все темы, связанные с Постоянство SSL . Это хорошо изученная проблема в мире балансировки нагрузки.

Краткий ответ: вы не можете полагаться на SSLID - большинство браузеров пересматривают, и вам все равно придется использовать исходный IP. Если IP-адрес может измениться в середине сеанса, вы можете принудительно выполнить мягкую повторную аутентификацию или использовать SSLID в качестве моста между двумя изменениями IP-адреса (и наоборот, т.е. предполагать перехват только в том случае, если оба IP-адрес и SSLID изменяются одновременно, как видно на сервере.)

ОБНОВЛЕНИЕ 2014

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

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

Answer 2

Мне интересно, почему бы просто не

1. требуется ssl в вашем транспорте
2. кодирует входные данные (html / url / attribute) для предотвращения межсайтовых скриптов
3. требуют только POST для всех запросов, которые изменяют информацию, и
4. предотвращайте CSRF как можно лучше (в зависимости от того, что поддерживает ваша платформа).
5. Установите файлы cookie для HTTPOnly

Answer 3

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

- MarkusQ