Как предотвратить случайную аутентификацию пользователей Rails как неправильного пользователя?

Question

В частности, я написал приложение на Rails, в котором я использую хранилище сессий по умолчанию (в Rails 2.3.5) CookieStore, и я обнаружил странную проблему в разработке.

Сам инесколько других пользовались сайтом в течение нескольких недель, и у каждого из нас был логин, основанный на имени пользователя и пароле (каждый пользователь регистрировал себя, и я сохранял (соленые и хэшированные) данные в базе данных).Я хранил идентификатор пользователя в объекте Rails session (и, следовательно, в файле cookie, который передается взад-вперед между браузером и сервером).

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

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

Я думаю, я понимаю, почему это произошло:идентификатор пользователя, переданный из браузера этого пользователя на сервер, теперь соответствует другой записи пользователя в моей базе данных.Моей первоначальной мыслью было: «О, дорогой, я этого не ожидал!»но чем больше я думал об этом, тем больше осознавал, что это, вероятно, ожидаемое поведение.

Я понимаю, что могу изменить свое приложение на Rails на пользователя ActiveRecordStore, но перед этим я хотел убедиться, что понимаю, что происходитЗдесь.В частности, действительно ли сочетание использования CookieStore сеансов и их сохранения в течение некоторого времени действительно создает такую ​​зияющую дыру в безопасности?Или я что-то упустил?Должен ли session_id обеспечивать здесь немного больше безопасности?

Answer 1

Большая дыра в безопасности в этой настройке - это не длина куки, а установка user_id в куки.Это означает, что любой, кто входит на ваш сайт, может войти как любой другой пользователь, просто изменив этот файл cookie!Хакер просто последовательно прошел бы по user_id, войдя в систему и увидев, что они хотят украсть или злоупотребить.

Если вы хотите выполнить свою собственную аутентификацию, попробуйте это вместо этого: добавьте строковое поле "token" вваш пользовательский стол.Когда кто-то входит в систему, установите для этого токена случайный набор цифр и букв и передайте пользователю , что , в качестве файла cookie.Маркер должен содержать не менее 32 символов, буквенно-цифровой, верхний и нижний регистр.

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

UPDATE

@ shingara прав, что хранилище cookie обрабатываетчасть безопасности уже моя ошибка.Поэтому смешивание user_id является единовременным, поскольку вы сбрасываете базу данных.Это не проблема, с которой вы столкнетесь в производственной среде, если только вы не сбросите базу данных снова.Если сброс когда-либо возможен, все равно выполните создание токена, как я рекомендовал.В противном случае, ты в порядке.

Answer 2

Самое простое решение проблемы, с которой вы столкнулись, - это изменить имя файла cookie при сбросе базы данных.Имя файла cookie должно быть в config / initializers / session_store.rb

ActionController::Base.session = {
  :key         => '_your_app_session_v2',

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

Answer 3

У меня была похожая проблема, и я решил ее, используя фрагмент кода, похожий на этот комментарий mdesantis об управлении секретным токеном Rails

Answer 4

Спасибо за все ответы.Все они ответили на мой вопрос таким образом: да, моя установка (и не установка нового ключа сеанса после стирания пользователей) создает дыру в безопасности.

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

Итак, подведя итог, я задал вопрос, потому что не смог найти ничего, что обсуждало бы опасность сеанса CookieStore+ долгое время жизни печенья , и я обнаружил, что это удивительно, и я подумал, что могу упустить что-то очевидное.

Answer 5

Ваш случай поступил, только если у вас есть 2 разных пользователя с одинаковым идентификатором user_id.Так что это невозможно, если вы определите user_id как уникальный.

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