入侵同网手机_入侵同一个原产地政策

入侵同网手机

重点 (Top highlight)

The Same-Origin Policy is one of the fundamental defenses deployed in modern web applications. It restricts how a script from one origin can interact with the resources of a different origin. It is critical in preventing a number of common web vulnerabilities.

同源策略是现代Web应用程序中部署的基本防御措施之一。 它限制了一个来源的脚本如何与另一个来源的资源进行交互。 防止许多常见的Web漏洞至关重要。

However, since the SOP is quite strict and inflexible, most websites utilize methods of relaxing the SOP. And this is often where things go wrong. Today, we are going to dive into the details of SOP, how it impacts web applications, and how attackers exploit features that relax SOP.

但是,由于SOP相当严格且不灵活,因此大多数网站都采用放宽SOP的方法。 这通常是出问题的地方。 今天,我们将深入研究SOP的细节,它如何影响Web应用程序以及攻击者如何利用放松SOP的功能。

什么是原产地政策(SOP)? (What is the Same-Origin Policy (SOP)?)

In one sentence, the Same-Origin Policy is this: A script from page A can only access data from page B if they are of the same origin.

一句话,“同源策略”是这样的:来自页面A的脚本只能访问来自页面B的数据(如果它们具有相同的来源)。

谁的血统相同? (Who has the same origin?)

Two URLs are said to have the same origin if they share the same protocol, hostname and port number. Let’s say that page A is at

如果两个URL共享相同的协议,主机名和端口号,则称它们具有相同的来源。 假设A页位于

https://medium.com/@vickieli (HTTPS is on port 443 by default)

Which of these following pages would be of the “same-origin” according to the Same-Origin Policy?

根据“原产地政策”,以下哪些页面属于“原产地”?

https://medium.com/ (same origin, same protocol, hostname and port number)http://medium.com/ (different origin, because protocol differs)https://twitter.com/@vickieli (different origin, because hostname differs)https://medium.com:8080/@vickieli (different origin, because port number differs)

SOP有什么限制? (What does SOP limit?)

The SOP does not allow a script from page A to access data on page B if they don’t share the same origin. This is meant to prevent a malicious script on page A from obtaining sensitive information embedded on page B’s DOM.

如果SOP不共享相同的原始数据,则不允许A页中的脚本访问B页中的数据。 这是为了防止页面A上的恶意脚本获取嵌入在页面B的DOM中的敏感信息。

  • Side note: SOP limits data access only. Embedded resources such as images, CSS and scripts not restricted and can be accessed and loaded across different origins.

    旁注:SOP仅限制数据访问。 嵌入式资源(例如图像,CSS和脚本)不受限制,可以跨不同来源访问和加载。

Modern web applications often base their authentication on HTTP cookies, and servers take action based on the cookies included automatically by the browser. This makes SOP especially important.

现代Web应用程序的身份验证通常基于HTTP cookie,服务器根据浏览器自动包含的cookie采取措施。 这使得SOP尤其重要。

Imagine if you are logged in into onlinebank.com, and at the same time, you are visiting attacker.com in the same browser. If SOP doesn’t exist, a script hosted on attacker.com is free to access your information on onlinebank.com, since your browser would automatically include your onlinebank.com cookies in every request you send to onlinebank.com (Even if the request is a malicious one generated from a script hosted on attacker.com).

试想一下,如果你已经登录了onlinebank.com,并在同一时间,你是在同一个浏览器访问attacker.com。 如果不存在SOP,则攻击者网站上托管的脚本可以自由访问onlinebank.com上的信息,因为您的浏览器会在您发送给onlinebank.com的每个请求中自动包含您的onlinebank.com cookie(即使该请求从托管在attacker.com脚本)生成一个恶意的。

attacker.com could do something like this:

Attacker.com可以执行以下操作:

1. Issue a GET request to onlinebank.com/personal_info using a script. (Since you are logged in to onlinebank.com, the server could send back the HTML page containing your personal info page.)2. Receive and parse the returned HTML page.3. Retrieve the CSRF tokens, private email addresses, addresses and banking information parsed from the page.

This is where SOP comes into play: SOP will prevent the malicious script hosted on attacker.com to read the HTML data returned from onlinebank.com.

这是SOP发挥作用:SOP将阻止托管在attacker.com恶意脚本来读取onlinebank.com返回HTML数据。

放宽SOP (Relaxing the SOP)

Practically, SOP is often too restrictive for modern web applications. For example, multiple subdomains or multiple domains of the same large website would not be able to share information with each other. To work around these issues, many ways of relaxing or working around the SOP was invented.

实际上,对于现代Web应用程序,SOP常常过于严格。 例如,同一大型网站的多个子域或多个域将无法彼此共享信息。 为了解决这些问题,发明了许多放松或解决SOP的方法。

设置document.domain (Setting document.domain)

Setting the domain of different subdomains to the same using document.domain will enable them to share resources. For example, setting the domain of a.domain.com and b.domain.com to domain.com so that they can interact.

