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

Question

[alestro]

Наткнулся на CSRF и слегка озадачился это проблемой. Как правильнее организовать защиту от подмены запросов?
Почитав пару статей на эту тему, понял что лучший способ - отправлять вместе с запросом уникальных токен.
Так вот, пока есть такая схема:
При авторизации записывать пользователю в сессию уникальных токен. После чего на страницах требующих отправки запроса добавить в форму hidden поле и передавать через него тот самый токен. После чего, перед обработкой запроса проверять сам токен. Но каким образом его проверять, ибо читал, что проверка токена на isset - не есть хорошо.

Answer 1

[Mikhail Osher]

1) создаем токен
2) пишем в сессию
3) добавляем в нужные места во вьюхах. например, hidden-поля в формы или устанавливаем какой-нибудь заголовок, если запросы делаются через AJAX
4) при каждом POST/DELETE/PUT/PATCH запросах проверяем входной токен и токен в сессии. не совпали = пока.

Comments

[Виталий Хоменко]

Правильно ли я понимаю, что вы предлагаете накапливать список сгенерированных токенов в сессии? То есть если на странице формы нажимать F5 много раз, то при каждом отображении формы будет добавляться доп. токен в сессию?

Я хочу лишь уточнить момент, и все.

[Mikhail Osher]

Виталий IIIFX Хоменко: он один раз генерится на каждого юзера.

Answer 2

[Петр]

Так как взаимодействие с сервером идет запрос/ответ, то токены позволят только определить, что возможно была подмена. От самой подмены они не спасут.
К примеру вы реализовали:
1. На сервере сгенерировали и сохранили id сессии и токен.
2. Передали на клиент.
3. Клиент делает запрос к серверу и передает id сессии и токен
4. Вы проверяете значение id токена. Если корректен, то генерите новый и сохраняете.
5. Все возвращаете клиенту.

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

Comments

[alestro]

И как быть в итоге?

[Петр]

alestro: Не париться во этому поводу ))

[Юрий]

Петр: разные токены на одну сессию, конечно ничего хорошего. на одну сессию - один токен (и естественно не в куках). иначе юзер откроет 2 вкладки и уже начнутся проблемы.

либо по вашей схеме токены на серваке не хранятся, но все запросы подписываются, то есть все ссылки и формы с уникальным кодом - сигнатурой (делал в одном проекте)

[Петр]

Вячеслав Юрьевич: Так и пройдутся по вашему сдвигу.

[Петр]

Юрий: Если несколько токенов, то какой смысл в них, сессии достаточно. И чем вам куки не угодили, даже если они в нескольких вкладках открыты (не в режиме ананомности), то кука будет одна на эти вкладки.

[Юрий]

Петр: в том если токен в куках - толку от него абсолютный 0. это никак не помешает злоумышленникам вызвать метод на вашем сайте с другого сайта в браузере пользователя.

[Петр]

Юрий: А какие есть варианты? Это веб тут только: в параметрах GET запроса, в теле POST запроса, в хедере запроса, в куках. Или куда еще вы спрятать можете? WebSocket так это другой канал передачи данных. Все это легко копируется.

[Юрий]

самое главное, токен не сохраняется на клиенте, а только вставляется в html. то есть доп скрытые параметры в формы, гет параметры для аякса так же js берет их кода html .
проблем нет.
единственная проблема кто-то на это забивает, а кто-то забывает

[Петр]

Юрий: Эээ? Не сохраняется на клиенте? Вставляется в html? Клиент это и есть программа по отображению html, т.е. браузер. )))

[Юрий]

Петр: браузер отображает html, при чем тут сохранение?

хотя у меня формулировка неправильная. просто в куках нельзя, иначе чем этот токен отличается от сессионнной куки? которая при csrf не спасает...

[xfg]

Юрий: вы безусловно правы. Но можно еще токен сохранять не в сессии, а в куке. На сервере ожидать, что токен придет в заголовке/теле и сравнивать его с тем, что в куке. Это позволит и анонимных пользователей защитить от csrf.

[Юрий]

xfg: в таком виде да, поможет

Answer 3

[Владимир Дубровин]

При авторизации записывать пользователю в сессию уникальных токен.

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