#flask #redis #csrf
#flask #redis #csrf
Вопрос:
CSRF, который расшифровывается как подделка межсайтового запроса, представляет собой атаку на веб-приложение, в котором злоумышленник пытается обмануть аутентифицированного пользователя для выполнения вредоносного действия. Большинство CSRF-атак нацелены на веб-приложения, использующие аутентификацию на основе файлов cookie, поскольку веб-браузеры включают все файлы cookie, связанные с конкретным доменом, с каждым запросом. Таким образом, когда вредоносный запрос выполняется из того же браузера, злоумышленник может легко использовать сохраненные файлы cookie.
Я решил использовать Flask-Session, который представляет собой расширение Flask, которое позволяет просто интегрировать серверный кэш, сохраняя данные сеанса пользователя на сервере.
Достаточно ли использовать это расширение (сохранение сеанса пользователя в redis) для предотвращения CSRF-атак?
Комментарии:
1. Нет, это не так, это не то, что делает CSRF.
2. Спасибо за ваш ответ @MartijnPieters. Я действительно ценю.
3. Обратите внимание, что на самом деле это не относится к Flask. CSRF заставляет пользователя делать запрос, который они не хотели делать, на сервер. Сервер предполагает, что они разговаривают с законным пользователем и что запрос был преднамеренным . Допустим, вы используете сеанс для идентификации пользователя, вошедшего в систему на веб-сайте банка. Если злоумышленник может обмануть пользователя, чтобы перевести деньги на другой счет, не имеет значения, где хранятся данные сеанса.
4. Например, злоумышленник может отправить изображение в электронном письме в формате HTML, но ссылка на изображение на самом деле является ссылкой на веб-сайт банка. Если пользователь уже зарегистрировался на сайте банка и поэтому отправляет файл cookie из браузера на сайт, расширение Flask-Session по- прежнему использует этот файл cookie для идентификации загружаемых данных в Redis . Запрос, похоже, исходит от пользователя, независимо от того.
5. Защита от CSRF использует дополнительные данные на веб -странице, которые должны соответствовать информации, прикрепленной к учетной записи пользователя, которая недоступна за пределами страницы браузера и меняется каждый раз, когда вы загружаете страницу, которая может инициировать конфиденциальные запросы. Таким образом, сервер, по крайней мере, знает, что запрос поступил с определенной страницы браузера, которая была только что отправлена пользователю первой. Внешний злоумышленник не может получить это значение контрольной суммы CSRF, поэтому трюк с изображением ссылки в электронной почте не сработает, потому что контрольная сумма CSRF отсутствует или неверна.
Ответ №1:
Нет, Flask-Session не защищает от CSRF-атак, поскольку CSRF-атаки не полагаются на аутентификацию сеанса, они полагаются на уже существующее соединение между браузером и вашим сайтом. Flask-Session не удаляет соединение между браузером пользователя и данными вашего сеанса, только там, где хранятся данные сеанса, связанные с пользователем.
Все, что позволяет Flask-сессия, это скрыть информацию, которую вы связываете с данным пользователем, от посторонних глаз. Но вам все равно нужно будет уметь различать пользователя A и пользователя B, поэтому в браузере все еще есть файл cookie, который сообщает вашему серверу Flask, какие данные загружать из Redis для этого пользователя. Без Flask-Session любые данные сеанса хранятся в браузере, с Flask-Session браузеру присваивается только уникальный идентификатор.
CSRF-атакам не нужно знать, что хранится в сеансе, только то, что сеанс существует. Атака CSRF срабатывает, когда:
- Пользователя можно обмануть, заставив отправить запрос на сайт, чтобы сделать что-то, что выгодно злоумышленнику
- Пользователь уже зарегистрировался на сайте, поэтому сайт видит запрос на выполнение желаемого действия, отправляемый от клиента, который уже прошел проверку подлинности.
Вы смягчаете атаки CSRF, требуя, чтобы каждый запрос, который делает что-то ценное, сопровождался секретным токеном CSRF, который не сохраняется в сеансе. Браузеру не должно быть разрешено сохранять значения CSRF, поэтому он никогда не будет использовать токен CSRF позже. Вместо этого вы помещаете токен в HTML страницы или в другие заголовки запросов и ответов. Таким образом, сервер не только может быть уверен, что у них есть аутентифицированный пользователь, но и что запрос является свежим и не был сгенерирован злоумышленником без доступа к браузеру.
Если вы создаете формы с помощью WTForm, используйте функциональность Flask-WTF CSRF, чтобы убедиться, что запрос поступил с новой веб-страницы. Вы даже можете использовать их API, когда не используете формы, например, при использовании вызовов AJAX или созданных вручную форм.
Возможно, вы захотите ознакомиться со страницей предотвращения CSRF OWASP, чтобы лучше понять, как работают CSRF-атаки.