同源策略和CORS(跨域资源共享)

Question

我试图了解CORS.根据我的理解,它是一种在浏览器中实现的安全机制,以避免除了用户打开的域之外的任何ajax请求(在url中指定)

现在,由于这种限制,实施了许多CORS以使网站能够进行跨源请求.但根据我的理解,实施CORS违反了"同源政策" SOP的安全目的

CORS只是为了提供对请求服务器想要服务的额外控制.也许它可以避免垃圾邮件发送者

来自维基百科:

要启动跨源请求,浏览器会使用Origin HTTP标头发送请求.此标头的值是为页面提供服务的站点.例如,假设http://www.example-social-network.com上的页面 试图访问online-personal-calendar.com中的用户数据.如果用户的浏览器实现了CORS,则会发送以下请求标头:

来源:http://www.example-social-network.com

如果online-personal-calendar.com允许请求,它会在其响应中发送一个Access-Control-Allow-Origin标头.标头的值指示允许的源站点.例如,对先前请求的响应将包含以下内容:

Access-Control-Allow-Origin:http://www.example-social-network.com

如果服务器不允许跨源请求,则浏览器将向example-social-network.com页面而不是online-personal-calendar.com响应发送错误.

要允许访问所有页面,服务器可以发送以下响应头:

Access-Control-Allow-Origin:*

但是,这可能不适合担心安全问题的情况.

我在这里失踪了什么？CORS保护服务器与保护客户端安全的意图是什么.

Answer 1

同源政策

它是什么？

同源策略是浏览器之间标准化的安全措施.在"原产地"主要是指"域".它可以防止不同的来源相互交互,以防止诸如跨站点请求伪造等攻击.

CSRF攻击如何运作？

浏览器允许网站以cookie的形式在客户端的计算机上存储信息.这些cookie附带了一些信息,比如cookie的名称,创建时间,过期时间,设置cookie等等.Cookie看起来像这样:

