GWT: сохранение идентификатора сеанса в cookie, и что дальше? - PullRequest
7 голосов
/ 18 августа 2010

В настоящее время я делаю сайт с использованием GWT, размещаясь на AppEngine. Я делаю это с помощью своих собственных входов в систему (я знаю, что Google что-то предоставляет с GWT, но мне нужна собственная система входа в систему), и я уже довольно давно пытаюсь определить сессии. Я нашел несколько учебных пособий, и один из сайтов, которые я читал, - http://code.google.com/p/google-web-toolkit-incubator/wiki/LoginSecurityFAQ

Там есть раздел "Как запомнить логины". Я знаю, как получить идентификатор сеанса и сохранить его на клиенте в файле cookie через вызов RPC. Чего я не понимаю, так это того, что, в конце концов, через день или около того пользователь возвращается, и я должен получить идентификатор сеанса из cookie и отправить его обратно на сервер. Что я должен делать на сервере, чтобы безопасно оценить правильность идентификатора сеанса и получить всю необходимую информацию о пользователе?

Дополнительные вопросы: 1. Что изменит идентификатор сеанса? 2. Что делать, если пользователь был на ноутбуке, а пользователь ушел куда-то еще? Сможет ли он по-прежнему безопасно входить в систему без необходимости повторного ввода логина и пароля?

Спасибо!

~ Скотт

Ответы [ 2 ]

8 голосов
/ 18 августа 2010

Аналогичный вопрос: вопрос по GWT, cookie-файлам и управлению веб-страницей .
Следует помнить одну важную вещь: не полагайтесь только на файлы cookie - перенесите идентификатор сессии / токен в полезную нагрузку запроса и сравните его со значением файла cookie на стороне сервера. Это предотвратит атаки XSRF. Это то, о чем вы должны беспокоиться.

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

Что я должен делать на сервере для того, чтобы надежно оценить, если Идентификатор сеанса все еще допустим, и подтяните вся необходимая информация о пользователь?

Вы должны отслеживать идентификаторы сессии / пары входа в вашу БД.

Что изменит идентификатор сеанса?

Либо истекает срок действия, либо пользователь пытается войти в систему с токеном, который не привязан к их IP-адресу. Вы также можете добавить свои собственные правила - например, количество входов в систему и т. Д. Для дополнительной безопасности вы можете генерировать новый идентификатор / токен сеанса при каждом новом входе в систему / сеанс (пользователь аутентифицируется со старым токеном, сервер проверяет его действительность). и отправляет обратно пользователю новый токен, который он / она должен использовать с этого момента).

1 голос
/ 18 августа 2010

Чтобы запомнить логины, вам нужно безопасно создать уникальный идентификатор сессии. Обычно это помещается в куки. Я бы порекомендовал использовать фреймворк, который делает сессионные куки для вас. Если вы ошибетесь, ваш сайт будет широко открыт для злоупотреблений. Вещи для рассмотрения включают в себя:

  • Вам нужно беспокоиться о краже печенья. IP-адрес пользователя должен быть закодирован в идентификаторе сеанса или связан с идентификатором сеанса. Проверяйте IP-адрес на каждой странице доступа.
  • Убедитесь, что ваши логины в зашифрованных сеансах. В противном случае вы предоставляете учетные данные в сети в виде открытого текста.
  • Как долго должны длиться сеансы. Они должны выдержать тайм-аут после установленного срока. Это может длиться часами или днями.
  • Помните, что в разных файлах cookie должны быть разные функции. Он должен содержать что-то, что может быть использовано для идентификации пользователя. В зависимости от ваших требований безопасности это может быть зашифрованное значение. Этот файл cookie может иметь более длительное время ожидания.

Ответы на ваши дополнительные вопросы.

  1. Ничто на стороне клиента не может изменить идентификатор сеанса. Идентификатор сеанса должен обновляться при каждом входе в систему.
  2. В зависимости от того, насколько безопасен идентификатор сеанса, им может потребоваться войти в систему. Защищенные сеансовые куки-файлы часто кодируют IP-адрес, чтобы предотвратить их кражу. Если это так, пользователь ноутбука должен будет войти снова.
...