Защита от CSRF: достаточно ли хэшированного PHPSESSID?

Question

Просто интересно, достаточно ли для защиты CSRF необходимости отправки хэшированного PHPSESSID во все формы или сценарии действий?Я понимаю, что это может быть получено, если пользователь находится в одной физической сети (firesheep).Пример:

http://site.com/deleteMessage.php?mid=22&token=MD5ed_PHPSESSID

Не учитывая ту же проблему с сетью, PHPSESSID:

 1) Is known only to the user doing the action
 2) Can not be guessed by an attacker crafting a malicious img or request (<img src="http://site.com/deleteMessage.php?mid=22&token=I_DONT_KNOW_IT_:( )
 3) Can not be pulled on the same site assuming no XSS vulnerabilities exist.
 4) Can easily be pulled by the legitimate user (Javascript fills the form or GET var in the link)

Номер 3 беспокоит меня, хотя у меня нет никаких уязвимостей XSS, которые яМне известно, что, поскольку я htmlentities ($ string, ENT_QUOTES) редактировал все, я не люблю полагаться на предположения.Это достаточная защита CSRF или есть лучший способ?

Answer 1

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

XSS нарушает все методы защиты на Шпаргалке по профилактике CSRF , за исключением использования capthca.При этом вы должны защитить свой идентификатор сеанса от XSS, используя флаг cookie HTTP_Only.

Имейте в виду, что флаг HTTP_only НЕ ПРЕДОТВРАЩАЕТ XSS! , это только усложняет задачу.использовать.Часто злоумышленник прибегает к использованию XHR для считывания токена CSRF, чтобы «прокатиться» по сеансу, а не перехватывает идентификатор сеанса.

Answer 2

Согласно Надежной защите для подделки межсайтовых запросов Бартом, Джексоном и Митчеллом кажется, что HMAC идентификатора сеанса является лучшим универсальным решением.

Согласно этому документу сеансНезависимый одноразовый номер, который не соответствует идентификатору сеанса в хранилище состояния сервера, уязвим для активных сетевых атак даже при использовании TLS / SSL / HTTPS.HMAC идентификатора сеанса не имеет подобной уязвимости.Независимый от сеанса одноразовый номер разрешен, если вы сопоставляете одноразовый номер с идентификатором сеанса на сервере вместо того, чтобы сопоставлять параметры POST с заголовком Cookie.

Answer 3

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

Регенерируйте это случайное значение каждый раз, когда отображается форма.

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

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

Answer 4

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

Просто используйте случайный токен, как все предлагают.

Answer 5

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