Требуется ли токен CSRF в коде, если мы реализовали аутентификацию и авторизацию на основе JWT?
в приложении весенней загрузки
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?
@utkarshsharma мы говорим не о злоумышленниках JWT, а о злоумышленниках CSRF. Предположим, пользователь X правильно вошел в ваше приложение через JWT в каком-то браузере, где у него есть соответствующий сеанс. Если приложение позволяет выполнять запросы и выполнять операции записи из действующего сеанса без защиты CSRF, тогда ваш пользователь может отправить запрос на выполнение таких операций записи, и сервер не сможет определить, действительно ли пользователь намеревался это сделать. Таким образом, если кто-то отправит пользователю X ссылку, которая должна выполнить запрос, о котором пользователь X не знает, он, тем не менее, будет выполнен в
@utkarshsharma браузер, в котором у пользователя X есть действительная сессия, и при условии отсутствия защиты от такой подделки запрос будет выполнен без ведома X об этом. Другими словами, предположим, что вы вошли в систему с помощью JWT, и ваше приложение позволяет выполнять операции записи без токенов CSRF. Если запрос GET или POST успешно инициируется от имени пользователя, у которого уже есть действующий сеанс, ваша аутентификация JWT не защитит вас от таких подделок, поэтому для предотвращения этого вам понадобится токен CSRF.
@utkarshsharma, так что 1. Вы входите в систему через JWT, у вас есть действительный сеанс, 2. Кто-то успешно запускает запрос от вашего имени в вашем браузере, где вы уже прошли аутентификацию. 3. Вредоносный запрос будет успешно выполнен, если ваше приложение не ожидает действительный токен CSRF.
браузер, в котором у пользователя X есть действительный сеанс, и, при условии, что нет защиты от такой подделки, запрос будет выполнен без того, чтобы X даже не знал об этом. Другими словами, предположим, что вы вошли в систему с помощью JWT, и ваше приложение позволяет выполнять операции записи без токенов CSRF. Если API, выполняющий операцию записи, требует JWT в заголовке. Как это позволит выполнить операцию записи без токена jwt?
@utkarshsharma вам обязательно понадобится токен CSRF. Если вы работаете с некоторым JWT, отправляемым в API, и он переопределяется каждый раз, когда вы запрашиваете API, тогда ваш JWT также работает как токен CSRF. Итак, ответьте, пожалуйста, на следующие вопросы: 1. Все ли ваши конфиденциальные операции отправляют JWT в ваш API? Если да, то получает ли он новый JWT от API при каждом таком запросе? 3. Является ли ваш API вашим IDP?
Требуется кому?