Cookie: cookiename=chocolate; Domain=.bakery.com; Path=/ [// ;otherDdata]

所以这是一个巧克力饼干,应该可以从http://bakery.com及其所有子域访问.

此cookie可能包含一些敏感数据.在这种情况下,该数据是... chocolate.如你所见,高度敏感.

所以浏览器存储了这个cookie.每当用户向可访问此cookie的域发出请求时,cookie将被发送到该域的服务器.快乐的服务器

这是一件好事.服务器在客户端存储和检索信息的超酷方式.

但问题是,这允许http://malicious-site.com将这些cookie发送到http://bakery.com,而无需用户知道!例如,请考虑以下情形:

# malicious-site.com/attackpage

var xhr = new XMLHttpRequest();
xhr.open('GET', 'http://bakery.com/order/new?deliveryAddress="address of malicious user"');
xhr.send();

如果您访问恶意网站,并执行上述代码,并且不存在同源策略,则恶意用户将代表您下订单,并在他的位置获取订单...您可能不喜欢这个.

发生这种情况是因为你的浏览器发送你的巧克力饼干来http://bakery.com,这让http://bakery.com认为你正在为新秩序的要求,故意.但你不是.

简而言之,这就是CSRF攻击.跨网站提出了伪造请求."跨站请求伪造".由于同源政策,它不会起作用.

同源政策如何解决这个问题？

它阻止malicious-site.com向其他域发出请求.简单.

换句话说,浏览器将不会允许任何网站不得向其他任何网站的请求.它可以防止不同的起源通过AJAX之类的请求相互交互.

但是,来自其他主机的资源加载(如图像,脚本,样式表,iframe,表单提交等)不受此限制.我们需要另一面墙来保护我们的面包店免受恶意网站的攻击,使用CSRF令牌.

CSRF代币

如上所述,恶意网站仍然可以在不违反同源政策的情况下执行此类操作:

<img src='http://bakery.com/order/new?deliveryAddress="address of malicious user"'/>

并且浏览器将尝试从该URL加载图像,从而向该URL发送GET请求以发送所有cookie.为了阻止这种情况发生,我们需要一些服务器端保护.

基本上,我们将适当熵的随机唯一标记附加到用户的会话,将其存储在服务器上,并将其与表单一起发送给客户端.提交表单时,客户端会将该令牌与请求一起发送,服务器会验证该令牌是否有效.

既然我们已经这样做了,并且恶意网站再次发送请求,它将始终失败,因为恶意网站没有可行的方法来知道用户会话的令牌.

CORS

必要时,可以在需要跨站点请求时规避策略.这被称为CORS.跨源资源共享.

这通过让"域"告诉浏览器冷却并允许这样的请求来工作.这个"告诉"的事情可以通过传递标题来完成.就像是:

Access-Control-Allow-Origin: //comma separated allowed origins list, or just * 因此,如果http://bakery.com将此标题传递给浏览器,并且创建请求到http://bakery.com的页面出现在原始列表中,那么浏览器将提供请求以及cookie .

根据原则定义的规则¹.例如,同一域的不同端口不是同一个源.因此,如果端口不同,浏览器可能会拒绝此请求.与往常一样,我们亲爱的 Internet Explorer也是例外.IE以相同的方式处理所有端口.这是非标准的,没有其他浏览器以这种方式运行.不要依赖于此.

JSONP

当CORS不是一个选项时,带有填充的JSON只是绕过同源策略的一种方法.这是冒险的,也是一种不好的做法.避免使用它.

该技术涉及的是向其他服务器发出如下请求:

<script src="http://badbakery.com/jsonpurl?callback=cake"></script>

由于同源策略不会阻止此²请求,因此该请求的响应将加载到页面中.

这个网址很可能会回复JSON内容.但只是在页面上包含JSON内容并不会有帮助.它会导致错误,当然.因此http://badbakery.com接受一个回调参数,并修改JSON数据,将其包装在传递给回调参数的任何内容中.

所以不要回来,

{ user: "vuln", acc: "B4D455" }

这是无效的JavaScript抛出错误,它会返回,

cake({user: "vuln", acc:"B4D455"});

这是有效的JavaScript,它会被执行,并可能根据cake函数存储在某处,以便页面上的其余JavaScript可以使用数据.

这主要由API用于将数据发送到其他域.同样,这是一种不好的做法,可能存在风险,应该严格避免.

为什么JSONP不好？

首先,它非常有限.如果请求失败,您将无法处理任何错误(至少不是以理智的方式).您无法重试请求等.

它还要求您cake在全局范围内具有不太好的功能.如果您需要使用不同的回调执行多个JSONP请求,厨师可以保存您.这可以通过各种图书馆的临时功能来解决,但仍然是做一些hackish的hackish方式.

最后,您将在DOM中插入随机JavaScript代码.如果您不是100%确定远程服务将返回安全蛋糕,您不能依赖于此.

参考

^{1. https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy#Definition_of_an_origin}

^{2. https://www.w3.org/Security/wiki/Same_Origin_Policy#Details}

其他有价值的读物

http://scarybeastsecurity.blogspot.dk/2009/12/generic-cross-browser-cross-domain.html

http://tools.ietf.org/html/rfc3986(抱歉:p)

https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy

https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)

Answer 2

浏览器为防止跨站点脚本（XSS）漏洞而实施的策略是同源起源策略（SOP）。这主要是为了保护服务器，因为在很多情况下服务器可以处理身份验证，Cookie，会话等。

跨源资源共享（CORS）是放松SOP的少数技术之一。由于默认情况下SOP为“ on”，因此在服务器端设置CORS将允许通过XMLHttpRequest将请求发送到服务器，即使该请求是从其他域发送的也是如此。如果您的服务器打算服务来自其他域的请求（例如，如果您提供的是API），则此功能将非常有用。

我希望这可以消除SOP和CORS之间的区别以及两者的目的。