2015-11-04 4 views
1

В контексте CORS можно ли заставить браузер всегда отправлять заголовок Origin с полным доменным именем? Целевая служба должна видеть Origin: http://website.intranet.example.com/page.html вместо Origin: http://website/page.html.Браузер не отправляет FQDN в заголовке Origin

Как видно из примера, это среда интрасети, и цель состоит в том, чтобы отфильтровать исходные запросы по субдомену, чтобы разрешить любую страницу, размещенную на машине домена (*.intranet.example.com), чтобы сделать запросы перекрестного происхождения службе, которая также размещена в тот же домен. Проблема (если хотите) заключается в том, что сайты интрасети обычно адресуются как http://website/, а остальная часть подразумевается суффиксом DNS для подключения: intranet.example.com, установленным с помощью политики домена.

Единственный способ решения проблемы я могу думать о том, чтобы требовать, чтобы все страницы «происхождения», чтобы заставить канонические URL (т.е. перенаправлять //foo к //foo.intranet.example.com) с наименьшим побочным эффектом «некрасивых URL-адресов».

ответ

0

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

Предполагая, что для разрешения запроса на перекрестный запрос ответному серверу необходимо ответить только соответствующим заголовком ответа Access-Control-Allow-Origin, вы можете ответить с помощью значения подстановочного знака, чтобы сказать, что любой входящий источник в порядке:

Access-Control-Allow-Origin: * 

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

например. в Apache, используйте модули SetEnvIf и Header для записи переменной среды, содержащей значение начала, если это значение соответствует определенному регулярному выражению, тогда, если эта переменная существует, напишите заголовок ответа Access-Control-Allow-Origin со значением переменной среды:

SetEnvIf Origin "(.+)" origin_header_value=$1 
Header set Access-Control-Allow-Origin "%{origin_header_value}e" env=origin_header_value 

Если вам нужно более точный контроль над зерном, содержит ли веб-сервер в Access-Control-Allow-Origin заголовок таким образом, то вы можете просто установить более ограничительное регулярное выражение в команде SetEnvIf вместо использования .+.

+0

Проблема в том, что 'Origin: http: // server1 /' является неоднозначным. Запрос может быть легитимным на странице «server1.intranet.example.com» или «server1» может быть вредоносной машиной в какой-либо локальной сети; это применяется, когда пользователь домена удален и использует VPN или DirectAccess для доступа к интрасети. – Serguei

+0

Это может быть справедливо в отношении любого HTTP-запроса, хотя похоже, что вы хотите определить легитимность запроса на основе значения заголовка Origin, но это не очень хороший способ определить вредоносные запросы - вы можете сделать HTTP-запросы с любыми значениями, установленными в их. Возможно, вы можете добавить дополнительную проверку входящих IP-адресов в белый список? Или добавить некоторую http-авторизацию или предположить, что, если вы можете определить, что запрос поступает через VPN, что он уже должен быть разрешен? - это может зависеть, если это закрытая или открытая интрасеть. – user3417917

+0

Пользователь переходит к 'http: // evil-comp/page.html' (сервер без домена), который вызывает вызовы AJAX на' http: // payroll.intranet.example.com/конфиденциальный', а затем пересылает эти данные в другом месте. Правильная политика CORS предотвратит появление «http: // evil-comp/page.html» содержимого содержимого ответа. – Serguei