Я прочитал много статей о защите CSRF ( это хороший ) и различные вопросы здесь, на SO, но ни один из них, похоже, недостаточно информативен для ответа на мой вопрос.
Я разрабатываю свою собственную CMS, и я хочу защитить свои формы входа и комментариев. Я позволю анонимным пользователям прокомментировать мой сайт.
Все формы на моем сайте защищены с помощью токенов. Я уже знаю об этом подходе, но проблема в том, что ему нужен активный сеанс (то есть после входа пользователя в систему). Проблема с форматами входа и комментариев заключается в том, что они доступны для всех и не требуют входа в систему – какая будет лучшая защита от CSRF в этом случае?
В приведенной выше ссылке я прочитал, что при попытке входа в систему, а затем приступить к обычным методам анти-CSRF (например, назначению токена сеансу пользователя), можно создать «предварительную сессию», не имеют представления о том, как добиться этого.
Заголовок referrer является слабым решением, поэтому я не должен беспокоиться. Заголовок Origin, насколько я уже протестировал, поддерживается только в Google Chrome. Как насчет пользовательских заголовков? XMLHTTPRequest похоже на возможность, однако я потратил буквально более трех часов на поиск Google некоторой информации о том, как реализовать такую меру безопасности на своем веб-сайте. Но даже если бы я мог использовать пользовательский заголовок, не делает его бесполезным, поскольку заголовки HTTP могут быть полностью фальшивыми?
Итак, вопрос: как я должен защищать свои формы входа и комментариев против CSRF?
Изменить: вот дополнительная информация из приведенной выше ссылки:
Мы рекомендуем строгое подтверждение Referer для защиты от входа в систему CSRF, поскольку формы входа обычно передаются через HTTPS, где заголовок Referer надежно присутствует для законных запросов. Если в запросе на вход пользователя отсутствует заголовок Referer, сайт должен отклонить запрос на защиту от вредоносного подавления.
а также
Секретные маркеры проверки могут защищаться от входа в систему CSRF, но разработчики часто забывают реализовать защиту, потому что перед входом в систему нет сеанса для привязки токена CSRF. Чтобы использовать секретные маркеры проверки для защиты от входа в систему CSRF, сайт должен сначала создать «presession», реализовать защиту CSRF на основе токенов, а затем перейти к реальному сеансу после успешной аутентификации.
Я просто не могу положить конец этому аргументу после прочтения приведенных выше цитат. Один из них упоминает использование заголовка referrer, но я не совсем уверен, действительно ли это добавляет к безопасности webapp.
Изменить 2: Как насчет использования CAPTCHA?