Проверяет ли реферер достаточно защиты от атаки CSRF?

Ответ 1

Кроме того, использование реферера не будет работать для пользователей, чьи браузеры (или корпоративные прокси) не отправляют рефереры.

Ответ 2

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

Хотя токены по-прежнему считаются наиболее безопасным вариантом, использование реферера часто намного проще, а также довольно безопасно. Обязательно посмотрите все PUT/POST/PATCH/DELETE-запросы и посчитайте это атакой, если реферер отсутствует или находится не в том домене. Очень немногие (если таковые имеются) прокси удаляют реферер для запросов такого типа.

См. также рекомендацию OWASP о проверке заголовка реферера в качестве защиты CSRF:

Checking The Referer Header

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

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

Есть также распространенные ошибки реализации с проверками реферера. За Например, если атака CSRF происходит из домена HTTPS, то реферер будет опущен. В этом случае отсутствие рефери должно быть считается атакой, когда запрос выполняет состояние менять. Также обратите внимание, что атакующий имеет ограниченное влияние на реферер. Например, если домен жертвы - "site.com", тогда злоумышленник использует эксплойт CSRF с сайта "site.com.attacker.com" которая может обмануть сломанную реализацию проверки реферера. XSS можно использовать обойти проверку реферера.

Ответ 3

Единственный правильный ответ: "Помимо прочего, использование реферера не будет работать для пользователей, чьи браузеры (или корпоративные прокси-серверы) не отправляют рефереры". Это, как говорится, очень необычно в наши дни. Все люди, которые говорят, что источники могут быть подделаны, полны этого. Вы не можете фальсифицировать реферер, если у вас нет другого контроля над браузером другого человека (XSS/Trojan/etc). Если вам нужны рефереры для использования приложения, они так же эффективны, как токены CSRF. Просто убедитесь, что вы на 100% уверены, что ваша проверка верна (например, если вы используете регулярное выражение, убедитесь, что вы проверяете с начала "^" реферера).

Ответ 4

no недостаточно, для злоумышленника очень легко сделать это. Для клиента, как вы просите, все, что должен сделать злоумышленник, это заставить пользователя щелкнуть ссылку, созданную им, с этого момента, игра над

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

Как вы упомянули в вопросе, токены являются нормой, когда дело доходит до предотвращения CSRF

Ответ 5

Следуйте норме: используйте токены.

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

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

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