使用document.domain将不同子域的域设置为相同的域将使它们能够共享资源。 例如,将a.domain.comb.domain.com的域设置为domain.com,以便它们可以交互。

  • Side note: Doing this will set the port number to null, which might be interpreted differently by different browsers. In the above example, https://a.domain.com might not be able to interact with https://domain.com since their port numbers differ (Null versus 443).

    旁注:这样做会将端口号设置为null,不同的浏览器可能会对此解释不同。 在上面的示例中,https://a.domain.com可能无法与https://domain.com进行交互,因为它们的端口号不同(Null与443)。

跨域资源共享(CORS) (Cross-origin resource sharing (CORS))

You can also use Cross-origin resource sharing (CORS) to relax the SOP. CORS protects the data of the requested server. It allows servers to explicitly specify the list of origins that are allowed via the Access-Control-Allow-Origin header. The origin of the page sending the request is then checked against this list of allowed origins.

您还可以使用跨域资源共享(CORS)放宽SOP。 CORS保护请求的服务器的数据。 它允许服务器通过Access-Control-Allow-Origin标头明确指定允许的来源列表。 然后对照此允许的来源列表检查发送请求的页面的来源。

跨域消息传递(postMessage) (Cross-domain messaging (postMessage))

PostMessage is a way of working around SOP. This technique allows pages to send text-based messages to other pages by calling the postMessage() method on a window. The receiving window then handles the message using an onmessage event handler.

PostMessage是解决SOP的一种方法。 该技术允许页面通过在窗口上调用postMessage()方法将基于文本的消息发送到其他页面。 然后,接收窗口使用onmessage事件处理程序处理消息。

Since using postMessage requires the sender to obtain the window object of the receiver, messages can only be sent between a window and its iframes or popups.

由于使用postMessage要求发送者获取接收者的窗口对象,因此消息只能在窗口与其iframe或popups之间发送。

带有填充的JSON(JSONP) (JSON with Padding (JSONP))

JSONP is another technique that works around SOP. It allows the sender to send JSON data within a callback function that gets evaluated as JS. Then a script located at a different origin can read the JSON data by processing the function.

JSONP是另一种围绕SOP起作用的技术。 它允许发送方在被评估为JS的回调函数中发送JSON数据。 然后,位于不同来源的脚本可以通过处理函数读取JSON数据。

Since the HTML <script> tag is allowed to load JS code regardless of origin, an easy way of sharing data across origins is through loading it as a part of a <script> tag. JSONP wraps JSON data in a callback function in order for the data to be interpreted as valid JS code.

由于允许HTML <script>标记加载JS代码,而与来源无关,因此跨来源共享数据的一种简单方法是将其作为<script>标记的一部分进行加载。 JSONP将JSON数据包装在回调函数中,以便将数据解释为有效的JS代码。

For example, let’s say we’re trying to pass the following JSON blob across origins:

例如,假设我们试图跨来源传递以下JSON Blob:

// data located at https://medium.com/get_user_articles
{“username”: “vickieli”, “num_articles”: “39”}

This data block cannot be loaded directly as a script since it’s in JSON format:

由于此数据块采用JSON格式,因此无法直接将其作为脚本加载:

<script src=”https://medium.com/get_user_articles”></script>

This would fail since the JSON blob above it’s not valid Javascript, and a JS syntax error would be thrown. JSONP works around this issue by wrapping the data in a JS function:

这将失败,因为其上方的JSON Blob不是有效的Javascript,并且将引发JS语法错误。 JSONP通过将数据包装在JS函数中来解决此问题:

parse({“username”: “vickieli”, “num_articles”: “39”})

The page that receives the data can then extract the data from the JSONP payload by processing the function.

然后,通过处理函数,接收数据的页面可以从JSONP有效负载中提取数据。

The issue with JSONP is that site A would have to trust site B completely because it is including arbitrary Javascript from site B. Now that CORS is an option, JSONP is used less often.

JSONP的问题在于,站点A必须完全信任站点B,因为它包含来自站点B的任意Javascript。既然可以使用CORS,那么JSONP的使用就更少了。

攻击SOP (Attacking the SOP)

Besides the controlled and intended SOP bypasses mentioned above, there are ways that an attacker can use to manipulate cross-origin communication. These exploits are often caused by the faulty implementation of one of the SOP relaxing techniques.

除了上面提到的受控和有目的的SOP绕过之外,攻击者还可以使用多种方法来操纵跨域通信。 这些漏洞通常是由SOP放松技术之一的错误实施引起的。

An attacker being able to bypass SOP and the relaxation policy intended by the developers can cause private information to be leaked and often leads to more vulnerabilities such as authentication bypass, account takeover and large data breaches.

攻击者能够绕过SOP和开发人员意图的放松策略,可能会导致私人信息泄漏,并经常导致更多漏洞,如身份验证绕过,帐户接管和大数据泄露。

