Как работают сеансы и файлы cookie в Rails?

Question

Я использую Devise для обработки аутентификации в своих приложениях Rails, но так и не понял, как это работает. Поскольку Devise также использует конфигурацию хранилища сеансов, установленную в Rails, я предполагаю, что это вопрос о сеансовой обработке с Rails.

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

Вот что я знаю, до сих пор ..

Я знаю о печенье и сессий. Файлы cookie представляют собой строки, хранящиеся на стороне клиента, которые используются для поддержки сеанса по нескольким HTTP-запросам.

Вот мое основное понимание аутентификации (пожалуйста, поправьте меня, если я ошибаюсь):

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

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

Вот мои вопросы:

1. Я прочитал, что по умолчанию, начиная с Rails 2, теперь он использует CookieStore (вместо SessionStore), который генерирует сессии хэши с SHA512 (вместо идентификаторов сеансов), и все это сохраняется в файле cookie, что означает, что несколько идентификаторов пользователя могут иметь один и тот же сеансовый хеш, и он будет работать нормально. Мне кажется, что это очень опасная вещь, подвергая большое количество хэшей одним секретным ключом, хранящимся на сервере, и основывая всю вашу систему аутентификации на основе этого ключа. Существует ли приложение реального масштаба для больших масштабов, которое использует хеширование вместо хранения идентификаторов сеанса на стороне сервера?

2. Что касается хранения активного идентификатора сеанса на стороне сервера, я также прочитал, что вы можете переключиться на использование разных видов хранилища сеансов для Rails. Исходя из этого, я слышал о системах, которые перешли системы аутентификации в качестве сервисов и вместо них использовали токены auth. Что такое токен аутентификации и как он отличается от идентификатора сеанса?

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

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

Answer 1

Я прочитал, что по умолчанию, начиная с Rails 2, теперь он использует CookieStore (вместо SessionStore), который генерирует сеанс хэши с SHA512 (вместо сессионных идентификаторов), и все это хранится на cookie, что означает, что несколько идентификаторов пользователя могут иметь тот же самый азарт сессии , и он будет работать нормально. Мне кажется, что это очень опасная вещь, подвергая большое количество хэшей одним секретным ключом , хранящимся на сервере, и основывая всю систему аутентификации на основе этого ключа.

Да, это кажется страшным с первого взгляда, но я не уверен, какая опасность на самом деле. В Rails 4 данные сеанса шифруются с использованием PBKBF2, а затем подписывается с вашим секретом сеанса. Это подписание помогает определить, было ли изменено содержимое зашифрованного сеанса, и сервер отклонит сеанс, если он обнаружит фальсификацию.

https://cowbell-labs.com/2013-04-10-decrypt-rails-4-session.html

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

Есть ли приложение реального масштаба в реальном мире, использующее хеширование вместо хранения идентификаторов сеанса на стороне сервера?

честно, я не знаю ответа на этот экспромтом, но я подозреваю, что тот факт, что это «по умолчанию» для Rails означает, что есть больше, чем несколько сайтов там, используя куки сессии магазинов ,

На тему сохранения активных идентификаторов сессии на стороне сервера, я также прочитал, что вы можете переключиться на использование различных видов хранения сессии для Rails. Исходя из этого, я слышал о системах, которые перехватывали аутентификацию как услуги и вместо них использовали токены auth. Что такое токен и как он отличается от идентификатора сеанса?

Я делаю это на сервере сейчас - в основном случайный хеш генерируется, когда пользователь аутентифицируется и этот хеш хранится, зашифровывается и подписывается в файле cookie. Хэш-файл cookie является ключом к серверному хранилищу данных (в моем случае Redis, но он может быть в реляционной базе данных или memcache или как вам нравится), а фактические данные сеанса - это сохраненная серверная сторона, сопоставленная с этим ключом. Это оставляет меньше ваших данных сеанса в руках клиента, поскольку люди могут потенциально расшифровать и проанализировать его, так что это в целом немного безопаснее.

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

Да, вы могли бы сделать это, но это заняло бы очень и очень долго.Вам также нужно угадать, как подписать недавно измененные данные cookie, чтобы он соответствовал тому, что сервер ожидает увидеть на своей стороне, и он подписан с довольно большим ключом.

Я действительно не думаю, что существует много альтернатив для сохранения состояния аутентификации при использовании файлов cookie (я полагаю, что HTML5 Local Storage будет работать, если вы чувствуете себя экзотично и не заботитесь о поддержке старого браузера).