Кажется, предполетная подготовка к CORS не имеет смысла. Это шутка?

Question

По образцам отсюда:

Если в запросе используются методы, отличные от GET, HEAD или POST. Кроме того, если POST используется для отправки данных запроса с Content-Type, отличным от application/x-www-form-urlencoded, multipart/form-data или text/plain, например, если запрос POST отправляет полезную нагрузку XML на сервер используя application/xml или text/xml, запрос предварительно просвечивается.

Таким образом, в следующем примере предполёт выполняется из-за типа контента XML и пользовательского заголовка X-PINGOTHER:

var invocation = new XMLHttpRequest();
var url = 'http://bar.other/resources/post-here/';
var body = '<?xml version="1.0"?><person><name>Arun</name></person>';

function callOtherDomain(){
  if(invocation)
    {
      invocation.open('POST', url, true);
      invocation.setRequestHeader('X-PINGOTHER', 'pingpong'); //<====
      invocation.setRequestHeader('Content-Type', 'application/xml'); //<====
      invocation.onreadystatechange = handler;
      invocation.send(body); 
    }
}

Но в так называемом предварительном запросе OPTIONS (ниже) сервер уведомляется только о HTTP-методе и настраиваемом заголовке. Никто не сказал серверу оXML Content-Type,

Логично, что пока отправляется запрос предварительной проверки, это означает, что Content-Type отсутствует в 3 формах, которые не требуют предварительной проверки. Но может быть множество других возможностей. Суть в том, что сервер должен знать, почему отправляется предварительный запрос.

Так как же сервер мог разумно решить, разрешить ли этот запрос с отсутствующим фрагментом головоломки (тип контента)?

Answer 1

CORS почти всегда безопасен. Цитирование из Fetch Standard,

Для ресурсов, где данные защищены с помощью IP-аутентификации или брандмауэра (к сожалению, все еще относительно распространенным), использование протокола CORS небезопасно. (Это причина, почему протокол CORS должен был быть изобретен.)

Однако в противном случае использование следующего заголовка безопасно:

Access-Control-Allow-Origin: *

Даже если ресурс предоставляет дополнительную информацию, основанную на cookie или HTTP-аутентификации, использование вышеуказанного заголовка не раскроет ее. Он будет делить ресурс с такими API, как XMLHttpRequest, так же, как он уже используется совместно с curl и wget.

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

Таким образом, серверу не нужно ничего знать о типе содержимого запроса, чтобы знать, как ответить на запрос OPTIONS. Сервер просто должен знать: запрашиваемый URL-адрес доступен только через аутентификацию на основе IP или за каким-то брандмауэром или интранетом? Если это так, то он должен отклонить запрос OPTIONS. Если это не так, т. Е. Если ресурс доступен через общедоступный Интернет с использованием таких инструментов, как curl, wget, telnet или вашей любимой библиотеки HTTP, то он должен разрешить запрос OPTIONS. Это даст браузерам тот же доступ, что и другим инструментам.

Затем сервер может принимать дальнейшие решения при поступлении последующего запроса POST. Например, возможно, сервер хочет отклонить POST с неправильным Content-Type. Но он всегда хотел бы сделать это. Не хотелось бы отклонять запрос OPTIONS только от CORS-уважающих браузеров; вместо этого он должен отклонить запрос POST из любого источника.

(Причина, по которой браузеры являются особыми, заключается в следующем. Рассмотрим интранет, который следует плохим правилам безопасности и доступен для чтения любому, кто имеет свой IP-адрес в определенном диапазоне, т.е. любому, кто использует компьютер компании. Обычно это не проблема: люди внутри Компания, использующая curl, может получить доступ к данным, а люди за ее пределами, которые используют curl, не могут. Однако, рассмотрим кого-то внутри компании, который просматривает какой-либо вредоносный веб-сайт, https://evil.com/. Если evil.com использует XHR API для зайдите на http://intranet/secret-data, тогда запрос будет поступать с привилегированного IP-адреса, так как запрос выполняет браузер на компьютере привилегированного пользователя. Чтобы предотвратить такие утечки безопасности, был разработан протокол CORS, поэтому что вместо выполнения прямого POST для http://intranet/secret-data, браузер сначала выполняет запрос OPTIONS, для которого весь http://intranet/, вероятно, просто скажет "нет, вы не можете получить к нему доступ", и тогда ПОЧТА никогда не происходит.)