W
Я пересмотрю одно видео
Size: a a a
2019 November 13
W
И точно скажу или просто дропну сюда его
С
Я пересмотрю одно видео
Давай
W
Пока что скидываю про JWT, то что смотрел я
W
про куки ничего нету, сейчас сам буду гуглить
С
Да, я это смотрел. Там во второй части как раз о недостатках говорится
W
Да, я это смотрел. Там во второй части как раз о недостатках говорится
Именно
W
https://tproger.ru/translations/user-session-security/
Краткосрочный токен доступа с долгоживущим токеном обновления
Особенности:
Если пользователь добровольно выходит из системы, токены доступа и обновлений аннулируются и удаляются на фронтенде.
Токен авторизации (токен обновления) постоянно открыт в двух пространствах для атаки — фронтенде и бэкенде — и время от времени открыт во время передачи.
В случае кражи злоумышленник будет иметь несанкционированный доступ в течение короткого периода времени (до истечения срока действия токена).
Злоумышленник может использовать украденный токен обновления, чтобы получить новые токены доступа и пользоваться несанкционированным доступом к учётной записи жертвы долгое время.
Кража токена может быть обнаружена только с помощью эвристических алгоритмов или если пользователь уведомит поставщика услуг.
Токены доступа не нужно отзывать, поскольку они недолговечны. При необходимости токены доступа Opaque и токены обновления можно легко отозвать, удалив их из базы данных.
Обнаружить кражу можно при определённых сценариях и реализациях. Например, в одной из реализаций предыдущие токены доступа будут немедленно аннулированы при создании нового токена. Это позволяет системе распознать кражу, когда злоумышленник и жертва находятся в сети одновременно. Если злоумышленник использует токен обновления, токен доступа жертвы будет аннулирован, что заставит жертву запросить новый токен доступа. Это приведёт к другому запросу от злоумышленника и так далее. Если бэкенд обнаруживает короткие интервальные запросы на новые токены, можно сделать вывод, что произошла кража.
CSRF
Эта атака не направлена на кражу аутентификационных токенов. Вместо этого она позволяет злоумышленнику использовать текущую активную сессию.
Для предотвращения таких атак обычно требуется использование анти-CSRF токена или SameSite cookie.
https://tyapk.ru/blog/post/authentication-methods
Краткосрочный токен доступа с долгоживущим токеном обновления
Особенности:
Если пользователь добровольно выходит из системы, токены доступа и обновлений аннулируются и удаляются на фронтенде.
Токен авторизации (токен обновления) постоянно открыт в двух пространствах для атаки — фронтенде и бэкенде — и время от времени открыт во время передачи.
В случае кражи злоумышленник будет иметь несанкционированный доступ в течение короткого периода времени (до истечения срока действия токена).
Злоумышленник может использовать украденный токен обновления, чтобы получить новые токены доступа и пользоваться несанкционированным доступом к учётной записи жертвы долгое время.
Кража токена может быть обнаружена только с помощью эвристических алгоритмов или если пользователь уведомит поставщика услуг.
Токены доступа не нужно отзывать, поскольку они недолговечны. При необходимости токены доступа Opaque и токены обновления можно легко отозвать, удалив их из базы данных.
Обнаружить кражу можно при определённых сценариях и реализациях. Например, в одной из реализаций предыдущие токены доступа будут немедленно аннулированы при создании нового токена. Это позволяет системе распознать кражу, когда злоумышленник и жертва находятся в сети одновременно. Если злоумышленник использует токен обновления, токен доступа жертвы будет аннулирован, что заставит жертву запросить новый токен доступа. Это приведёт к другому запросу от злоумышленника и так далее. Если бэкенд обнаруживает короткие интервальные запросы на новые токены, можно сделать вывод, что произошла кража.
CSRF
Эта атака не направлена на кражу аутентификационных токенов. Вместо этого она позволяет злоумышленнику использовать текущую активную сессию.
Для предотвращения таких атак обычно требуется использование анти-CSRF токена или SameSite cookie.
https://tyapk.ru/blog/post/authentication-methods
W
Вот что я нарыл
С
Из всего вышесказанного делаю вывод, что JWT менее безопасен чем сессии
Тогда вопрос, где их использование актуально?
Тогда вопрос, где их использование актуально?
Тааак, вывод меняется. JWT и сессии походу равносильны.
Если украли токен сессии то нужно обрывать его вручную
Если украли JWT токены, то они автоматом сбрасываются при авторизации
Если ставить оповещения, то
В одном случае нужно восстанавливать пароль, или сбрасывать сессию на специальной странице
Во втором просто авторизоваться повторно
Если украли токен сессии то нужно обрывать его вручную
Если украли JWT токены, то они автоматом сбрасываются при авторизации
Если ставить оповещения, то
В одном случае нужно восстанавливать пароль, или сбрасывать сессию на специальной странице
Во втором просто авторизоваться повторно
С
Тааак, вывод меняется. JWT и сессии походу равносильны.
Если украли токен сессии то нужно обрывать его вручную
Если украли JWT токены, то они автоматом сбрасываются при авторизации
Если ставить оповещения, то
В одном случае нужно восстанавливать пароль, или сбрасывать сессию на специальной странице
Во втором просто авторизоваться повторно
Если украли токен сессии то нужно обрывать его вручную
Если украли JWT токены, то они автоматом сбрасываются при авторизации
Если ставить оповещения, то
В одном случае нужно восстанавливать пароль, или сбрасывать сессию на специальной странице
Во втором просто авторизоваться повторно
Я даже больше в сторону jwt склоняюсь, для пользователя меньше гемора и не нужно делать логику работы с сессией
W
Тааак, вывод меняется. JWT и сессии походу равносильны.
Если украли токен сессии то нужно обрывать его вручную
Если украли JWT токены, то они автоматом сбрасываются при авторизации
Если ставить оповещения, то
В одном случае нужно восстанавливать пароль, или сбрасывать сессию на специальной странице
Во втором просто авторизоваться повторно
Если украли токен сессии то нужно обрывать его вручную
Если украли JWT токены, то они автоматом сбрасываются при авторизации
Если ставить оповещения, то
В одном случае нужно восстанавливать пароль, или сбрасывать сессию на специальной странице
Во втором просто авторизоваться повторно
Можно даже реализовать систему
W
Которая бы отслеживала что один и тот же рефреш токен прилетает
W
Несколько раз и розлогинивать юзера
W
Или в будущем тупо игнорировать
W
через middleware
W
Пока юзер не введёт ещё раз свои данные для авторизации
W
Я даже больше в сторону jwt склоняюсь, для пользователя меньше гемора и не нужно делать логику работы с сессией
И суть в том, что ты можешь между разными доменами, на втором сайте это визуально продемонстрировано
С
Тааак, вывод меняется. JWT и сессии походу равносильны.
Если украли токен сессии то нужно обрывать его вручную
Если украли JWT токены, то они автоматом сбрасываются при авторизации
Если ставить оповещения, то
В одном случае нужно восстанавливать пароль, или сбрасывать сессию на специальной странице
Во втором просто авторизоваться повторно
Если украли токен сессии то нужно обрывать его вручную
Если украли JWT токены, то они автоматом сбрасываются при авторизации
Если ставить оповещения, то
В одном случае нужно восстанавливать пароль, или сбрасывать сессию на специальной странице
Во втором просто авторизоваться повторно
Хотяяя. А как тогда сбросить рефрешнутый токен злоумышленника?