Я использую фильтр [ValidateAntiForgeryToken] с солью для предотвращения атак CSRF. У Сандерсона прочитал, что если хотите защищать формы, например, независимо, то для каждой формы свою соль надо написать. При этом для соли у него подходило и название формы (например, "loginForm"). Но тогда получается, что у всех пользователей после залогинивания будет одинаковый куки-набор. Т. е. по идее подобрать можно, даже не имея возможности прочитать куки, а уж если возможность есть...

Сдаётся мне, что Сандерсон недоговаривает, и соль надо генерить каждый раз разную (для каждой формы для каждого обращения каждого пользователя). Не то, чтобы они обязательно не повторялись, а хотя бы чтобы просто не была одна и та же всё время.

Кто что на это скажет? И ещё насчёт генерации соли - пойдёт ли в качестве соли текущая дата со временем? Гарантированно каждый раз разная будет соль.

авторПредлагаю такой вариант:
1. генеришь hash на основе куков (например: md5('cookie1=value1&cookie2=value2&sk+' +secretkey + userIP)) и пишешь его в кукисы же ) (или куда душе хочется)
2. при запросе пользователем страницы - проверяешь ранее сгенеренный hash со сгенеренным хешем на основе полученных кукисов, и если не совпадают - идет лесом пользователь
[ValidateAntiForgeryToken] это и делает (только надо соответствующую функцию генерации куки Html.AntiForgeryToken использовать). Насчёт алгоритма генерации, правда, не уверен, но как-то он это генерирует.

Разница между вашим и встроенным в .NET для меня в том, что у вас секретный ключ присутствует, а у Html.AntiForgeryToken явно ничего такого не просматривается, кроме какой-то соли. В МСДНе просто пишут, что эта функция и её фильтр обеспечат защиту от подделки серверного запроса.

SanSYSЕсли ты в куках хранишь мегаважную инфу, которую легко подделать, то действительно стоит заморачиваться с "солью"
Дата со временем тут как-то не к месту, имхо
А что тогда к месту? Что подойдёт?



Вообще, меня всё же ПОКА интересует не ваш алгоритм, а то, что у Сандерсона написано и в МСДНе. И конкретно - соль. Сандерсон пишет, что разным начальным значениям соответствуют разные противоподделочные маркеры. Ну тогда получается, что одинаковым значениям будут соответствовать одинаковые маркеры. Неясно только, будет ли маркер разный, если разные айпи пользователей будут и разные айдишники их. По идее, должны быть разными. Ну вот, чтобы гарантировать разность маркеров независимо от того, как там внутри .NET'а генерируется маркер, я просто думаю генерировать на каждый запрос свою соль.

Тут ещё вопрос - что по вашему алгоритму, что по сандеровскому - где хранить сгенеренные хеши, с которыми сверять пользовательские. По идее, они должны вычисляться при каждом POST запросе, а не храниться где-нибудь. Храниться должен только ключ.




...А-а-а, погодите! Там вот же какая штука. Маркер (хеш - как угодно назовите) создаётся функцией Html.AntiForgeryToken при запросе GET в форме, а проверяется фильтром [ValidateAntiForgeryToken] при запросе POST. Т. е. если бы была разная соль на каждую пару запросов GET-POST, то пришлось бы как-то её передавать от функции генерации к фильтру. Т. е. пришлось бы где-то хранить. А это накладно. Значит, только вычислять и только постоянная соль.

Прокомментируйте, если кто разбирается - я правильно понял в этом последнем абзаце?

авторТ. е. если бы была разная соль на каждую пару запросов GET-POST, то пришлось бы как-то её передавать от функции генерации к фильтру.
Имеется ввиду, что внутри пары этих запросов соль постоянна, а между разными парами (хоть даже одного пользователя и содного айпи) - разная.

spuser7320,

Токен это любая случайно-сгенерированная последовательность хранящаяся в сессии юзера и форме при их несовпадении - юзера посылают
Не нужен там никакой хэш и никакие шаманства - подойдет даже простой GUID
Это если злоумышленник не может прочитать куки или где там этот токен хранится. А если может, то надо бы предусмотреть такой механизм, который бы:

