Скопирует со страницы пользователя с помощью скрипта. И как может форма протухнуть, если токен не меняется?
ты путаешь два соседних, но таки разных понятия: кросс-сайтовый скриптинг XSS и кросс-сайтовый запрос CSRF. это два вектора атаки. --- Добавлено --- вот у тебя есть форум. давай-ка внери сюда свой скрипт чтобы стащить мой токен. --- Добавлено --- мы обсуждали токенЮ который не меняется в пределах пользовательской сессии, а не вообще никогда. --- Добавлено --- сессия кончается когда-то
Я надеюсь сюда скрипт внедрить непросто. Может мы все-же обсуждаем не токен, а секретный ключ, на основе которого генерируется токен?
Присоединяюсь, откуда скопирует? Как он отправит от нашего имени запрос со своего клиента? CSRF-атака работает не так. Он должен с этим токеном подготовить где-то ловушку типа картиночки с запросом вместо SRC, и тогда, когда мы ее откроем, мы пошлем от своего имени запрос с валидным токеном. Либо где-то на сайте, где я бываю, внедрить в форму, в которую я пишу, этот токен, и отослать, на самом деле, не то, что я ввел в форму, а некий иной запрос на атакуемый сайт. Вероятность события сия - околонулевая. Суть токена не в том, что он должен быть всегда всегда разный. Суть токена в том, что он должен просто быть. --- Добавлено --- Да, ты определенно не совсем понимаешь суть CSRF.
Помню было время, когда вконтакт, в далеком 2007 году, все управляющие запросы через геты принимал. Без какой-либо уникализации ссылок вообще. То есть вот тупо что у меня выпиливание страницы это ?action=delAccont, что у тебя Много тогда полегло... Тупо вот атакой через картиночку на посещаемых ресурсах.
Ага... Залогинется, скопирует токен, а потом выйдет из аккаунта и будет со своим же токеном запросы слать.
Будут. Токен нельзя убивать пока запрос с этим токеном не пришел. Т.е. На каждый запрос новый токен. Пришел запрос, видим токен ищем в списке токенов этот токен, убиваем его, генерируем новый). Может и сложно, но за то каждый запрос покрыт уникальным токеном. Вообще, я думаю. Одного токена на сессию хватает.. Я могу и ошибаться но кажется в OpenCart как раз один токен за всю сессию пользователя.
Меня аж передёргивает от этого названия Имел несчастье с ним познакомиться. Не CMS, а сплошная дырища. Не знаю, как обстоит дело с безопасностью в последней версии, но версия 2.1, так точно - ужос летящий на крыльях ночи. Голый движок, который был установлен на тестовый поддомен, уже через пять дней с легкостью пропустил sql-инъекцию и на всех страницах по текстам, можно было изучать арабский язык. Сделал проверку с помощью ZAP, так выдало целую простыню предупреждений разного уровня, в том числе и критические: Cross Site Scripting, SQL-инъекция и т.д..
уже каша в голове, по абстрагированию всевозможных вариантов, костылей, обходов. на 10 шагов дальше.. А что если пользователь зашел на редактирование своей учетки ( токен с генерировался ).. оставил вкладку... а на другом сайте кликнул ссылку на делете... но увы GET параметры мы не принимаем. Токен во форме запихан.. или кука не проститутка. ...
А одноразовый токен защищает еще и от случайного повторения одной и той же операции со стороны авторизованного клиента
А что это дает то? Звучит как десятикратное md5 ) Ещё раз. Мы ведь говорим о csrf-токене и в данном случае не имеет значения, генерируется он каждый раз или только на одну сессию. Алиса его не знает по определению, а если знает, то ей совершенно не важно, живет токен целый сеанс или умирает сразу. Ну, может чуть сложнее, но не сложнее принципиально. Короче, csrf-токен - это простой механизм защищающий от определенного вектора атаки, не нужно его усложнять и навешивать лишние функции ) Пример с другого конца: не нужно проверять пользовательский ввод на ключевые слова вроде SELECT или <script>. Не нужно удалять теги или кастовать хитрые регулярки. Нужно всегда и при любом раскладе экранировать пользовательский вывод. Всё. Точно так же как и блокировка submit после нажатия. Ровно с той же эффективностью )) p.s. Вон, Сурикат хорошо расписал потенциальные проблемы. Можно накидать ещё, но и этого хватит.
Один из вариантов: выдавать в начале два токена: один с коротким временем жизни (скажем час, полчаса) с ним и идет основная работа. Второй храним долго (зависит от сути проекта). Как первый протухает, шлем запрос на новую пару токенов используя второй.
Меня не покидает один вопрос - нужен ли вообще токен в таком случае? Если с другого домена можно послать GET запрос от лица пользователя, то и запросить токен тоже можно для последующих POST запросов.
По ходу, браузер --- Добавлено --- Да и способов можно придумать много, а я хочу лишь разобраться, как писа́л в начале, с резонностью использования того или иного способа: один токен на сессию или одноразовый.
хм... ну если ты отдаешь его по get-запросу, то таки да, можно. --- Добавлено --- Не, мы тут не про auth-токены говорим, а про csrf: случайная строка, которая хранится в сессии и отправляется с каждым запросом изменяющим состояние. Спор на тему: достаточно ли генерировать токен один раз на сессию или нужно создавать новый после каждого запроса (а то и пачку). хех... пачка токенов выдающихся каждому юзеру. Сурикат таки прав, ддос будет не долгим, да )
@Maputo, при чем тут GET-запросы не пойму. Суть же в том, чтобы защититься от потенциально опасных (POST, PUT, DELETE, etc), по которым может происходить изменение данных, например, в БД или загрузка файлов.