Блог

Итак, допустим, у меня есть веб-сайт с базой пользователей, и когда пользователь входит в систему, я помещаю файл cookie (или сеанс) с парой ключ-значение, запоминающей, кто этот пользователь. Но мне только что пришло в голову, какую информацию я должен использовать, чтобы запомнить пользователя, чтобы обеспечить его безопасность. Я не могу использовать username = имя пользователя или user_id = идентификатор пользователя (потому что мой user_id будет равен 1), потому что тогда люди могут просто угадать, каковы значения файлов cookie, и войти в систему как этот пользователь. Итак, какую пару ключ / значение я должен использовать, чтобы иметь возможность идентифицировать пользователей и при этом надежно подключать их информацию к базе данных? Спасибо.

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

https://www.owasp.org/index.php/Session_hijacking_attack

Управление сеансами может быть довольно сложным, и в зависимости от требуемого уровня безопасности вы не захотите заниматься этим самостоятельно, потому что, скорее всего, в вашей среде разработки / фреймворке уже есть решение, прошедшее большую проверку, чем домашнее решение. Вот ссылка, подробно описывающая некоторые моменты, которые следует учитывать, к сожалению, в этой теме есть нечто большее, чем просто сообщение Stack Overflow:

https://www.owasp.org/index.php/Session_Management

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

Если вы хотите сделать это правильно, то вам следует взглянуть на http://jaspan.com/improved_persistent_login_cookie_best_practice также.

Я определенно не эксперт в области безопасности, но недавно я внедрил инструмент управления пользователями и сделал следующее.

• Не используйте шифрование, оно медленное, и в большинстве случаев при простом внедрении это просто пустая трата времени.

Вот что вам действительно нужно сохранить на сервере — для проверки подлинности каждого запроса.

• Идентификатор пользователя (очевидный)
• CookieHash (состоит из идентификатора пользователя, некоторого секретного закрытого ключа и случайно сгенерированного криптографического номера)
• LastLogin
• Возобновлена сессия (полезно при отмене чьего-либо сеанса, например. обновляйте cookieHash каждые 10 минут, в противном случае выйдите из системы пользователя)
• Последний совет

Что я сохраняю в файлах cookie, так это

• Идентификатор пользователя
• CookieHash

Как использовать эту базовую защиту

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

Каждый запрос проверяет идентификатор пользователя на соответствие его хэшу. Если кто-то указал userId = 4, но хэш не совпал, то сеанс автоматически прерывается и пользователь перенаправляется на экран входа в систему. Возможный журнал полезен для того, чтобы увидеть, как часто люди пытаются поиграть с вашей тяжелой работой.

Я надеюсь, это поможет.

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

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

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