Есть ли способ загрузить запрос перекрестного источника без явных заголовков CORS, установленных на стороне сервера? - PullRequest
Новая
       22

Есть ли способ загрузить запрос перекрестного источника без явных заголовков CORS, установленных на стороне сервера?

0 голосов
/ 23 мая 2019

Я пытаюсь написать потребителя RSS-канала на JavaScript, но, к сожалению, большинство каналов, похоже, явно не устанавливают заголовок access-control-allow-origin в своих ответах (хотя я понимаю, что данные предназначены для общественностипотребление / очистка).

Мой вопрос: есть ли способ загрузить такие данные в javascript (кроме использования прокси-сервера на стороне сервера или превращения проекта в плагин для браузера), учитывая, что:

  • Запросы - простые запросы на получение.(Таким образом, запрос OPTIONS обычно не отправляется, даже если присутствует заголовок access-control-allow-origin)
  • Файлы cookie / аутентификация не важны, так как каналы общедоступны.(Таким образом, withCredentials был бы ложным, если бы это был запрос XMLHttpRequest)

например что-то вроде: 

fetch('http://rss.slashdot.org/Slashdot/slashdotMain', {
  crossOrigin: false,
  xhrFields: {
    withCredentials: false
  }
})).then(function(response){
  console.log('Got a response!', response);
});

Обновление

Вторая часть моего вопроса: почемуРазрешено ли это?

Например: предположим, я по какой-либо причине перехожу на домен malware-website.com.Он отправляет простой запрос Ajax GET, включая withCredentials: false, на my-bank.com.my-bank.com обрабатывает этот запрос, но затем браузер блокирует ответ.

Как блокировка ответа на этот запрос получения повышает безопасность?

  • Не имеет значения, если яЯ вошел на my-bank.com на другой вкладке, поскольку файлы cookie или заголовок авторизации не отправляются в соответствии с директивой withCredentials: false.Классический сценарий XSRF уже был предотвращен - этот запрос точно такой же, как если бы любой другой пользователь в Интернете (включая вредоносного) загрузил этот ресурс.
  • Если в URL-адресе был маркер аутентификации (такой какJWT), то вредоносный веб-сайт уже имеет это и потенциально может сохранить его для собственного использования позже - блокировка этого конкретного ответа не изменит этого.
  • Он не защищает данные на my-bank.com, так какон не блокирует запрос, только ответ - если у них есть ресурс в стиле REST, который выполняет обновление в ответ на этот GET, тогда у меня будет плохое время.то есть: классический CSRF не предотвращается, если my-bank.com не требует непростой просьбы об обновлениях (POST или запрос с заголовками, чтобы сначала отправлялся запрос OPTIONS)

Итак, опять же, чтохорошо ли здесь блокировать только ответ?

Я думаю, что ответ, который я искал, был следующим: «Если простые withCredentials: false запросы также позволили подорвать ту же политику происхождения, то плохой актермог сделать Х ".

Есть идеи о том, что это за Х?

...