同源策略

566 阅读6分钟

同源策略(Same-origin policy,简称 SOP)

同源

何为同源?

协议、域名、端口都一样,就是同源

限制

之所以会遇到 跨域问题,正是因为 SOP 的各种限制。但是具体来说限制了什么呢?

如果你说 SOP 就是“限制非同源资源的获取”,这不对,最简单的例子是引用图片、css、js 文件等资源的时候就允许跨域。

如果你说 SOP 就是“禁止跨域请求”,这也不对,本质上 SOP 并不是禁止跨域请求,而是在请求后拦截了请求的回应。这就会引起后面说到的 CSRF

其实 SOP 不是单一的定义,而是在不同情况下有不同的解释:

  • 限制 cookies、DOM 和 Javascript 的命名区域
  • 限制 iframe、图片等各种资源的内容操作
  • 限制 ajax 请求,准确来说是限制操作 ajax 响应结果,本质上跟上一条是一样的

下面是 3 个在实际应用中会遇到的例子:

  • 使用 ajax 请求其他跨域 API,最常见的情况,前端新手噩梦
  • iframe 与父页面交流,出现率比较低,而且解决方法也好懂
  • 对跨域图片(例如来源于 )进行操作,在 canvas 操作图片的时候会遇到这个问题

如果没有了 SOP:

  • 一个浏览器打开几个 tab,数据就泄露了
  • 你用 iframe 打开一个银行网站,你可以肆意读取网站的内容,就能获取用户输入的内容
  • 更加肆意地进行 CSRF

解决跨域的办法就不说了,网上一查一大把

跨站请求伪造 CSRF

CSRF(Cross-site request forgery)跨站请求伪造,是一种常见的攻击方式。

设想这样一种情况:A网站是一家银行,用户登录以后,又去浏览其他的网站,如果其他网站可以读取A网站的Cookie,会发生什么?很显然,如果Cookie包含隐私(比如存款总额),这些信息就会泄漏。更可怕的是Cookie往往用来保存用于的登录状态,如果用户没有退出登录,其他网站就可以冒充用户为所欲为,因为浏览器同时还规定,提交表单不受同源策略的限制。

补充一下,cookie一般做身份认证,cookie是客户端向服务端发请求时自带的,而在你进入恶意网站的一瞬间,恶意网站的js脚本就会执行,那他可以通过<img>来向A网站服务器发送一个请求,A网站服务器就误以为是用户的操作,或者通过<form>发送一个post请求,效果是一样的,试想如果恶意网站发送的请求是转账10万,后果可想而知

上面说了,SOP 可以通过 html tag 加载资源,而且 SOP 不阻止接口请求而是拦截请求结果,CSRF 恰恰占了这两个便宜。

所以 SOP 不能作为防范 CSRF 的方法。

  • 对于 GET 请求,直接放到<img>就能神不知鬼不觉地请求跨域接口。

  • 对于 POST 请求,很多例子都使用 form 提交

归根到底,这两个方法不报跨域是因为请求由 html 控制,你无法用 js 直接操作获得的结果。

SOP 与 ajax

对于 ajax 请求,在获得数据之后你能肆意进行 js 操作。这时候虽然同源策略会阻止响应,但依然会发出请求。因为执行响应拦截的是浏览器而不是后端程序。事实上你的请求已经发到服务器并返回了结果,但是迫于安全策略,浏览器不允许你继续进行 js 操作,所以报出你熟悉的 blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.。

所以再强调一次,同源策略不能作为防范 CSRF 的方法。

不过可以防范 CSRF 的例外还是有的,浏览器并不是让所有请求都发送成功,上述情况仅限于简单请求,相关知识会在下面 CORS 详细解释。

CSRF 对策

SOP 被 CSRF 占了便宜,那真的是一无是处吗?

不是!是否记得 SOP 限制了 cookie 的命名区域,虽然请求会自动带上 cookies,但是攻击者无论如何还是无法获取 cookie 的内容本身。

所以应对 CSRF 有这样的思路:同时把一个 token 写到 cookie 里,在发起请求时再通过 query、body 或者 header 带上这个 token。请求到达服务器,核对这个 token,如果正确,那一定是能看到 cookie 的本域发送的请求,CSRF 则做不到这一点。(这个方法用于前后端分离,后端渲染则可以直接写入到 dom 中)

跨域资源共享 CORS

跨域是浏览器限制,但是如果服务器设置了 CORS 相关配置,在返回服务器的信息头部会加上 Access-Control-Allow-Origin,浏览器看到这个字段的值与当前的源匹配,就会解锁跨域限制。

Accept-Ranges: bytes
Access-Control-Allow-Origin: *
Age: 0
Connection: keep-alive
Content-Length: 73
Content-Type: application/json;charset=UTF-8
Date: Fri, 14 Feb 2020 08:49:14 GMT
Set-Cookie: aliyungf_tc=AQAAAOqu0AYWRAsAh470eGjRMNY7tVXP; Path=/; HttpOnly
Via: 1.1 varnish
X-Cache: 10.0.0.4MISS120.244.142.135, 47.111.193.22, 100.97.58.25,10.0.0.29
X-Varnish: 223066077

对于 CORS,请求分两种。

简单请求

  1. 请求方法使用 GET、POST 或 HEAD

  2. Content-Type 设为 application/x-www-form-urlencoded、multipart/form-data 或 text/plain

符合上面两个条件的都为 CORS 简单请求。简单请求都会直接发到服务器,会造成 CSRF。

预检请求

不符合简单请求要求的请求都需要先发送预检请求(Preflight Request)。浏览器会在真正请求前发送 OPTION 方法的请求向服务器询问当前源是否符合 CORS 目标,验证通过后才会发送正式请求。

例如使用 application/json 传参的 POST 请求就是非简单请求,会在预检中被拦截。

再例如使用 PUT 方法请求,也会发送预检请求。

上面提到的可以防范 CSRF 的例外,就是指预检请求。即使跨域成功请求预检,但真正请求并不能发出去,这就保证了 CSRF 无法成功。

CORS 与 cookie

与同域不同,用于跨域的 CORS 请求默认不发送 Cookie 和 HTTP 认证信息,前后端都要在配置中设定请求时带上 cookie。

这就是为什么在进行 CORS 请求时 axios 需要设置 withCredentials: true。

顺带一提,Access-Control-Allow-Credentials设为true时,Access-Control-Allow-Origin 强制不能设为 *,为了安全