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

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

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

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

Проверять Заголовок Referer

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

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

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

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

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

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

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

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

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

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

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