Реализация сессий в рельсах

Question

Я делаю первый проход, выполняя свою собственную аутентификацию и сеансы в rails, и не уверен, что понимаю поддержку сеансов, которая присутствует. (Под первым проходом я имею в виду, что сначала я аутентифицируюсь через http, а не через https. Рабочий код будет использовать https.)

Мое понимание безопасных сеансов состоит в том, что вы передаете токен браузеру через cookie-файл через SSL, а затем сравниваете этот токен с токеном, хранящимся на сервере, чтобы выяснить, действительно ли это пользователь, которого вы считаете. Я надеялся, что вы, ребята, сможете проверить мое понимание безопасных сессий, а именно:

1. Пользователь получает страницу входа и отправляет имя пользователя и пароль (POST через SSL).
2. Сервер проверяет протокол и затем проверяет sha1 пароля (обычно + соль) по существующему хешу в БД. Если они совпадают, сгенерируйте идентификатор сеанса, поместите его как в (n SSL) cookie с идентификатором пользователя, так и в хранилище сеансов на стороне сервера. Перенаправить пользователя в защищенную область сайта.
3. Этот идентификатор сеанса остается неизменным на протяжении всего сеанса пользователя, вошедшего в систему - или - сервер выдает новый идентификатор сеанса после каждой безопасной операции, отправляя его через файл cookie SSL и сохраняя новое значение в БД.
4. Любые действия, которые включают в себя личные или защищенные данные, проверяют хранилище сеанса на наличие идентификатора сеанса для этого пользователя и, если он присутствует, сравнивают идентификатор сеанса cookie с хранилищем сеанса перед выполнением действия. Если мы чередуем идентификаторы сеансов, после действия введите новый идентификатор сеанса (файл cookie SSL и хранилище на стороне сервера).
5. Пользователь выходит из системы, что говорит серверу удалить идентификатор сеанса из хранилища сеансов и очистить cookie. Или срок действия файла cookie истекает в браузере и / или на сервере, и требуется повторная проверка подлинности.

Есть ли явные ошибки в приведенном выше? Кроме того, похоже, что поддержка сеанса [] Rails не предотвратила бы атаки MITM, если бы токен в cookie был просто идентификатором сеанса. Это правильно?

Answer 1

Я бы посоветовал взглянуть на restful_authentication . Это стандартная библиотека аутентификации для Rails по умолчанию.

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

Технически вы были бы уязвимы для атаки MITM, если вы не используете соединение SSL.

Answer 2

Вы, кажется, путаете «сеанс» и «вход в систему». Сеансовый объект в Rails - это просто хэш, который хранится в файле cookie, и он всегда присутствует & mdash; независимо от того, вошел ли пользователь в систему.

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

Плагин restful_authentication делает много вещей. Возможно, вы найдете мое Blank Rails App более полезным, поскольку оно делает нечто похожее с гораздо меньшим количеством кода. Взгляните на контроллер сессий и lib / authentication , где определен код контроллера, связанный с аутентификацией.

Answer 3

Попробуйте этот веб-сайт, http://www.quarkruby.com/2007/10/21/sessions-and-cookies-in-ruby-on-rails. Похоже, что это достаточно полный охват предмета.

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

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