1) на каждый запрос каждого пользователя создавал бы новый токен;
2) при этом сервер мог бы вычислить (или запомнить) этот токен в любое время (или с некоторым "интервалом устаревания"), чтобы сравнить с тем, что в ответе от пользователя в куках пришло.

Это гарантирует, что каждый токен будет использоваться только один раз. По токену на запрос. А также то, что правильный токен сможет сгенерировать только сервер, а то, что попытается сгенерировать (или скопировать старый токен) злоумышленник, свереру будет незнакомо и он такого пользователя отправит. Т. е. сам межсайтовый скриптинг обессмыслится, ибо перехват токенов будет бесполезен - они будут устаревать за один запрос.

Но это уже, по-моему, попахивает шифрованием и сертификатами. Да и говорят, что если исключить возможность чтения куков злоумышленником, то токены можно оставлять одинаковыми (т. е. создавать по одной и той же соли).


Всё же, мне непонятно, эти токены (которые генерятся функцией Html.AntiForgeryToken) хотя бы для разных пользователей разные? Ну т. е. они изменяются в зависимости от айпи, айди и прочих параметров пользователя? И соль нужна только для того, чтобы сделать разные токены для разных форм даже для одного и того же юзера.

авторЭто если злоумышленник не может прочитать куки или где там этот токен хранится. А если может, то надо бы предусмотреть такой механизм, который бы:

1) на каждый запрос каждого пользователя создавал бы новый токен;
2) при этом сервер мог бы вычислить (или запомнить) этот токен в любое время (или с некоторым "интервалом устаревания"), чтобы сравнить с тем, что в ответе от пользователя в куках пришло.
То, что SanSYS предложил, не соответствует этому. Да и Html.AntiForgeryToken тоже. Потому что токены будут одинаковы у одного и того же юзера. Т. е. раз узнал его токен и гадь, пока серверная сторона алгоритм генерации токена не сменит. Если бы алгоритм менялся на каждом запросе, то перехват токена был бы бесполезен.

Я слышал о таком половинчатом варианте. В хеш этого токена зашивается время его устаревания - т. е. всегда токен будет разный, т. к. каждый запрос приходит в разное время (и устаревание, соответственно, каждый раз на разное время назначается). Когда серверу приходит POST-запрос от юзера, сервер вычисляет снова этот хеш, и если расшифрованное время устаревания меньше текущего времени, то запрос отклоняется.

Такой механизм у меня на подтверждении почты стоит. Почему бы его не использовать в противоподделачных токенах? Только время устаревания сделать минут на десять, а не на час, как у меня на почте стоит. Т. е. если юзер отправил GET на форму, а потом промедлил и POST с формой отправил позже, чем через десять минут, то надо снова форму заполнять. В этом случае перехват токена будет работать только в течении 10 минут. Согласитесь, за такое время надо ещё суметь воспользоваться ситуацией и тут уже скорее конкретный подкоп под конкретного юзера будет со сниффером и прочим, а не тупой CSRF.

авторТ. е. раз узнал его токен из куков и гадь
Я, конечно, поработал над устранением XSS, но на всякий случай...

spuser7320,

Вы не правильно понимаете защиту на основе токенов - каждый раз когда юзеру отдается страница - генерится новый токен который пишется в форму в хидден-поле и в сессию на сервере
Когда юзер сабмитит форму - производится сравнение этих токенов и только при совпадении выполнется действие над данными
Смысл в то что если враг украл токен, то есть надежда что пока он с украденным токеном добежит к сибе в пиндостан чтобы начать колдовать с токеном - наш юзер или обновит форму(т.е опять получит новый токен) либо завершит действие с ней

Шифровать токен - это как масло маслянное)))
Генерится новый токен? А меня смутила фраза, что если соль одинаковая (а если она статично забивается, то она одинаковая), то токен тоже всегда одинаковый.


Для остальных. Эти токены не для борьбы со снифферами и прочими взломщиками, а только против XSS и CSRF.