Сеансовые куки со знаком. Хорошая идея?
Когда поток вашей программы в функции сталкивается с оператором return, возвращается элемент управления для размещения вызывающей эту функцию. Это правда, даже если это была та же самая функция. Это совершенно нормально и ожидаемо.
В вашем случае каждый вызов все еще должен выполнить после рекурсивного шага (потому что ваш вызов expo() никогда не бывает последним до return), и вы видите, как программа получает на этой работе.
Следите за кадром стека во время отладки; вы увидите, что на самом деле это не так, как вы думаете; вы возвращаетесь к предыдущему контексту вызова.
4 ответа
Подписанный токен - хороший метод для всего, где вы хотите выпустить токен, а затем, когда он будет возвращен, иметь возможность проверить, что вы выпустили токен, без необходимости хранить какие-либо данные на стороне сервера. Это хорошо для таких функций, как:
- ограниченный по времени вход в учетную запись;
- сброс пароля;
- формы анти-XSRF;
- ограниченное по времени представление формы (защита от спама).
Сам по себе он не является заменой файла cookie сеанса, но если он может вообще устранить необходимость в каком-либо хранилище сеанса, это, вероятно, хорошо, даже если разница в производительности не будет огромной.
HMAC - это один из разумных способов создания подписанного токена. Это не будет самым быстрым; вы можете обойтись простым хешем, если знаете и можете избежать атак расширения. Я оставлю вам решать, стоит ли вам рисковать.
Я предполагаю, что hmac () на любом языке, который вы используете, был настроен на использование подходящего секретного ключа на стороне сервера, без которого у вас не может быть безопасного подписанного токен. Этот секрет должен быть надежным и хорошо защищенным, если вы хотите построить на нем всю свою систему аутентификации. Если вам нужно его изменить, все будут отключены.
Для входа в систему и сброса пароля вы можете добавить дополнительный фактор к токену, номер генерации пароля. Вы можете повторно использовать для этого хешированный пароль в базе данных, если хотите. Идея состоит в том, что когда пользователь меняет пароли, он должен аннулировать все выпущенные токены (за исключением файла cookie в браузере, выполняющего изменение пароля, который заменяется повторно выпущенным).В противном случае пользователь, обнаруживший, что его учетная запись была взломана, не сможет заблокировать другие стороны.
Да, это плохая идея.
Для начала, это небезопасно. С помощью этой схемы злоумышленник может создать собственный файл cookie и выдать себя за любого пользователя.
Идентификаторы сеанса должны выбираться из большого (128-битного) пространства с помощью криптографического генератора случайных чисел.
Они должны быть конфиденциальными, чтобы злоумышленники не могли их украсть и выдать себя за аутентифицированного пользователя. Любой запрос, выполняющий действие, требующее авторизации, должен быть защищен от несанкционированного доступа. То есть весь запрос должен иметь какую-то защиту целостности, такую как HMAC, чтобы его содержимое не могло быть изменено. Для веб-приложений эти требования неизбежно приводят к HTTPS.
Какие проблемы с производительностью у вас есть? Я никогда не видел веб-приложений, в которых надлежащая безопасность создавала какую-либо точку доступа.
Если у канала нет конфиденциальности и целостности, вы открываете себя для атак «человек посередине». Например, без конфиденциальности Алиса отправляет свой пароль Бобу. Ева выслеживает его и может войти позже как Алиса. Или, с частичной целостностью, Алиса присоединяет свой подписанный файл cookie к запросу на покупку и отправляет их Бобу. Ева перехватывает запрос и изменяет адрес доставки. Боб проверяет MAC на куки, но не может обнаружить, что адрес был изменен.
У меня нет никаких цифр, но мне кажется, что возможности для атак «человек посередине» постоянно растут. Я замечаю рестораны, использующие сеть Wi-Fi, которую они предоставляют клиентам для обработки своих кредитных карт. Люди в библиотеках и на рабочих местах часто подвержены прослушиванию, если их трафик не превышает HTTPS.
Что заставляет вас думать, что это улучшит производительность по сравнению с безопасными идентификаторами сеанса и извлечет идентификатор пользователя и информацию о времени из серверного компонента сеанса? положить его в руки малышей. Например, не передавайте его клиенту вообще, даже с защитой от несанкционированного доступа.
Игнорируя идеологические проблемы, это выглядит довольно прилично. У вас нет одноразового номера. Вы должны добавить это. Просто случайный мусор, который вы храните вместе с идентификатором пользователя и временем, чтобы предотвратить повтор или предсказание.
Вы не должны изобретать велосипед . Обработчик сеанса, который поставляется с вашей платформой разработки, намного более безопасен и, безусловно, проще в реализации. Файлы cookie всегда должны быть очень большими случайными числами, которые связаны с данными на стороне сервера. Файл cookie, содержащий идентификатор пользователя и отметку времени, не помогает защитить сеанс от атаки.
Предлагаемый обработчик сеанса более уязвим для атак, чем использование криптографического одноразового номера для каждого сеанса. Сценарий атаки следующий.
Вероятно, вы используете один и тот же секрет для расчета HMAC для всех сеансов. Таким образом, этот секрет может быть взломан злоумышленником, входящим в систему со своей учетной записью. Посмотрев на свой идентификатор сеанса, он может получить все, кроме секрета.Затем злоумышленник может перебрать секрет до тех пор, пока значение hmac не будет воспроизведено. Используя этот секрет, он может восстановить административный файл cookie и изменить свой user_id = 1 , что, вероятно, предоставит ему административный доступ.