WEB前端安全之同源策略
如果无法正常显示，请先停止浏览器的去广告插件。
1. CLICK TO EDIT MASTER TITLE STYLE
2. WEB前端安全之同源策略
香草
3. 个人简介
ID：香草
• 现任四川电科网安科技有限公司，御风网络安全实验室负责人
• 擅长WEB渗透、java漏洞挖掘、WEB前端漏洞挖掘与利用，曾披露过Strtus2框架漏洞、各
大邮箱XSS漏洞等，目前从事红队攻防与反网络犯罪方面的研究工作
4. WEB前端安全之同源策略 目录
一、同源策略的概念
二、不同场景下的跨域特性总结
三、CSP策略
5. 一、同源策略
6. 什么是同源策略？
同源策略（SOP）是浏览器中非常核心的安全功能，主要是为了进行文档（DOM）数据隔离，
避免不同页面之间的数据污染。XSS漏洞利用的本质实际上就是和同源策略的玩耍。
➢ 如果协议、端口和域名对于两个页面是相同的，则两个页面具有相同的源（IE列外，IE忽
略端口），同源页面之间的JS可以访问彼此的DOM。
➢ 除非javascript所处的两个页面的协议、域名、端口都完全一致，否则两个独立的
javascript运行环境不能访问彼此的DOM。
7. 同源策略举例
举例：原始页面 http://a.qq.com/aa/a.php
http://a.qq.com/bb/b.php 同协议、端口、域名-同源
https://a.qq.com/aa/a.php 不同协议-不同源
http://b.qq.com/aa/a.php 不同域名-不同源
http://a.qq.com:8080/aa/a.php 不同端口-不同源（IE同源）
思考：如果我们一定要在不同源之间的页面传输消息怎么办？
8. 二、不同场景下的跨域特性总结
9. 2.1 domain的安全问题
为了解决不同数据源数据传输的问题
➢ 允许两个拥有相同二级域名的相关网站，协商认可彼此
的同源检查
domain的修改策略
• 可以设置成非顶级域名，如qq.com，但是不能设置为
com
• chrome允许随意修改，firefox和IE只允许向下修改（向
顶级域名修改）
如：xx.a.qq.com->qq.com->a.qq.com chrome允许，
firefox不允许。
10. 2.11 domain的继承
➢ about:blank
<iframe src="about:blank">
• webKit内核浏览器继承发起页面的domain，IE和Firefox独一无二的domain
• window.open("about:blank"),weibKit、IE、Firefox都是继承发起页面的domain
• 修改发起页面的domain相当于修改about:blank的domain，反之也成立
➢ data:text/html;，各个浏览器都是拥有独一无二的domain
➢ iframe srcdoc，继承发起页面的domain
不同浏览器有略微差异
11. 2.12 domain跨域技巧
产生的安全问题：
• 任何子域的安全问题（主要是XSS漏洞），将影响其他设置了domain的页面
• 如果http://mail.qq.com/a.html->domain='qq.com'，那么http://*.qq.com域下任意一个
xss漏洞将导致跨域数据获取问题
攻击流程
思考：不同二级域名(如：qq.com和baidu.com)之间的页面怎么传输消息？
12. 2.13 domain的共享策略
对http://a.qq.com/aa/a.php和http://b.qq.com/aa/a.php
进行document.domain="qq.com"，则两个页面具有了相同的源
注意：设置了domain的页面不能访问未设置domain的页面，反之亦然
• http://a.qq.com->domain='qq.com'，访问http://qq.com->domain未设置，访问失败
• http://a.qq.com->domain未设置，访问http://a.qq.com->domain='qq.com'，访问失败
• http://a.qq.com->domain未设置，访问http://a.qq.com->domain='a.qq.com'，访问失败
13. 2.2 window .name
➢ name值是窗口级的变量，即使页面网址变化name值也不变，可用作跨域数据传输
➢ 产生的攻击场景
攻击向量长度限制绕过，如eval(name)
window.write(name)
<iframe name=“alert(11)”src=”xss.html”></iframe>
➢ 产生的思考，如果每次要跨域传输数据都需要这样操作，是不是略显麻烦？
有没有更好的办法？
14. 2.3 JSONP
这是一种很巧妙的跨域资源共享
但是也带来JSON劫持、敏感信息泄露的问题
我仅仅访问了对方发过来的一个页面，为什么我的个人信息就泄露了？
15. 2.3 JSONP
攻击场景
1）完全无验证
2）加入token验证，如果token不变先通过referer盗取token然后盗取json
3）加入referer验证，referer可伪造为空
思考
这种方式的跨域资源共享，确实是优雅不少，而且没有违背同源策略。
但是有么有更直接方便的方式呢？
16. 2.4 ajax
ajax 主要是实现页面和 web 服务器之间数据的异步传输
• 通过XMLHttpRequest对象与远程的服务器进行信息交互
• 跨域资源共享，CORS，Cross-origin resource sharing
通过设置Access-Control-Allow-Origin返回头的方式指定某个页面不受跨域资源限制可
以设置为*，设置*是最简单粗暴的，但是出于安全考虑，如果是*的话，游览器将不会发
送cookies，即使你的XHR设置了withCredentials，因此很多程序员为了方便实现共享，
就根据请求来源动态的添加返回头，这也造成了数据安全问题。
思考
还有没有更方便的方式实现跨域资源共享？可以实时通信？
17. 2.5 postMessage
为了解决不同二级域名之间页面数据传输问题
安全问题：
origin判断错误，或者没有判断，导致数据
污染，从而产生其他问题，如：直接
eval(e.data)
攻击场景：
伪造一个发送端，利用opener或者iframe
获取句柄，发送污染数据，如：
主动打破同源策略（前提需要获取目标页面句柄）
opener.postMessage("alert(111)","*");
18. 2.6 location
window.location==document.location==window.document.location
location.href的值可以跨域修改，但是不能跨域获取。
攻击思路
• 可以利用top.window.location.href="http://xxx.com"跨域修改顶层窗口的URL链接
• 可以利用opener.window.location.href="http://xxx.com"跨域修改打开链接的原窗口的URL链接
• 从而实施钓鱼攻击或者盗取window.name
19. 2.7 cookie
Cookie是存储是浏览器上的一小段名值段的数据，一般会用做鉴定权限，如果cookie被攻击者获取，那
么攻击者就可以伪造成受害者的身份发起请求，这叫会话劫持。xss攻击的目的之一就是获取对方的认证
cookie。因此围绕着cookie的安全浏览器也做了很多防御措施。
➢ 比如为了防止JS读取cookie的http-only属性
➢ 为防止DNS劫持导致的https网站cookie盗取的Secure属性
➢ 为了及时销毁cookie的Expires属性
➢ 为了限制跨域获取和设置cookie的domain属性
➢ 为了限制跨域发送cookie的sameSite属性
20. 2.71 cookie-domain
cookie中的同源策略
• Cookie domain是指服务端返回头：set-cookie头设置的域，或者js设置的域。
• Cookie的设置，如设置a.qq.com的cookie的domain。
设置情况 效果
完全未设置 精确匹配a.qq.com，只有在a.qq.com域下才能获取到该cookie
设置为aa.a.qq.com 不同域，设置不成功
设置为a.qq.com 匹配*.a.qq.com，a.qq.com以及它的子域下都能获取到该cookie
设置为qq.com 匹配*.qq.com，qq.com以及它的子域下都能获取到该cookie
设置为baidu.com 不同域，设置不成功
21. 2.72 cookie-sameSite概念
sameSite的出现本质是为了限制cookie在三方网站的的发送，从根本上解决csrf和jsonp劫持的问题，
并且对于随意嵌套iframe的xss默认情况下也无法成功的获取cookie。sameSite有三个等级Strict、
Lax(默认)、None
等级 说明
Strict 只有当Cookie的网站与浏览器的网址栏中当前显示的网站相匹配时，才会发送
Cookie
Lax 安全的顶级跳转（可发送COOKIE），如点击链接，GET表单提交，JS调用
window.open等方式产生的跳转请求，JS修改Location对象产生的跳转请求
网址相同-可发送COOKIE
其他情况不发送，如不同域的图片加载，iframe加载等
None 不受任何限制
22. 2.73 cookie-sameSite，对攻击方式的影响
sameSite对攻击方式的影响
• JSONP劫持基本没得玩儿了，当然，这会影响到正常功能，所以开发者不得不把sameSite设置为
None，又是一种矛盾。
• 对XSS攻击本身没影响，但是影响利用方式，如iframe嵌入目标网站来触发XSS这样的方法将无法获
取cookie。
• DNS劫持之https-cookie偷取，默认情况下也没得玩儿了。
• CSRF基本也废了，当然同源的情况不影响。
23. 2.8 localStorage
➢ 在浏览器实现了一种简单的数据库
➢ localStorage，关闭浏览器之后仍然有效
➢ sessionStorage，浏览器会话结束后会被清理
➢ 修改和获取遵循同源策略，但是不受document.domain的影响
攻击场景
24. 三、CSP策略
25. 3.1 CSP策略
CSP（Content Security Policy）指的是内容安全策略 ，是一个附加的安全层，用于帮助检测和缓解某
些类型的攻击，包括跨站脚本攻击 (XSS) 和数据注入等攻击。
CSP的设置方法，参考https://bbs.pediy.com/thread-267389.htm
26. 3.2 CSP语法
27. 3.3 CSP的绕过
CSP，内容安全策略， Content-Security-Policy
➢ 继承，<iframe src="about:blank"></iframe>和<iframe srcdoc="xxx"></iframe>都是继承父
级页面的CSP
➢ CSP是基于页面返回头的策略，很多网站都没有配置全局CSP策略，比如图片地址或者不存在页面基
本上没有设置CSP
防御方法
设置document.domain=location.host，根据document.domain的特性，如此就无法把代码注入到
没有设置documen.domain的页面
28. 3.4 总结
前端漏洞挖掘和漏洞利用技巧基本都和同源测试有着千丝万缕的联系，同源策略的就好比前端武学的内功
心法，参透它一定能使你功力大增！
同源策略的世界异常精彩，更多有趣的东西等着大家去研究……