Я забыл как защищаться от CSRF. Помню только, что в запросе, скрытым полем отправляется токен. А что дальше забыл. Напомните кто знает.
1) генеришь токен. 2) пишешь в сессию. 3) вставляешь его в скрытое поле в форму. 4) когда приходит форма, проверяешь, есть ли в ней токен, есть ли в сессии токен, совпадают ли они. Если нет, игноришь - пришедшие данные от имени этого пользователя были посланы откуда угодно, но не со страницы твоего сайта, сгенеренной твоим сервером конкретно для этого человека.
токен может генериться функцией от адреса и чего-то уникального для пользователя. можно еще время устаревания добавить. тогда не понадобится его хранить. Добавлено спустя 6 минут: другой вариант: генерить случайный токен, а в куку засовывать "подпись", зависящую от токена, адреса и секретного ключа. при проверке вычислять подпись заново и сравнивать с той, что в куке. на сервере кроме ключа ничего не хранится.
в wordpress используются т.н. nonce — теоретически эти токены должны быть одноразовыми. но использование ajax вносит свой геморой. приходится делать одноразовое многоразовым. вордпресовцы пошли на компромис, у них токен устаревает за несколько часов. таким образом они сокращают количество того, что необходимо хранить.
Спрошу здесь. Генерить токен и писать в сессию/куку явно не в шаблоне надо, а выносить в хэлперы. Не новое для меня слово, тем не менее я не знаю куда это надо выносить. Буду благодарен тому кто объяснить что такое хэлперы.
ХЗ. У меня вот просто есть функция API::get_token(); Я ее втыкаю в код, генерирующий форму в нужное место и доволен. Она сама скрытое поле сгенерит(опционально), и токен, и сама в сессию запишет данные. Потом, в критических местах вызывается функция API::check_token(), которая тоже сама все делает и возвращает true или false, в зависимости от того, сочла она запрос подлинным или поддельным. Кто тебе мешает сделать нечто подобное у себя? В итоге в шаблон выходят только вызовы.
если только в одном месте, то будет требоваться токен для загрузки любой страницы, в то время как требуется только защита записи (изменения).
конечно всё подряд не стоит, но не только изменение данных. user logout, например, может и должен защищаться от csrf. иначе кто-то может подсунуть тебе картинку с адресом выхода и давай досвидания ))) здесь токен может быть get-параметром. Добавлено спустя 4 минуты 32 секунды: посмотрите здесь на форуме: ссылки "Выход", "Подписаться на тему", "В закладки" прикрыты некими хешами. это оно и есть!
проверяет, есть ли в запросе токен с таким-то случайно сгенеренным именем, проверяет, есть ли в сессии переменная с таким именем, и совпадают ли их значения. Если да, при том, что ранее совпали фингерпринты все, то ок, запрос честный, возвращаем true. Это там происходит, где ты обрабатываешь запрос конкретный. Можно и на роутере, но тогда зачастую в холостую будут идти проверки даже тогда, когда они не нужны. А с Код (PHP): if (API::check_token()){ //code } можно быть уверенным, что там, где это важно, код обернут в защиту. Но это чисто мое имхо. Автор и любой другой может делать так, как сам считает нужным для себя и как считает возможным исходя из своей архитектуры. Добавлено спустя 1 минуту 4 секунды: Мое любимое развлечение, когда кто-то на форуме просит затестить его проект, натыканный кнопками в виде стилизованных УРЛов с чистыми гетами