Вы правильно поняли, что проблема со смешиванием http и https в стандартном приложении Rails заключается в том, что сеанс должен быть небезопасным (то есть ссылаться на него через небезопасный файл cookie), что означает, что он уязвим для боковых сокетов.1001 *
Как вы упомянули в своем комментарии к ответу @ nmott, один из подходов - иметь как безопасный, так и небезопасный файл cookie.
Вместо того, чтобы ссылаться на два идентичных сеанса, для моих целей я нахожу достаточным иметь незащищенный сеанс Rails вместе с защищенным подписанным файлом cookie, который просто ссылается на user_id текущего вошедшего в систему пользователя.Другими словами, мне не нужна полная копия сеанса, просто что-то уникальное для каждого пользователя (в безопасном файле cookie), которое соответствует небезопасному сеансу.
В каждом действии, к которому осуществляется доступ через SSL (и имеет текущего пользователя), я проверяю, совпадает ли безопасный подписанный cookie user_id с user_id, хранящимся в небезопасном сеансе Rails.Если есть совпадение, я предполагаю, что все в порядке, и действуйте как обычно, ссылаясь на небезопасный сеанс.Если совпадения нет, то я отображаю сообщение об ошибке.Я выполняю это с помощью метода before_filter, такого как следующий:
def verify_secure_user_cookie
# If we have a current user and the request is SSL, we want to make sure the user
# has a secure cookie that matches the current user's id. This prevents attackers
# from side-jacking a session by obtaining a cookie from a non-SSL request.
if current_user and request.ssl?
unless cookies.signed[:user_id] == current_user.id
raise StandardError, "Invalid secure user cookie"
end
end
end
Предположительно, законный пользователь всегда будет иметь безопасный cookie и никогда не увидит сообщение об ошибке.Злоумышленник сможет скопировать только небезопасный файл cookie и не сможет получить доступ к защищенному файлу cookie.В таком случае он мог бы подделать сеанс и получить доступ к страницам без SSL, но он не мог бы получить доступ к страницам SSL, используя сеанс жертвы.
Таким образом, ваши страницы без SSL все еще уязвимык боковому домкрату, но ваши SSL-страницы не уязвимы для бокового сокета.Чтобы это было эффективным, вы должны применять SSL для всех действий, которые должны быть защищены (либо от перехвата, либо от перехвата сеанса).Использование force_ssl в контроллере является одним из способов сделать это, или вы можете бросить свой собственный.