Let’s talk about a couple of ways how attackers achieve this and how these techniques work.

让我们谈谈攻击者如何实现此目标以及这些技术如何工作的几种方法。

XSS (XSS)

XSS is essentially a full SOP bypass because Javascript that runs on page A would operate under the security context of page A. This means that if an attacker is able to get a malicious script executed on the victim page, the script can access the page’s resources and data.

XSS本质上是完整的SOP绕过,因为在页面A上运行的Javascript将在页面A的安全上下文下运行。这意味着,如果攻击者能够在受害页面上执行恶意脚本,则该脚本可以访问页面的资源。和数据。

利用CORS (Exploiting CORS)

Misconfigured CORS is another thing that attackers can exploit to mess with cross-origin communication.

错误配置的CORS是攻击者可能利用来干扰跨域通信的另一件事。

One of the exploitable misconfigurations is when a site uses weak regex to validate origins. For example, if the policy only checks if an origin URL starts with www.site.com, that policy can be bypassed by using wildcard subdomains. If the attacker owns the domain attacker.com, she can enable the wildcard entry to her own domain, so that *.attacker.com would be redirected to attacker.com. She can then use www.site.com.attacker.com as the origin of the request to bypass SOP.

可利用的错误配置之一是站点使用弱正则表达式验证来源。 例如,如果该策略仅检查原始URL是否以www.site.com开头,则可以使用通配符子域来绕过该策略。 如果攻击者拥有域Attacker.com,则可以启用通配符条目到其自己的域,以便将* .attacker.com重定向到Attacker.com。 然后,她可以使用www.site.com.attacker.com作为绕过SOP的请求的来源。

Another common misconfiguration of CORS that can be exploited is setting allowed origins to NULL or attacker.com. This basically defeats the purpose of SOP and removes the limitation on any cross-origin communication.

可以利用的另一个常见的CORS配置错误是将允许的来源设置为NULL或Attacker.com。 这从根本上破坏了SOP的目的,并消除了任何跨域通信的限制。

An interesting configuration that is not exploitable is setting the allowed origins to the wildcard “*”. This is not exploitable because CORS does not allow credentials to be sent with these requests, and so no private information could be leaked.

一个无法利用的有趣配置是将允许的来源设置为通配符“ * ”。 这是无法利用的,因为CORS不允许将凭据与这些请求一起发送,因此不会泄露任何私人信息。

Misconfiguration in CORS is also not exploitable when custom headers are used for authentication, or when there are random, unguessable keys placed in the request or the URI.

当使用自定义标头进行身份验证,或者在请求或URI中放置随机,不可猜测的密钥时,也无法利用CORS中的错误配置。

利用postMessage (Exploiting postMessage)

When using postMessage, both the sender and the receiver of the message should verify the origin of the other side. Vulnerabilities happen when pages enforce poor origin check (weak regex, for example), or lack origin checks altogether.

使用postMessage时,消息的发送者和接收者都应验证另一端的来源。 当页面强制执行较差的原始检查(例如,正则表达式较弱)或完全缺少原始检查时,就会发生漏洞。

If the sender page does not enforce the targetOrigin of the receiver or uses a wildcard targetOrigin, it becomes possible to leak information to other sites using postMessage. (The targetOrigin can be specified in the postMessage function as a parameter.)

如果发送者页面未强制执行接收者的targetOrigin或使用通配符targetOrigin ,则可以使用postMessage将信息泄漏到其他站点。 (可以在postMessage函数中将targetOrigin指定为参数。)

To exploit this issue, an attacker can create a malicious HTML page that listens for events coming from the vulnerable page. She can then trick victims into triggering the postMessage utilizing a malicious link or fake image and make the victim page send data to the attacker’s page.

为了利用此问题,攻击者可以创建一个恶意HTML页面,以侦听来自易受攻击页面的事件。 然后,她可以诱使受害者利用恶意链接或伪造图像触发postMessage,并使受害者页面将数据发送到攻击者的页面。

On the other hand, if the message receiver does not validate where the postMessage is coming from, it becomes possible for attackers to send arbitrary data to the website and trigger unwanted actions on the victim’s behalf.

另一方面,如果消息接收者无法验证postMessage的来源,则攻击者就有可能向网站发送任意数据并代表受害者触发不需要的操作。

To do that, the attacker can embed or open the victim page in an HTML page to obtain its window reference. Then, she is free to send arbitrary postMessages to that window. When this malicious HTML page is accessed by the victim, the malicious postMessage will be fired bearing the victim’s credentials.

为此,攻击者可以将受害者页面嵌入或打开HTML页面以获得其窗口引用。 然后,她可以自由地向该窗口发送任意的postMessages。 当受害者访问此恶意HTML页面时,将发出带有受害者凭据的恶意postMessage。

Thanks for reading.

谢谢阅读。

翻译自: https://medium.com/swlh/hacking-the-same-origin-policy-f9f49ad592fc

入侵同网手机

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值