Всем привет. Никак не могу разобраться в том, как токен спасает от CSRF атак. Кто нить может объяснить?)

если я правильно понимаю: если токен неверен (или отсутствует, просрочен, уже использован ранее) действие будет отвергнуто сервером, таким образом поиск XSS-уязвимости осложняется.

Понятно. Я правильно понимаю, что для использование CSRF атаки злоумышленник должен получить id сессии пользователя?

тут фокус в другом. Опишу XSS, как я ее себе представляю.
Допустим, есть некий web-сервер, который позволяет производить чтение/запись/изменение/удаление записей. Чтение записи (example.com/articles/read/15, где 15 - это ID записи, вполне типичный урл роутера джанго, верно?) не требует каких-либо специфических разрешений, запись/изменение (example.com/articles/update/15) используют метод POST, а вот удаление (example.com/articles/delete/15) записи производится через GET-запрос с указанием ID записи в строке URL, которую нужно удалить.
Допустим, злоумышленник знает, этот механизм работы с записями. Злоумышленник оставляет запись в каком-нибудь месте(да хоть в собственной подписи на форуме), куда ходит администратор, наделенный полномочиями удалять записи, скажем тег <img src="http://example.com/articles/delete/15">. Браузер жертвы попытается перейти по указанному урлу в поисках картинки. Допустим, жертва залогинена на своем сайте (что-то много допущений, да). сервер подхватит куки браузера и будет считать, что жертва хочет удалить запись с ID=15, и удалит ее. Вот как-то вот так.
Сам такое не пробовал, возможно я неправ. Если кто знает точнее, просьба опровергнуть.

Получается CSRF атака будет отличаться от XSS тем, что например в тег <img> вставлен url, а не javascript код? А токен спасает тем, что пока юзер не перейдет на страницу формы, перед отправкой запроса и не получит токен, запрос не будет выполнен? Что-то на самом деле много допущений получается)

> Получается CSRF атака будет отличаться от XSS тем, что например в тег <img> вставлен url, а не javascript код?
Именно, цель CSRF - заставить жертву перейти по вредоносному (для жертвы) урлу и осуществить там некие действия от имени жертвы.

> А токен спасает тем, что пока юзер не перейдет на страницу формы, перед отправкой запроса и не получит токен, запрос не будет выполнен?
жертва-то по урлу перейдет, но, поскольку токен на действие был не выдан предварительно(т.е., он неверен), то сервер такое действие пошлет лесом.

> Что-то на самом деле много допущений получается)
Не много на самом деле. Допустим (хм, мда) есть админ блога, где удаление записей уязвимо для CSRF. В каментах можно запостить картинку с указанным выше урлом и провокационным коментарием. Админ полез в админку удалить коментарий и… удалил запись в своем-же блоге.

Ну, в википедии даже яснее расписано, чем я тут рассказываю :)

Ну более менее понятно) спасибо) просто раньше думал что во время CSRF крадется id сессии. а в википедии сбивала фраза “Если жертва заходит на сайт, созданный злоумышленником, от её лица тайно отправляется запрос на другой сервер (например, на сервер платёжной системы), ” просто если жертва зашла на сайт злоумышленника, что мешает злоумышленнику запустить javascript код в браузере жертвы? только отключенный javascript. Отсюда делал вывод, что в этом случае xss эксплуатируется намного проще чем csrf и не понимал почему тогда такая шумиха вокруг csrf…