Модель безопасности в Rails Вопрос - PullRequest
2 голосов
/ 22 февраля 2011

Я читаю отличный Rails-учебник и натолкнулся на отрывок, по которому у меня возник вопрос:

Вставка 9.2. Сеансы и файлы cookie, потому что HTTP - это протокол без сохранения состояния, веб приложения, требующие входа пользователя должен реализовать способ отслеживания каждого прогресс пользователя от страницы к странице. Один техника для поддержания пользователя статус входа должен использовать традиционный Rails сессия (через специальную сессию функция) хранить токен запоминания равно идентификатору пользователя:

session [: запомнить_token] = user.id Этот объект сеанса делает идентификатор пользователя доступно со страницы на страницу, сохраняя это в печенье, которое истекает после закрыть браузер На каждой странице приложение может просто позвонить
User.find_by_id (сессия [: remember_token]) чтобы получить пользователя. Из-за то, как Rails обрабатывает сессии, это процесс безопасен; если злоумышленник пытается подделать идентификатор пользователя, Rails будет обнаружить несоответствие на основе специального идентификатор сессии, сгенерированный для каждой сессии. Для выбора дизайна нашего приложения, который включает в себя постоянные сеансы, то есть статус входа, который сохраняется даже после закрытия браузера - сохранение идентификатор пользователя - это дыра в безопасности. Как как только мы порвем связь между специальный идентификатор сеанса и сохраненный пользователь злоумышленник может войти как тот пользователь с равным Remember_token на идентификатор пользователя. Чтобы исправить этот недостаток, мы генерировать уникальную, безопасную память токен для каждого пользователя на основе соль пользователя и идентификатор. Кроме того, постоянный токен памяти также представляют дыру в безопасности проверка куки браузера, злоумышленник может найти токен а затем использовать его для входа из любого другой компьютер, в любое время. Мы решаем это путем добавления метки времени к токен, и сбрасывать токен каждый раз пользователь входит в приложение. Это приводит к постоянному сеансу по существу непроницаем для атаки.

Я не понимаю, что это говорит. Я беру из этого, что уникальный идентификатор сеанса создается и сохраняется на клиенте в файле cookie. Затем, когда этот файл cookie отправляется на сервер по запросу, сервер знает, что это за пользователь, о котором идет речь, так что вход в систему может быть сохранен. Однако, если злоумышленник украл файл cookie, я не понимаю, почему он не может войти с другого компьютера. Автор говорит, что это решается путем добавления метки времени, но я не вижу, как это помогает. Далее автор говорит, что токен сбрасывается каждый раз, когда пользователь входит в систему, но все дело в постоянном входе, поэтому я не понимаю. Пожалуйста, помогите!

1 Ответ

2 голосов
/ 23 февраля 2011

Вы правы - cookie-файл "Запомнить меня" может использоваться для кражи логина. Проблема, которую они пытаются решить, заключается в том, что если кто-то украдет ваш файл cookie, содержащий ваш уникальный идентификатор, и будет его использовать, он сможет войти в вашу учетную запись в любой момент в будущем.

Обычным решением является аннулирование всех предыдущих файлов cookie каждый раз, когда вы входите в свою учетную запись, используя либо имя пользователя / пароль или файл cookie "Запомнить меня", так что данный Cookie позволит вам войти в систему один раз. Отметка времени показывает, как они обеспечивают уникальность каждого файла cookie.

Если вы беспокоитесь о краже файлов cookie, типичным решением также является сохранение IP-адреса, с которого поступил запрос, и если IP-адрес, с которого поступает файл cookie, не совпадает с IP-адресом, по которому файл cookie был создан из, запретите вход в систему и вынудите пользователя войти в систему. Это может быть неудобно для пользователей, которые находятся за динамическими прокси-серверами, или которые несут свой ноутбук в и из работы / дома / кафе, так как их IP-адрес изменит все время.

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

Если вам нужна дополнительная информация по этой теме, в разделе Руководство по безопасности Руководства по Rails есть целый раздел о сессиях.

...