Требование токена CSRF, если реализован JWT

Требуется ли токен CSRF в коде, если мы реализовали аутентификацию и авторизацию на основе JWT?

Требуется кому?

Robby Cornelissen 03.07.2024 10:00

в приложении весенней загрузки

utkarsh sharma 03.07.2024 10:28
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
Поднятие тревоги для долго выполняющихся методов в Spring Boot
Поднятие тревоги для долго выполняющихся методов в Spring Boot
Приходилось ли вам сталкиваться с требованиями, в которых вас могли попросить поднять тревогу или выдать ошибку, когда метод Java занимает больше...
Версия Java на основе версии загрузки
Версия Java на основе версии загрузки
Если вы зайдете на официальный сайт Spring Boot , там представлен start.spring.io , который упрощает создание проектов Spring Boot, как показано ниже.
Документирование API с помощью Swagger на Springboot
Документирование API с помощью Swagger на Springboot
В предыдущей статье мы уже узнали, как создать Rest API с помощью Springboot и MySql .
1
2
57
2
Перейти к ответу Данный вопрос помечен как решенный

Ответы 2

CSRF — это эксплойт, используемый для того, чтобы заставить пользователей отправить запрос на изменение. Аутентификация на основе JWT не обеспечивает никакой защиты от этого, поскольку проблема не в аутентификации. Следовательно, никакой механизм аутентификации не защитит вас от CSRF.

Spring Security предоставляет некоторые простые меры противодействия. Покопайтесь в их документации для идей.

Ответ принят как подходящий

CSRF — это подделка межсайтовых запросов, тип атаки, которая заставляет прошедших проверку подлинности пользователей выполнить что-либо. Например, если вы разрешаете отправку запроса GET и выполнение операций, таких как

https://your.site.com/delete-user/123

то, если это разрешено, кто-то может отправить вам ссылку на это, и если вы откроете ее, то пользователь будет удален от вашего имени. Таким образом, JWT не защитит вас от самого JWT, для этого вам потребуются токены CSRF.

Не забывайте, что POST-запросы могут быть сфабрикованы аналогичным образом. Например, если вы случайно встраиваете вредоносный файл Javascript, который отправляет POST-запрос, который вам не нравится, то возможна такая же подделка.

Таким образом, в целом имеет смысл иметь механизм токена CSRF, токен генерируется каждый раз, когда страница должна отображаться, токен ожидается при следующем запросе, отличном от GET, и гарантируется, что запросы GET не будут выполнять такие изменения, как удаление , редактирование контента или что-то в этом роде, но изменение приемлемого типа запроса для них на POST или что-то в этом роде.

но все же, если идентификатор сеанса предоставляется с использованием файлов cookie... злоумышленник не может предоставить jwt... что приводит к 403?

utkarsh sharma 03.07.2024 10:27

@utkarshsharma мы говорим не о злоумышленниках JWT, а о злоумышленниках CSRF. Предположим, пользователь X правильно вошел в ваше приложение через JWT в каком-то браузере, где у него есть соответствующий сеанс. Если приложение позволяет выполнять запросы и выполнять операции записи из действующего сеанса без защиты CSRF, тогда ваш пользователь может отправить запрос на выполнение таких операций записи, и сервер не сможет определить, действительно ли пользователь намеревался это сделать. Таким образом, если кто-то отправит пользователю X ссылку, которая должна выполнить запрос, о котором пользователь X не знает, он, тем не менее, будет выполнен в

Lajos Arpad 03.07.2024 10:55

@utkarshsharma браузер, в котором у пользователя X есть действительная сессия, и при условии отсутствия защиты от такой подделки запрос будет выполнен без ведома X об этом. Другими словами, предположим, что вы вошли в систему с помощью JWT, и ваше приложение позволяет выполнять операции записи без токенов CSRF. Если запрос GET или POST успешно инициируется от имени пользователя, у которого уже есть действующий сеанс, ваша аутентификация JWT не защитит вас от таких подделок, поэтому для предотвращения этого вам понадобится токен CSRF.

Lajos Arpad 03.07.2024 10:57

@utkarshsharma, так что 1. Вы входите в систему через JWT, у вас есть действительный сеанс, 2. Кто-то успешно запускает запрос от вашего имени в вашем браузере, где вы уже прошли аутентификацию. 3. Вредоносный запрос будет успешно выполнен, если ваше приложение не ожидает действительный токен CSRF.

Lajos Arpad 03.07.2024 10:59

браузер, в котором у пользователя X есть действительный сеанс, и, при условии, что нет защиты от такой подделки, запрос будет выполнен без того, чтобы X даже не знал об этом. Другими словами, предположим, что вы вошли в систему с помощью JWT, и ваше приложение позволяет выполнять операции записи без токенов CSRF. Если API, выполняющий операцию записи, требует JWT в заголовке. Как это позволит выполнить операцию записи без токена jwt?

utkarsh sharma 03.07.2024 11:40

@utkarshsharma вам обязательно понадобится токен CSRF. Если вы работаете с некоторым JWT, отправляемым в API, и он переопределяется каждый раз, когда вы запрашиваете API, тогда ваш JWT также работает как токен CSRF. Итак, ответьте, пожалуйста, на следующие вопросы: 1. Все ли ваши конфиденциальные операции отправляют JWT в ваш API? Если да, то получает ли он новый JWT от API при каждом таком запросе? 3. Является ли ваш API вашим IDP?

Lajos Arpad 03.07.2024 11:47

Другие вопросы по теме

Не могу понять, почему мой логинконтроллер не может аутентифицировать пользователя. Spring Security сводит меня с ума
API не может получить доступ к частным конечным точкам (403 запрещено), даже если пользователь прошел аутентификацию
Bean-компонент типа «org.springframework.security.crypto.password.PasswordEncoder», который не удалось найти
Проблема Spring Security с JWT: невозможно создать подкласс финального класса JwtAuthenticationProvider
Проблемы с пользовательским поставщиком аутентификации при весенней загрузке 3.3.0
Как защитить конечную точку веб-сокета микросервиса с помощью Spring Cloud Gateway?
Дополнительная логика проверки при обновлении токена доступа
Обработка внутренней ошибки сервера, когда эмитент OAuth недоступен в WebFluxSecurity
Почему защита CSRF необходима для подключения к веб-сокетам, если Spring Security реализует политику одинакового происхождения на уровне сервера?
Spring Security + Keycloak (с самоподписанными сертификатами) – как отключить проверку имени хоста?

Похожие вопросы

Не могу понять, почему мой логинконтроллер не может аутентифицировать пользователя. Spring Security сводит меня с ума
Как увеличить максимальную длину выражений SpEL в весенней загрузке 3.3.0?
API не может получить доступ к частным конечным точкам (403 запрещено), даже если пользователь прошел аутентификацию
Camunda 7, Spring Boot, проблема с Эврикой
Вызов любых частных (закрытых) запросов REST приводит к ошибке построения пути PKIX в Spring Security 6 (OAuth2ResourceServer)
Виртуальные потоки не используются в приложении Spring Boot 3.2, несмотря на конфигурацию
Bean-компонент типа «org.springframework.security.crypto.password.PasswordEncoder», который не удалось найти
Проблема Spring Security с JWT: невозможно создать подкласс финального класса JwtAuthenticationProvider
Проверка подписи JWT не удалась
Шаблон проектирования интерфейса для классов.... Кто-нибудь использует шаблон проектирования интерфейса для классов?