XSS攻击-跨域技巧
2019-12-20 13:48:45 0 举报AI智能生成
WEB前端XSS攻击基础，跨域基础，同源策略详解
作者其他创作
大纲/内容
同源策略
概念
为了进行文档（DOM）数据隔离，避免不同页面之间的数据污染
同源策略(SOP)是浏览器的一个核心安全功能，
除非javascript所处的两个页面的协议、域名、端口都完全一致
否则两个独立的javascript运行环境不能访问彼此的DOM
除非javascript所处的两个页面的协议、域名、端口都完全一致
否则两个独立的javascript运行环境不能访问彼此的DOM
如果协议、端口和域名对于两个页面是相同的，
则两个页面具有相同的源（IE列外，IE忽略端口），同源页面之间的JS可以访问彼此的DOM
则两个页面具有相同的源（IE列外，IE忽略端口），同源页面之间的JS可以访问彼此的DOM
举例：原始页面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同源）
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同源）
伪协议：data、javascript等不适用这个规则，这里会产生很多有意思的漏洞（这里不展开）
源的继承-将会在伪协议中讨论
file协议，这里不展开
产生的思考
不同源（域）之间的页面怎么传输消息
跨域资源获取
(同源策略的衍生)
(同源策略的衍生)
document.domain
为了解决不同源数据传输问题
允许两个拥有相同二级域名的相关网站，
协商认可彼此的同源检查
协商认可彼此的同源检查
domain的修改策略
可以设置成非顶级域名，如qq.com,但是不能设置为com
那是否可以设置国家级域名，如aaa.sina.com.cn，是否可以设置为com.cn，那整个
国家都是我的了，真是个机灵鬼，答案是com.cn也算顶级域名，但是这里不同的
浏览数实现上就出现了混乱
国家都是我的了，真是个机灵鬼，答案是com.cn也算顶级域名，但是这里不同的
浏览数实现上就出现了混乱
如：对http://a.qq.com/aa/a.php和http://b.qq.com/aa/a.php
进行document.domain="qq.com"则，两个页面具有了相同的源
进行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'，访问失败
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'，访问失败
产生的思考
不同二级域名(如：qq.com和baidu.com)之间的页面怎么传输消息
产生的安全问题
任何子域的安全问题（主要是XSS漏洞），将影响其他设置了domain的页面
如果http://mail.qq.com/a.html->domain='qq.com'
那么http://b.a.qq.com域下任意一个xss漏洞将导致跨域数据获取问题
那么http://b.a.qq.com域下任意一个xss漏洞将导致跨域数据获取问题
攻击方式：攻击者自己的页面http://www.attack.com通过iframe嵌入存在xss漏洞的页面，
设置http://b.a.qq.com->domain='qq.com',再iframe目标页面http://mail.qq.com/a.html
通过contentDocument进行DOM操作
设置http://b.a.qq.com->domain='qq.com',再iframe目标页面http://mail.qq.com/a.html
通过contentDocument进行DOM操作
self-xss，代码回注，变废为宝，XSS后门
window.postMessage
为了解决不同二级域名之间页面数据传输问题
前提需要获取目标页面句柄
parent.window.postMessage
opener.window.postMessage
.....
window.onmessage监听
onmessage=function(e){e.orgin,e.data}
orgin：发送方的源
data：接收到的数据
window.postMessage发送
postMessage(message, targetOrigin)
message：发送的数据
targetOrigin：设置接收方的源
遵循同源策略，但是不受window.domain影响
产生的安全问题
onmessage端的问题
origin判断错误，或者没有判断，导致数据污染，从而产生其他问题
如：直接eval(data)
如：直接eval(data)
攻击方式
postMessage端的问题
如：orgin设置为*，导致获取敏感信息
攻击方式
Ajax跨域
ajax 主要是实现页面和 web 服务器之间数据的异步传输
通过XMLHttpRequest对象与远程的服务器进行信息交互,并且受同源策略约束，
但是不受document.domain的影响
但是不受document.domain的影响
产生的思考
不同源之间的页面怎么传输数据
跨域资源共享
（CORS，Cross-origin resource sharing）
（CORS，Cross-origin resource sharing）
Access-Control-Allow-Origin
可以设置为*，设置*是最简单粗暴的，
但是出于安全考虑，如果是*的话，
游览器将不会发送cookies，即使你的XHR
设置了withCredentials
但是出于安全考虑，如果是*的话，
游览器将不会发送cookies，即使你的XHR
设置了withCredentials
withCredentials
默认为false
默认不会发送cookie也不会响应set-cookie头
JSONP
更取巧的跨域资源共享
带来的问题，JSON劫持，敏感信息泄露
window.name、window.open、location、parent等同源策略之外的相关问题单独讲，这里不详细展开
document.cookie
基本特性
浏览器发送cookie不管请求来源（document.referrer）
COOKIE的出现早于同源策略，因此浏览器实现中会有很多问题
关于document.referrer可以单独出个专题
a.qq.com的
Cookie的设置
Cookie的设置
domain属性
Cookie域是指服务端返回头：set-cookie头设置的域,或者js设置的域
完全未设置，精确匹配a.qq.com
设置为aa.a.qq.com,设置不成功
设置为a.qq.com，匹配*.a.qq.com
设置为qq.com，匹配*.qq.com
设置为baidu.com，设置不成功
path属性
设置配aa/a.html，必须匹配aa/a.html才会发送cookie
http-only属性
javascript不可读取cookie
Secure属性
https页面才允许发送cookie
产生的安全问题
CSRF（Cross Site Request Forgery）
跨站点请求伪造，本质也是跨域问题，
这个可以单独出一个专题，这里不展开
这个可以单独出一个专题，这里不展开
DNS劫持之https-cookie偷取，本质也是跨域问题，可以单独出个专题，这里不展开
javascript跨域获取cookie
本质是document.domain的攻击方式，
需要注意Cookie的domain与path的匹配规则
需要注意Cookie的domain与path的匹配规则
proxy.html
domain='qq.com'，很多网站提供的proxy页面
cookie作为认证机制，能获取cookie就等同于绕过同源策略了
cookie覆盖之Self-XSS
localhost.yahoo.com这种指向127.0.0.1的域名带来的安全问题
cookie与“合法”DNS劫持（运营商劫持）带来的问题，可以单独开专题，这里不展开
window.localStorage
在浏览器实现了一种简单的数据库
localStorage,关闭浏览器之后仍然有效
sessionStorage,浏览器会话结束后会被清理
遵循同源策略,但是不受document.domain的影响
产生的安全问题
XSS后门攻击，这个可以单独出个专题，这里不展开
flash的同源策略，鉴于chrome默认已经不支持flash就不细说了
CSP
内容安全策略， Content-Security-Policy
同源策略的坚实维护者，XSS攻击终结者？
跨域内嵌资源
标签
script
img
css
embed
iframe
X-Frame-Options
......
CSP绕过
CSP是基于页面返回头的策略
找到一个没有设置CSP的页面即可，CSP形同虚设
很多网站都没有配置全局CSP策略
未完待续，by 香草
0 条评论
下一页
