0

我正在尝试用 JavaScript 编写 RSS 提要使用者，但不幸的是，大多数提要似乎没有在其响应中明确设置访问控制允许来源标头（尽管我的理解是数据是供公共消费/抓取的）。

我的问题是：有没有办法在javascript中加载这样的数据（除了使用服务器端代理或将项目变成浏览器插件），因为：

  • 这些请求是简单的获取请求。（因此，即使存在 access-control-allow-origin 标头，通常也不会发送任何 OPTIONS 请求）
  • Cookies / 身份验证并不重要，因为提要是公开的。（因此，如果它是 XMLHttpRequest，withCredentials 将是错误的）

例如：

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

更新

我的问题的第二部分是：为什么不允许这样做？

例如：假设我出于某种原因导航到域恶意网站。它发送一个简单的 Ajax GET 请求，包括withCredentials: false到 my-bank.com。my-bank.com 处理此请求，但随后浏览器阻止响应。

阻止对此获取请求的响应如何提高安全性？

  • 如果我在不同的选项卡中登录 my-bank.com 并不重要，因为根据withCredentials: false指令不会发送任何 cookie 或授权标头。经典的 XSRF 场景已经被阻止了——这个请求就像互联网上的任何其他用户（包括恶意用户）已经加载了这个资源一样。
  • 如果 URL 中有一个身份验证令牌（例如 JWT），那么恶意网站已经拥有它，并且可能会存储它以供以后自己使用 - 阻止此特定响应不会改变这一点。
  • 它不保护 my-bank.com 上的数据，因为它不阻止请求，只是响应 - 如果他们有一个 REST 样式的资源来执行更新以响应该 GET，那么我将度过一段糟糕的时光。即：除非 my-bank.com 需要一个非简单的更新请求（一个 POST 或带有标头的请求，以便首先发送一个 OPTIONS 请求），否则不会阻止经典的 CSRF

再说一次，在这里阻止响应实际上有什么好处？

我想我正在寻找的答案是这样的：“如果简单的withCredentials: false请求也被允许破坏相同的源策略，那么一个坏演员可以做 X”。

关于 X 是什么的任何想法？

4

0 回答 0