Pull to refresh

Comments 9

Вместо непосредственного выполнения нашего запроса POST, который потенциально может вызвать серьезные проблемы на сервере, браузер отправил запрос «предварительной проверки». Это не что иное, как запрос OPTIONS к серверу с просьбой проверить, разрешено ли наше происхождение. В этом случае сервер не ответил положительно, поэтому браузер останавливает процесс, и наш запрос POST никогда не достигает цели.

Поделитесь, пожалуйста, опытом кто как решал проблему, чтоб сервер ответил положительно на «проверочный» запрос OPTIONS, и чтобы потом все последующие кроссдоменные POST-ы уходили нормально. При этом запросы «сложные», т.е. Content-type: 'application/json'.
Спасибо.
Я не компетентен в этом. Знаю лишь то, что на той стороне nginx+php+symfony.

Заголовки-то мы настроили, json гоняется туда сюда. Но вот как-то «костыльно» выглядит. В дев-консоли все post-запросы отображаются как OPTIONS, и тело запроса/ответа не видно. Зато плюс к секьюрности..)))
Ну Гугл как обычно. Теперь целью стал HPKP. Они системно борются с любыми вещами, которые связаны с реальной безопасностью между пользователями и сайтами. Но активно пропихивают любые решения с 3-й стороной. Всё по заветам «верьте нам».

P.S. Хотя вроде для себя любимых аналог HPKP в Хроме сделали.

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

С одной стороны это конечно так. А с другой пропихивать тотже QUIC это им совсем не мешает.

Да и решением для корпоративного сектора мог бы стать механизм «сертифицированного MITM». Смысл в том, что в браузер устанавливается специальный сертификат фирмы, который так и помечается (он может быть только один). И дальше следует разрешение на MITM с этим сертификатом (плюс пользователю показывают предупреждение, что трафик мол просматривается твоей организацией). И всё хорошо.

У firefox есть настройка 'security.enterprise_roots.enabled', которая по сути это и делает. В Chrome фактически этот режим по умолчанию и чтобы совсем не заморачиваться, запрятали данные о сертификате подальше от пользовательских глаз долой.

Ну так тогда в чём проблема HPKP и корпоративного сегмента? В нём просто HPKP будет обрабатывать Firewall (или кто там занимается инспекцией трафика), а браузер игнорировать. В домашнем сегменте — проверять будет браузер.

Весь смысл HPKP избавиться от возможности злоупотребления со стороны CA. Т.к. после первого посещения сайта строиться цепь доверия (хотя схема и не такая как у блокчейна, но сути это не меняет). И даже если CA издаст левый сертификат (а это весьма вероятно, учитывая что у нас все CA могут издавать сертификаты ко всем сайтам) то такой сертификат будет послан нафиг, т.к. его хеш отсутствует в этой цепочке доверия.

P.S. Опять же где-то слышал что в Хроме зашита защита от выдачи сертификатов на домены Гугла от левых CA (т.е. себя они защищают, т.к. прекрасно всё понимают).

Просто сам подход хоть и выглядит простым, создает больше проблем. Нет ни чего постоянного. Люди ошибаются, сертификаты устаревают, их отзывают, перевыпускают, доверие появляется и теряется — такова реальность. Да и пользователям по правде важнее удобство, чем абстрактная безопасность. Если вдруг перестает работать сайт, а проблема решается лишь обновлением браузера это нонсенс. Для тех кому все это действительнт нужно, в браузерах есть поддержка относительно безопасных схем типа pkcs#11, хотя физическими токенами пользоваться и не так удобно.

Sign up to leave a comment.