Почему Microsoft Edge отправляет пустой http-referer при вызове метода POST/REDIRECT/GET, если URI запроса и ответа совпадают?
В настоящее время я работаю над проектом Django1.11, я развернул свое приложение, используя nginx со схемой "https". Я хочу отправить форму, но не хочу ее повторять, поэтому я использовал шаблон POST/REDIRECT/GET. Все работает нормально и, как и ожидалось, в Mozilla и Chrome, то есть для вызова POST/REDIRECT/GET отобразит соответствующую веб-страницу. При перезагрузке и повторной отправке та же форма выдаст 403 доступа, который, как и ожидалось, будет отклонен. Проблема возникает только при тестировании того же представления в браузере Microsoft EDGE. При вызове метода POST/REDITECT/GET он напрямую выбрасывает 403. Причина 403 - REASON_NO_REFERER. Microsoft Edge пересылает пустой HTTP-реферер при использовании паттерна POST/REDIRECT/GET.
Я нашел патч для этого:
добавлять <meta name="referrer" content="origin-when-cross-origin" /> в <head> HTML-шаблона, и теперь он отлично работает и для Edge. Но все же, не знаю, что не так с Edge, если я не добавлю этот метатег в заголовок. Кроме того, это вызывает какие-либо уязвимости безопасности?
Джанго объяснил, почему проверка реферера является обязательной.
Suppose a user visits http://example.com/
# An active network attacker (man-in-the-middle, MITM) sends a
# POST form that targets https://example.com/detonate-bomb/ and
# submits it via JavaScript.
#
# The attacker will need to provide a CSRF cookie and token, but
# that's no problem for a MITM and the session-independent
# secret we're using. So the MITM can circumvent the CSRF
# protection. This is true for any HTTP connection, but anyone
# using HTTPS expects better! For this reason, for
# https://example.com/ we need additional protection that treats
# http://example.com/ as completely untrusted. Under HTTPS,
# Barth et al. found that the Referer header is missing for
# same-domain requests in only about 0.2% of cases or less, so we can use strict Referer checking.
в таком случае, означает ли это, что добавление мета в HTML обязательно для подачи xyz-origin в HTTP-реферер? Если да, то вызывает ли это какие-либо уязвимости в безопасности для атаки Man-In-The-Middle, поскольку у злоумышленника также может быть http-referer?
Я плохо разбираюсь в сетях, поэтому, пожалуйста, поправьте меня, если что-то отсутствует или не так с моей стороны.
2 ответа
Существуют разные алгоритмы для разных политик реферера. Нам нужно выбрать тот, который подходит для наших требований. Есть какие-то дыры в надежности или безопасности. Но в моем случае я развертываю свое приложение по схеме HTTPS. Также я собираюсь связать мое другое приложение, которое также по схеме HTTPS. так что для моего требования "происхождение-когда-кросс-происхождение" не поможет мне, если я отправлю данные в мое другое приложение. Вот почему "no-referer-when-downgrade" подходит. Также эта политика реферера является политикой браузера по умолчанию.
Тэг meta referer работает с большинством браузеров для передачи информации о реферерах способом, определяемым пользователем. Трафик остается зашифрованным, и все преимущества использования HTTPS остаются в силе, но теперь вы можете передавать данные реферера на все веб-сайты, даже те, которые используют HTTP.
Источник при перекрестном происхождении: отправляет полный URL-адрес в качестве источника ссылки, если у цели есть та же схема, хост и порт (т. Е. Поддомен), независимо от того, используется ли это HTTP или HTTPS, при отправке справочной информации только для источника на внешние сайты.
Исходя из этого, я думаю, у вас не будет проблем с безопасностью.
Рекомендации:
(1) Тэг Meta Referrer: продвижение для SEO и Интернета
(2) SEO для сайтов HTTPS: следует ли реализовывать метареферальный тег?