Приветствую! В очередной раз пробежался по инету в поисках правды по этому вопросу. В одних обсуждениях перевешивает точка зрения, что достаточно одного токена на сессию, в других - что токен нужно генерировать новый после каждого запроса. Уже сам запутался... Если сайт будет работать по SSL и обязательно нужна поддержка multi-tabs, то стоит ли заморачиваться с генерированием каждый раз нового токена или действительно одного на сеанс будет достаточно?
+ https://php.ru/forum/threads/66872/ --- Добавлено --- SSL разве относится к CSRF ? --- Добавлено --- Насколько понимаю защита доп не помешает, вдруг ЧУ
Только косвенно - защита от перехвата трафика. С этим никто не спорит, но не всегда же нужно идти на поводу программистской паранойи Ваш код я видел, но меня не столько реализация интересует, сколько определиться в направлении. Если, например, один токен - это очень слабая защита, то почему и как она может провалиться? (не берем в расчет шелы и прочие опасности). Если взять мой конкретный случай, то страница может быть открыта и час, и два и десть часов, поэтому ставить время "жизни" токена - не катит. Кроме того, страницы могут и будут открываться в разных вкладках и хранить кучу токенов, проверяя какой совпадает с токеном пришедшим в текущий момент - тоже какой-то бред. Поэтому лень диктует идти по пути наименьшего сопротивления и использовать один токен, но всё та же паранойя этому препятствует.
@Deonis, читал статью на хабре, где проверяли уяизвимость тех или иных сервисов. Так, у некоторых проверямых на каждый запрос новый токен, у некоторых один на одну сессию. Не ставь время жизни токена, просто генерируй его для каждого запроса)).
Если не про эту говорите, то не попадалась, но глянул бы. Я так надеялся, что скажут, мол послушай свою лень, одного токена с головой хватит... )))
SPA 1. Клиент делает запрос, сопровождает его токеном, ждет выполнения и получения нового токена. 2. Клиент делает ещё один запрос. Текущий токен уже протух на п.1, но новый пока ещё не получен. Как разруливать будем? )
"Кучка" в десятичной системе счисления - это сколько? )) Менеджер приходит в девять утра и сразу открывает сайт, а закрывает его часов в семь вечера. Кроме того, что он активно его использует, периодически (раз в 10 сек.) отправляются Ajax-запросы. Хотя, последний момент под вопросом, т.к. я пытаюсь убедить перебросить Ajax на WebSocket, но пока безуспешно. Но главная проблема - это то, что они, как я мог наблюдать, могут штук двадцать закладок открыть и тут уже "кучкой" не обойдешься.
@Deonis в процессе обмена данными, подкидывать новые токены. Вопрос же состоит в том, что в SPA приложении запрос может быть отправлен еще один до получения ответа на первый. Я делаю так - в каждом месте, где нужно использовать токен для защиты от CSRF, я дергаю функцию, которая генерирует случайный токен и пихает его в ссылку (форму) и в мемкеш. Когда приходит запрос, требующий защиты, я проверяю, передан ли с ним валидный токен. Если да - ОК, удаляю токен из мемкеша как использованный. Если нет - эррор. Недостатков в этой системе не нашел.
На практике под общим названием "CSRF token" используются настолько разные подходы, что можно было бы разные термины придумать. Как минимум, он должен быть уникален для данной пользовательской сессии. У WordPress, насколько знаю, токен по умолчанию действителен в течении получаса и может использоваться многократно, хотя в названии функций присутствует слово "nonce" — то есть "одноразовый" . Это сильно упрощает работу AJAX. А где-то токен применим только к конкретному запросу. Что выбрать, решать тебе. Почитай первоисточники чтобы знать матчасть лучше. https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet https://en.wikipedia.org/wiki/Cryptographic_nonce https://laravel.com/docs/5.5/csrf
Это асинхронные запросы? Если пользователю нужно отправлять несколько запросов с одной страницы - тогда запрос будет все равно один (одного типа) и токен просто не должен протухать до перезагрузки страницы. Но у меня возникает встречный вопрос - от чего защитит многоразовый токен?
используемый гандон будут еще использовать, да промоем пофиг, еще пойдет а мож еще друзей позвать, одним шариком для всех ?
На практике достаточно одного токена на сессию. Другое дело, что сессия должна быть сессией, а не запоминалкой входа на 5 лет вперед. Пилить новый токен на каждую форму нецелесообразно. 1) Даже если вопрос не о SPA, проблема, описанная @romach имеет место быть. Ну вот тупо пользователь открыл на сайте 5 страниц сразу. Ну вот я на форуме открыл 10 вкладок. В каждой есть кнопки. Они должны быть закрыты CSRF_защитой. Если на каждую новую страницу генерить новый токен, то на 9 из 10 у меня не будут работать кнопки и AJAX. Норм. 2) Окей, создаем новые токены и кладем в стопочку. Поздравляю, мы только что всему миру дали инструмент для DDOS-а нашего сервера ботом, которого можно на коленке поднять. Который будет молотить наш сайт и в одно рыло уложит сервер, но не перегрузкой очереди обработки запросов, а задрачиванием винта. Либо, если винт не SSD, он отожрет все его время, либо, если SSD, за N времени вычерпает дисковое пространство. А если мы храним токены в оперативке, то задача укладки сервера упрощается в разы. Достаточно загнать его в своп. Паранойя это ок, но надо руководствоваться здравым смыслом. CSRF-атаки стихийны. Никто не украдет ваш драгоценный CSRF-токен с тем, чтобы провести целенаправленную атаку на конкретного человека. Слишком замороченно. Если человек может украсть CSRF-токен, то, вероятно, имеет достаточный доступ к компьютеру жертвы, чтобы и без CSRF проводить атаку на него. Всякие вконтакты вообще практиковали (давно не проверял, мб поменялось уже) один токен на пользователя. Не на сессию На пользователя. И норм. Крч, я к чему - односессионного токена хватит всем. Однозапросный не имеет смысла и практической ценности.
по определению, токен должен защищать от поддельного запроса извне. он выдан в твоей сесии. кто-то другой, однажды совершавший те же действия, не сможет использовать свой токен чтобы выполнить действие от твоего лица.
@artoodetoo, с этим справляются сессии и без токенов. Токены для того, чтобы идентифицировать формы - то, что они были сгенерированы сервером. А коли везде один и тот же токен - он подойдет к любой форме.
Прям на каждой странице свой, или для каждой формы специфичный? Если первое, то весело Хотя Ксенфоро во многом странный движок. CSS, вот, в БД хранит... --- Добавлено --- Вы об одном и том же говорите, не?
Ну если штамп времени - то на одной странице должен быть один. Кстати второй параметр - это id пользователя. Я прав? Тут да. Об одном. Но далее расходимся.
@Maputo у нас форум написан ребятами из XenForo, что бы там ребята из ODware ни писали в подвале ))) это вопрос или утверждение? подозреваю, что там user_id, session_start_timestamp и собственно токен. --- Добавлено --- можно найти пиратские сорцы XenForo и покопаться в порохах. но лень --- Добавлено --- да, Фел. мы обсуждаем одну тему, как ни странно
@artoodetoo, если токен один - злоумышленник копирует его в свою форму и отправляет запрос на сервер - разве его что-то остановит? P.S.: ИМХО токены - это борьба с симптомами. Нужно избавляться от самой болезни - возможностью запуска сторонних скриптов.
а вообще местный токен похож на HMAC. присутствует открытый кусок данных, временная метка и подпись, сделанная с помощью закрытого ключа. вполне может служить в роли токена. --- Добавлено --- 1. скопирует откуда? 2. она протухает