CSRF Защита: Хешинг PHPSESSID достаточно?

Question

Просто интересно, требуется ли для хэширования PHPSESSID для всех форм или скриптов действий для защиты CSRF? Я понимаю, что это может быть получено, если пользователь находится в одной физической сети (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

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

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

Answer 2

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

Answer 3

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

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

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

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

Answer 4

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

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

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

Answer 5

Согласно Robust Defenses for Cross-Site Request Forgery by Barth, Jackson and Mitchell, кажется, что HMAC идентификатора сеанса является лучшим общим решением.

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