您的位置:首页 > 其它

[漏洞研究]配合XS-leaks进行CSRF利用

2022-03-14 11:42 489 查看

配合XS-leaks进行CSRF利用

XS-leaks

倒腾下

可以看到有些缓存,有些不缓存,为了实验效果,先设置为缓存吧

可以看到都缓存了,现在就是来进行探测了。

function test() {
// let win = open("http://123.60.29.171:10001/search?q=SUSCTF{"+ c )

let win = open("http://127.0.0.1/")
// setTimeout(()=>{win.location="http://127.0.0.1/"}, 1)
setTimeout(()=>{
console.log(win.history.length)
if(win.history.length === 1)
{
fetch("http://127.0.0.1/success")
}
}, 1000)
}

先利用加载一次,进行缓存,这个时候,再去访问,由于有缓存,所以可以立即打开,窗口历史数就为1,所以就会近些那个成功的访问,也就下面触发的success.

前端:缓存判断时,先判断url,看url是否完全匹配,再看过期时间。有些是后端可控制缓存,参考cdn缓存的性质,后端可控前端缓存是否有效 但好像不匹配官方wp中的自动补充后置位,进行逐个字符匹配,如果是这样的话,只能完全爆破到完全一样才可以,但这样和爆破就没啥。肯定是哪儿有问题 https://github.com/susers/SUSCTF2022_official_wp/blob/main/checkin %26 ez_note %26 rubbish_maker_zh.md 官方给的是说支持正则,试了一下,好像不支持正则啊。。。难不成是题目后端处理时,进行了正则匹配???

结束了,搞了好久才发现这里能进行正则探测是因为后端支持或者数据库之类的支持正则匹配,才能进行这样的探测,所以利用XS-leaks进行csrf利用是几乎不可能的。

http://retr0.vip/archives/3/

有关url的相关介绍https://www.zhangxinxu.com/wordpress/2019/08/js-url-urlsearchparams/ ,其中最关键的就是

语法 var myUrl = new URL(url, [base]) 参数 url 相对地址或者绝对地址。如果是相对地址,需要设置base参数,如果是绝对地址,则会忽略base设置。我们也可以使用URL对象作为url参数。此时作用的值是URL对象中的href属性值。 base 如果URL地址是相对地址,则需要这个参数,作用是作为相对计算的基础地址。我们也可以使用URL对象作为base参数,此时作用的值是URL对象中的href属性值。如果不设置该参数,则会按照空字符串''进行处理。 如果参数值无法组合成完整URL地址,则会报TypeError错误。

由此开展重学前端攻防技术。。。

同源策略

是浏览器设计的一个安全策略,在访问url时会通过比对schema,host,port来判断是否同源,再把符合同源策略的信息(:如cookie等填充到请求头中进行发送,完成请求。

看了很多文档介绍,发现浏览器实现同源策略是基于document.domain来判断是否同源的。那为什么不利用js直接修改掉document.domain为恶意的domain呢,这样不就可以进行恶意携带cookie等重要信息了。 这种操作是不允许的。但浏览器为了实现跨域访问,如去父域获取一张图片等,如果还是这种策略就不行,但为了保持同源策略,所以浏览器产商允许规范得修改document.domain. 这里允许将其修改为除了顶级域得其他父域,就是通过检测是否完全符合其suffix的特性。chorme种还可以修改为原来的domain,但后来尝试了firefox的,就貌似标准实现不一样 firefox中的就不允许修改回原来的域,只能不断往父域跳。这里的edu.cn也是顶级域,所以才会是显示修改失败。

既然同源策略防御得这么好,那又是为什么可以绕过呢?

其实就是浏览器厂商在设计时的,对于iframe,embad等特殊标签没做同源校验,或者做了校验,但允许部分情况通过校验。

由需求牵动出了CORS-Cross Origin Resource Share

首先思考浏览器具体是怎么判断是否同源的呢?怎么样绕过同源策略实现跨域呢?

其实看了相关的介绍,是可以通过js修改document.domain来修改源的,但有限制只能是修改为基域,或者说是父域。修改后,下次访问就可以实现跨域。但这样很麻烦而且还受限制

但CORS是通过相互协商进行的。

通过设置 - Access-Control-Allow-* 让浏览器来判断资源的跨域共享

CORS的背后基本思想就是使用自定义的HTTP头部让浏览器与服务器进行沟通,从而决定请求响应是应该成功还是应该失败。

服务端代码设置Header返回头告诉浏览器“谁谁谁是允许访问我的,你看到这家伙就给我放行吧~“。

当Http请求发起(可以通过更新操作去测试POST,或者用JavaScript请求测试GET)的时候(不分跨不跨域)会类似带着以下请求头信息:

Origin:http://www.csdnblog.com

返回头也会夹带着类似如下信息:

Access-Control-Allow-Credentials:true
Access-Control-Allow-Origin:http://www.csdnblog.com

一来一回的请求决定的请求决定了改请求是否会被浏览器通过,如果返回头中没有这个头部,或者有头部但是源信息不匹配(就是说返回头%-Allow-Origin中没有当前请求站点的域名),那么浏览器就会帮我们驳回这次请求,同源策略在这里发挥了作用。

小结

说了那么多,无非就是浏览器通过源设置了对应的独立的空间,彼此访问需要受限制。但有的时候需要在允许访问和不允许访问之间做一个平衡,这就是前端的攻防内涵。

Reference

https://developer.mozilla.org/zh-CN/docs/Web/Security/Same-origin_policy https://blog.z3ratu1.cn/SUSCTF2022%E5%87%BA%E9%A2%98%E7%AC%94%E8%AE%B0.html

内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: