почему Microsoft Edge отправляет пустой http-referer при вызове метода POST / REDIRECT / GET, если URI запроса и ответа совпадают? - PullRequest
0 голосов
/ 04 февраля 2019

В настоящее время я работаю над проектом 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-реферер?Если да, то вызывает ли это какие-либо уязвимости в безопасности для атаки «Человек в середине», поскольку у злоумышленника может быть также http-referer?

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

Ответы [ 2 ]

0 голосов
/ 05 февраля 2019

Существуют разные алгоритмы для разных политик реферера.Нам нужно выбрать тот, который подходит для наших требований.Есть какие-то дыры в надежности или безопасности.Но в моем случае я развертываю свое приложение по схеме HTTPS.Также я собираюсь связать мое другое приложение, которое также по схеме HTTPS.так что для моего требования «происхождение-когда-кросс-происхождение» не поможет мне, если я отправлю данные в мое другое приложение.Вот почему «no-referer-when-downgrade» подходит.Также эта политика реферера является политикой браузера по умолчанию.

0 голосов
/ 05 февраля 2019

Тэг meta referer работает с большинством браузеров для передачи информации о реферерах способом, определяемым пользователем.Трафик остается зашифрованным, и все преимущества использования HTTPS остаются на месте, но теперь вы можете передавать данные реферера на все веб-сайты, даже те, которые используют HTTP.

Источник при перекрестном происхождении : отправкаполный URL-адрес в качестве источника ссылки, когда цель имеет одинаковую схему, хост и порт (т. е. поддомен), независимо от того, используется ли HTTP или HTTPS, при отправке справочной информации только для источника на внешние сайты.

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

Ссылки:

(1) Метареферальный тег: улучшение дляSEO и Интернет

(2) SEO для HTTPS-сайтов: следует ли реализовать мета-тег тегов реферера?

(3) https://www.w3.org/TR/referrer-policy/

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...