Задать вопрос

Можно для тех кто в танке про CSRF?

Я ознакомился с https://habrahabr.ru/post/235247/ и другими статьями на ресурсах поменьше.
Сейчас у меня куки ставятся на 1 час в них кроме имени куки ничего не хранится, в сессии хранится email, id и сама сессия нигде не хранится (кроме temp сервера разумеется).

Если я правильно понял то:
1. Юзер авторизуется, при авторизации генерим ему токен и кладём в сессию
2. В любой форме есть скрытое поле token которое заполняется без ведома юзера данными из сессии
3. Но во время приёма данных формы из формы пришедший token надо как-то сравнить с оригиналом, иначе можно отправить любой и всё это обессмыслено. Выходит что бы был оригинал в пункте 1 token надо записать не только в сессию но в БД из которой при каждой проверке извлекать для сравнения.
А обновлять в БД его при каждой авторизации...
4. Get-запросы токенами защитить невозможно
Всё так или я что-то упустил?
  • Вопрос задан
  • 640 просмотров
Подписаться 4 Оценить Комментировать
Решения вопроса 3
@xfg
4. Get-запросы токенами защитить невозможно

Возможно, но не нужно. Вам не следует выполнять никаких действий, кроме отдачи контента по get запросу. Для update/delete/create нужно использовать POST если это классический веб-сайт и PUT/DELETE/POST если это RESTful API.

Пусть клиент отправляет csrf-токен в POST запросе. Пусть сервер при старте сессии сохраняет csrf-токен в сессию. Пусть сервер перед тем как выполнить POST запрос проверит соответствие токена из запроса с тем, что в сессии.

В базе данных токен хранить избыточно. Сохранив в сессию, вы всегда будете иметь к нему доступ, клиент его изменить никак не сможет.
Ответ написан
VGrabko
@VGrabko
Golang, Php, Js
1) создаем токен
2) пишем в сессию
3) добавляем в нужные места во вьюхах. например, hidden-поля в формы или устанавливаем какой-нибудь заголовок, если запросы делаются через AJAX
4) при каждом POST/DELETE/PUT/PATCH запросах проверяем входной токен и токен в сессии. не совпали = пока.
Ответ написан
Комментировать
Суть CSRF атаки в получении злоумышленником данных, которые позволят ему выдавать себя за другого человека. И все, что необходимо сделать для защиты, это генерировать при каждом запросе уникальный токен, естественно, с записью в базу или в текущую сессию, и при выполнении любого запроса сверять полученный токен и заменять его. Из этого следует, что токен нужно менять при каждом действии пользователя, а не только при каждой авторизации.

Время хранения кук тут роли никакой не играет. Нажмет пользователь "запомнить меня", а вы установите ему куку на час?

Собственно, тут все довольно прозрачно, на мой взгляд. Возможно, я тоже чего-то упустил, в таком случае буду рад поправкам.

Get-запросы токенами защитить невозможно

Почему? Посылаете в get токен параметром, на сервере проверяете.
Ответ написан
Пригласить эксперта
Ответы на вопрос 2
artem90
@artem90
TeamLead, Developer
Посмотрите в сторону готовых решений, наподобии этого:
https://github.com/BKcore/NoCSRF

Если хотите разобраться, как это все работает, можно расковырять код этой библиотеки
Ответ написан
Должны быть готовые решения, гляньте как там реализовано, типа asp mvc. В гет лучше ничего не пихать и вообще им лучше не пользоваться ао многих местах. Если нет сессии, почему вообще встал вопрос об этой уязвимости? Сессия не хранится-это как? Токен должен соответствовать сессии и например пути.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

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