Немного о токенах и CSRF

будет ли от CSRF защита вида token=secret
вместо принятой token = salt + ":" + MD5(salt + ":" + secret)

Ситуация, допустим, такая: при авторизации на сервере генерируется secret.
В каждую форму в виде чего угодно (допустим, в виде <input type="hidden" name="token" value="secret"/> ) дописывается это самый секрет.
Вопрос: будет ли обеспечена таким образом атака от CSRF?
Мои рассуждения: по мне, так да. Если сайт злоумышленника, на который зашла жертва, отправит запрос на наш сервер, то разницы между двумя токенами я не вижу: что token=secret, что token = salt + ":" + MD5(salt + ":" + secret) не возможно будет угадать.

Какие ваши рассуждения?

Что ты понимаешь под словом "авторизация"?

-----
Шта? Репозиторий?

ввод логина и пароля на стороне клиента, проверка на стороне сервера такого логина и такого пароля, инициация сессии.
+ запись в сессию secret

Т.е. на протяжении всего срока пока пользак залогинен в системе, секрет не изменяется?
В таком случае, нет, от CSRF не спасет.

-----
Шта? Репозиторий?

DeepVarvar
Как злоумышленник может узнать secret жертвы?

Защем ему узнавать? В его примере он всегда одинаковый.

-----
Шта? Репозиторий?

DeepVarvar,
Вы, уважаемый, сами себе противоречите.
Секрет генерируется при авторизации пользователя.
Да, пока пользователь залогинен, секрет остается неизменным. А вы как хотели?

andrewkard прав, утверждая, что злоумышленник не сможет узнать secret жертвы на протяжении всего срока его "залогиненности"

Находясь на том же хосте -- сможет.

-----
Шта? Репозиторий?

Зависит от того, как вы этот секрет создаете.
К примеру, если у вас что то вроде этого, то атакующий может сгенерировать такой же токен самостоятельно. Потому что ИД пользователя обычно не прячут. Он может присутствовать в URL.

$_SESSION['token'] = md5($user_id);

Если вы используете один и тот же токен на протяжении всей сессии, то его вообще никуда записывать не надо. Потому что ИД сессии по сути и есть то что вам нужно. Соль и хэширование здесь используются, я думаю, по тем же причинам что при хранении паролей (хэшей). Если сессии или хотя бы идентификаторы сессий "утекли" с вашего сервера, то хэширование токенов с солью поможет избежать CSRF.

Простой пример:

[quote=Ch_chov]Зависит от того, как вы этот секрет создаете. [/quot]
полный рандом (случайным образом)

Используешь хардварный генератор с получением энтропии из окружающей среды?

-----
Шта? Репозиторий?

прямо в точку

Вобщем я так понял -- ты оставляешь дырень с статичным секретом, да?

-----
Шта? Репозиторий?

Для CSRF достаточно. Если под secert подразумевается секрет пользователя, а не приложения.

Хотя можно поступить в какой-то мере еще проще и создавать токен как hash от клиентской информации (ip, юзер-агент и т.п.) + какой-то фиксированный секрет приложения. И хранить в сессии ничего не нужно будет.

-----
self-banned

нет смысла изощряться в генерации сверх криптостойкого токена цсрф ибо смысл использовать его всего один раз

если у вас проблемы с этим, то похоже что вы не понимаете смысла цсрф и его особенностей использования

-----
Just do it