сгенерированный клиентом двойной файл cookie, предотвращение подделки межсайтовых запросов - PullRequest
1 голос
/ 01 апреля 2010

в схеме предотвращения двойного представления файлов cookie csrf, необходимо ли серверу предоставлять файл cookie?

кажется, что я мог бы создать на странице клиентов javascript и установить cookie "anti_csrf", а затем дважды передать его (один раз как cookie, сделанный браузером, и один раз в теле запроса).

чужой домен не сможет прочитать или записать cookie «anti_csrf», чтобы включить его в тело запроса.

это безопасно, или я что-то пропускаю?

Ответы [ 3 ]

1 голос
/ 19 октября 2010

Tgr, прочитайте это:

http://jazzy.id.au/default/2010/09/20/cracking_random_number_generators_part_1.html

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

0 голосов
/ 08 мая 2010

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

0 голосов
/ 01 апреля 2010

Если у пользователя уже есть cookie-файл «anti_csrf» для вашего домена, то злоумышленник CSRF остается дома бесплатно! HTTP-запрос отправляется с cookie, и, конечно, легко включить параметр в POST, если вы знаете, каково значение.

Файл cookie name не должен быть секретом, но значение cookie должно быть трудно угадываемым секретом, известным только пользовательскому сеансу. Таким образом, злоумышленник не знает (и не может угадать), что нужно поместить в атакующую HTTP-транзакцию.

Если вы разместите код на странице, которая составляет значение cookie, вы должны предположить, что злоумышленник может получить собственный сеанс на вашем сайте (то есть действительный «реальный» логин) и проверить код напрямую. Если легко выяснить, как значение cookie генерируется на стороне клиента (и для почти любого решения на стороне клиента, известного человеку, так и будет), то злоумышленник снова может заставить свою страницу атакующего включить правильное значение параметра в ПОСТ АКТА.

...