CSRF и постоянно меняющиеся токены - PullRequest
0 голосов
/ 24 февраля 2010

Я только что видел эпизод Doctype на CSRF.

В нем говорится, что лучшим предупреждением для CSRF является создание токена из некоторых пользовательских уникальных данных (например, хеширование идентификатора сеанса), а затем POST, которые вместе с вашим запросом.

Было бы менее безопасно генерировать трудно угадываемое значение (например, GUID) и сохранять его как переменную сеанса и помещать его на страницу как скрытое поле?

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

Мне кажется, это так же безопасно. Я не прав?

1 Ответ

5 голосов
/ 24 февраля 2010

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

Смена токена каждый запрос, возможно, более безопасен. Но штраф вполне может считаться слишком высоким. Как и почти все, что касается безопасности, вы часто сталкиваетесь с необходимостью компромисса с простотой взаимодействия с пользователем - найдите мне одного пользователя, которому нравятся CAPTCHA !. Поиск правильного баланса для вашего приложения и ваших пользователей важен как для вашей безопасности, так и для удобства использования.

В CSRF (и многом другом) есть хорошее чтение в Open Web Application Security Project

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

...