SOP（同源政策）的含义
SOP（同源政策）的真正含义是什么？
我知道这意味着来自一个来源的 Javascript 代码无法从另一个来源获取资源。但“资源”一词到底意味着什么？例如：
- Javascript 代码可以从另一个站点访问图像。
- Javascript 代码无法向另一方发出 ajax 请求。
但是，当您使用 JSON 填充时，在完成填充脚本标记的加载后，第 3 方脚本将调用您指定的回调 - 一个站点的 Javascript 代码正在调用另一个站点的 Javascript 代码的方法。这是否违反SOP？
What is the real meaning of SOP (Same Origin Policy)?
I know it means that the Javascript code from one origin cannot accuess resources from another origin. But what exactly does the word "resources" mean? For example:
- Javascript code can access IMAGES from another site.
- Javascript code cannot make ajax request to another side.
But when you use JSON padding, after completing the loading of a padded script tag, the 3rd party script will call your specified callback -- Javascript code from one site is invoking a method of Javascript code from another. Does this violate SOP?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
有几种类型，但如果我们不指定：
这里对不同类型的 SOP 进行了精彩的描述。
There are several types but if we don't specify:
Here you have an excellent description of different types of SOP.
同源策略主要是为了防止其他域的脚本在加载的域的上下文中执行AJAX（XMLHTTP）请求，并限制其他域的站点访问cookie、本地存储等站点资源。就像为安全措施制定的标准规范一样，每个浏览器都有自己的通过遵守规范来实现它的方式。
我所说的“阻止其他域的脚本执行 AJAX (XMLHTTP) 请求”是指跨源请求不属于同一域。
例如，domain.com 和 test.domain.com 属于同一域，test 是子域，而 test.domain2.com 属于完全不同的域。
现在让我们考虑一下它的安全隐患：-
1. 假设网站 site1.com 有一个 API 调用来更新密码。当用户输入所需数据时，将向后端发出 HTTP 调用，并使用 cookie 中包含的会话数据验证用户的真实性。
2) 话虽如此，如果攻击者创建一个名为 site2 的站点，并具有 javascript 代码来对 site1 的更改密码端点进行 HTTP 调用。根据浏览器的默认行为，它将 site1 的所有 cookie 数据附加到请求中，这使得 HTTP 调用成功，从而使攻击者得逞。
3）为了能够缓解这种情况，浏览器实施了 SOP，它指示浏览器 javascript 引擎阻止任何跨域的请求，例如从 site2 到 site1，除非指示允许这样做。
4）现在，在这个不断发展的现代世界中，微服务架构和多个子域，这将是非常有问题的。为了解决这个问题，如果 API 响应中包含 Access-Control-Allow-Origin、Access-Control-Allow-Methods、Access-Control-Allow-Credentials 等标头，则浏览器支持跨源请求
。 5)当 ajax 请求从 site2 发送到 site1 时，浏览器会检查 API 响应标头，如果响应中存在以下任何值，则允许该请求：-
Access-Control-Allow-Origin:* 或 Access-Control-Allow-Origin:site2.com 或 Access-Control-Allow-Origin:*.site2.com （通配符条目）
6）话虽这么说，但存在一个主要漏洞这里，即使sop策略阻止了请求，它实际上意味着浏览器阻止了site2访问以读取响应数据，这意味着请求已经向服务器发出。此场景仅适用于特定条件下的少数请求，不会触发飞行前选项调用。当进行选项调用时，浏览器将根据选项调用中的标头响应不允许请求通过。
7）现在是第二部分，即 Access-Control-Allow-Credentials。在选项调用的服务器响应中，如果服务器将所有机密会话数据（如授权标头）的标头设置为 true，则安全 cookie 将添加到从 site2 到 site1 的跨源请求中。
注意：- 仅当 Access-Control-Allow-Origin 非常特定于某个域时才会添加此标头，这意味着它不适用于标头中的 * 值。如果 Access-Control-Allow-Origin 标头为 *，那么如果 Access-Control-Allow-Credentials 设置为 true，浏览器 SOP 策略将启动并阻止其允许安全数据。
SOP 原始策略不会' t 处理图像源和外部脚本包含。为了能够利用对这些内容的控制，请通过内容安全策略（CSP）。使用它，您可以控制对外部站点的图像、脚本、字体、样式等的访问。您还可以阻止站点中的不安全内联评估，例如警报框，以防止某些 XSS 攻击。这是新的事实上的标准，许多网站开始实施它。
为了能够防止此类攻击（CSRF 攻击），网站还实现了 csrf 令牌以及随每次状态更改而更改的表单。即使攻击者以某种方式从 site2 向 site1 发出请求，该请求也不会通过，因为 site1 的服务器会验证 csrf 令牌以及请求，攻击者无法通过该请求进行访问。
如果存在原始标头，其他措施将添加基于原始的验证。
JSONP 旨在通过回调来允许这种机制。
抱歉回答这么长，而且主题远比这个大。这只是我自己的理解，如果有错误的地方请告诉我。
Same Origin Policy is mainly intended to prevent scripts for other domains to perform AJAX (XMLHTTP) requests in the context of the loaded domain and also restricts sites of other domain to access sites resources like cookies, local storage etc. It is more like a standard specification formulated for security measures and every browser has its own way of implementing it by adhering to specifications.
By saying 'prevent scripts for other domains to perform AJAX (XMLHTTP) requests' I mean the cross-origin requests which don't belong to the same domain.
For example, domain.com and test.domain.com belong to the same domain and the test is subdomain, while test.domain2.com belongs to an entirely different domain.
Now let us consider its security implications:-
1.Let us say a website site1.com has an API call to update the password. When the user inputs the required data an HTTP call is made to the backend and the user's authenticity is validated with the session data contained in cookies.
2)Now with this being said, if the attacker creates a site named site2 and has a javascript code to make an HTTP call to site1's change password endpoint. By browsers default behavior it attaches all the cookie data it has for site1 to the request which makes the HTTP call successful thus allowing attackers to succeed.
3)To be able to mitigate this browsers implemented SOP, which dictates the browsers javascript engine to block any request to cross domains like from site2 to site1 for example, unless instructed to allow to do so.
4)Now in this growing modern world with microservice architectures and multiple subdomains, this will be very problematic. To get around this browsers support cross-origin requests if the API response says so with headers like Access-Control-Allow-Origin, Access-Control-Allow-Methods, Access-Control-Allow-Credentials, etc.
5)To put it forward when the ajax request is made from site2 to site1, the browsers check the API response headers and allows the request if any of these values are present in response:-
Access-Control-Allow-Origin:* or Access-Control-Allow-Origin:site2.com or Access-Control-Allow-Origin:*.site2.com (wildcard entry)
6)With this being said there is a major loophole here, even if the sop policy blocks the request, it actually means that the browser blocks the site2 access to read the response data meaning the request was already made to the server. This scenario is only applicable to a few requests on specific conditions which doesn't trigger pre-flight options call. When the options call is made the browser will not allow the request to go through based on the header response in options call.
7)Now comes the second part to it which is Access-Control-Allow-Credentials. In the server response for options call, if the server sets the header to true all the confidential session data like Authorization header, secure cookies will be added to the cross-origin requests from site2 to site1.
Note:- This header is only added if Access-Control-Allow-Origin is very specific to a domain meaning it will not work for * value in the header. Is the Access-Control-Allow-Origin header is * then browsers SOP policy will kick in and blocks it from allowing the secure data if Access-Control-Allow-Credentials is set to true.
The SOP origin policy doesn't deal with image sources and external script includes. To be able to utilize control over those go through the Content Security Policy (CSP). Using it you could control access to external sites wrt to images, scripts, fonts, styles, etc. You would also be able to block unsafe-inline eval's in site like alert boxes to prevent some XSS attacks. This is new defacto standard and a lot of websites started implementing it.
To be able to prevent such attacks (CSRF attacks), websites also implement a csrf-token along with a form that changes on every state change. Even if attacker somehow makes the request from site2 to site1, the request will not go through as the server at site1 validates the csrf token along with the request, which the attacker cannot access through.
Other measures would add origin-based validation if the origin header is present.
JSONP is designed to allow such a mechanism through callbacks.
Sorry for such a long answer and the topic is far bigger than this. This is just my own understanding of it and let me know if I am wrong anywhere.
JSONP 通过向 DOM 动态添加脚本标签并使用远程 Web 服务的 JSON 数据作为参数调用预定义函数来绕过同源策略。该标签不受同源策略的约束，因此可以跨域请求内容。
就像如何使用 Google 版本的 jQuery 在不违反 SOP 的情况下，您可以在您的网站上“包含”一个脚本标记，该标记对您从 Web 服务收到的数据调用预定义函数。
JSONP gets around the Same Origin Policy by dynamically adding a script tag to the DOM and calling a predefined function with the remote web service's JSON data as the parameter. The tag is not subject to the same origin policy and therefore can request content cross-domain.
Just like how you can use Google's version of jQuery on your site without violating SOP, you can "include" a script tag that calls a predefined function on the data you receive back from a web service.