Защита от CSRF. Насколько правильный подход?

Наткнулся на CSRF и слегка озадачился это проблемой. Как правильнее организовать защиту от подмены запросов?
Почитав пару статей на эту тему, понял что лучший способ - отправлять вместе с запросом уникальных токен.
Так вот, пока есть такая схема:
При авторизации записывать пользователю в сессию уникальных токен. После чего на страницах требующих отправки запроса добавить в форму hidden поле и передавать через него тот самый токен. После чего, перед обработкой запроса проверять сам токен. Но каким образом его проверять, ибо читал, что проверка токена на isset - не есть хорошо.
  • Вопрос задан
  • 2203 просмотра
Решения вопроса 1
miraage
@miraage
Старый прогер
1) создаем токен
2) пишем в сессию
3) добавляем в нужные места во вьюхах. например, hidden-поля в формы или устанавливаем какой-нибудь заголовок, если запросы делаются через AJAX
4) при каждом POST/DELETE/PUT/PATCH запросах проверяем входной токен и токен в сессии. не совпали = пока.
Ответ написан
Пригласить эксперта
Ответы на вопрос 2
petermzg
@petermzg
Самый лучший программист
Так как взаимодействие с сервером идет запрос/ответ, то токены позволят только определить, что возможно была подмена. От самой подмены они не спасут.
К примеру вы реализовали:
1. На сервере сгенерировали и сохранили id сессии и токен.
2. Передали на клиент.
3. Клиент делает запрос к серверу и передает id сессии и токен
4. Вы проверяете значение id токена. Если корректен, то генерите новый и сохраняете.
5. Все возвращаете клиенту.

- А теперь пользователь пользовался сайтом и не закрыв сессию ушел. Злоумышленник просто продолжит пользоваться его сессией и токеном. Пока не придет не правильный токен - вы не узнаете.
- Еще проблема. Ушел запрос на сервер с верным токеном, но по какой-то причине не вернулся. Повтор запроса это уже не валидный токен. Также несколько ajax запросов одновременно. Опять не валидный. Проблемы и вам как разработчику, так и пользователю.
Ответ написан
При авторизации записывать пользователю в сессию уникальных токен.

в целом нормально, но лучше не привязывать создание токена к авторизации, т.к. CSRF может быть и до авторизации, например CSRF на саму авторизацию. Создавайте его непосредственно при создании сессии. При этом чтобы не хранить токен на сервере и не создавать в явном виде, можно генерировать его как хэш, например MD5(sessionid,secret) - где secret некий ключ, известный только вашему серверу, который в случае необходимости можно поменять. В остальном - да, используйте его как скрытое поле во всех формах или как заголовок в ajax-запросах. Но если используете как скрытое поле в формах - избегайте GET-запросов, т.к. это потенциально может привести к раскрытию токена через Referer.
Ответ написан
Комментировать
Ваш ответ на вопрос

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

Войти через центр авторизации
Похожие вопросы