Недооцененная CSRF уязвимость!

7. karpov-ml, Нет, не поможет. Здесь visavi не через iframe подгружает. Нужен hash при отправке важных запросов.
Ganjar - однозначно молодец)

Хотя... от такого вида атак X-Frame-Options: DENY всё же защитит.

Эмм, немного недопонимаю, буду благодарен если кто-нибудь разъяснит.
Хэш авторизации, который хранится в куке, можно считать токеном?
Я при авторизации юзера выдаю ему засоленный хэш из его логина+id, записываю в куку.
То, что кука априори хранится на стороне клиента, по всей своей логике, спасти ситуацию не может, т.к. вредоносу по барабану как эта авторизация у меня хранится, главное чтобы сам сайт меня опознал.
Это так?
То есть, единственное решение - гонять юзера по сайту с дополнительным $_GET['token']?
Что то в роде "http://site.com/section/21/tokenvalue" ?

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

верно

То есть, единственное решение - гонять юзера по сайту с дополнительным $_GET['token']?

по всему не надо. Подставлять и проверять нужно только там, где действия пользователя нужно проверять. На том же ВК хеша нет на всех страницах. В формах достаточно подставить hidden поле с хэшем.

14. G_A_N_J_A_R, понял, спасибо за информацию, раньше даже не думал об этом

если кто то по глупости откроет сайт для кроссдоменного аякса, то и токены не спасут

Тогда возникает еще один момент: если злоумышленник узнает этот токен у конкретного пользователя, то его(пользователя) уже ничто не спасет, если он перешел по вредоносной ссылке. Вероятность конечно ничтожно мала, но тем не менее учитывать ее стоит. И как с ней бороться разработчикам - даже представить не могу.

А на стороне сервера нельзя разве каким либо образом заблокировать запросы с посторонних сайтов?

17. vlad6085, для каждой генерации страницы с формой создается свой токен.
даже если ты узнаешь токен из этой формы, он будет актуален только для твоей сессии с которой ты зашел на страницу с формой, у жертвы же сессия своя, и токена в ней не будет (или будет другой, если ты подсунешь ему незаметно страницу с этой формой)

17. vlad6085, Просто нужен не постоянный токин а сессионный, когда злоумышленник его получит он уже будет просрочен.

ну примерный алогритм токена - что то в таком роде, полагаю:

<?
$soil = '3#0sd7*+12G';
$token = md5(session_id().uniqid().$soil);
?>

и просрочен он будет при каждом обновлении страницы с токеном, за счет изменения uniqid()
записываем его в сессию ($_SESSION['token']), в hidden форму, после отправки формы, проверяем соответствие сессии и формы, удаляем сессию