绕过waf实现某bc网站的xss攻击
当时光顾着爽了，部分截图忘截了，师傅们见谅🙏
打开官网，映入眼帘熟悉的界面
发现提示有新站，可以供用户访问
(这里讲解一下，菠菜网站一般是通过cdn来分出子域名，通过随机化子域名：生成如 s1.abc.com、s2.abc.com 等动态子域名，让每个子域名指向不同的CDN节点，分散监管机构的封禁难度。以及抗ddos等一些功能，提高服务的稳定性)
看起来是跟主站没有什么特别大的区别，果断测试一手
先测试其支付逻辑这里有没有什么问题，好消息是有问题，他们定义金额用的int，不是long 因为当我把vip值充的无限大时，导致了溢出(数字变成了字符+数字),但是价格依旧没有改变
OK，那我正经测试测试入侵漏洞吧，用了sql注入 id=1后面刚跟了一个',就被拦截了，我尝试了字符，没有拦截，于是我想到了ascii码，用了 ord(i),结果依旧403.放弃
我还是正经的去搜索一下好康的吧，万一有新鲜呢，果断搜索 "牛仔裤"，发现关键词显示在了 页面上 这种情况，结合我做ctf的经验 可以往 ssti模版注入和xss，但是我并不知道这个网站用的什么框架 用wappalyzer也并没有发现什么.用了一些测试语句也不行，那就试试xss吧
OK，给我拦截了，我一看，这不是我最熟悉的*塔防火墙嘛，于是尝试bypass防火墙
这里放出防火墙把我哪些语句拦截了 (javascript,script,alert(‘1’),onload,autofocus,onfocus,confirm)
但是，当我拿出<iframe>时，虽然拦截，但是明显看到空出一片区域。这么说只要在html中能生成白色输入框的语句，就可能bypass了，果断上<input>,没拦截，并且成功跳转百度
然后，我不敢放大部分截图的原因来了，他们立刻换上了cloudflare，而且是高防，emmmm，对面的应急也是反应迅速.....
这回虽然只是一个低危漏洞，但是我感觉知识点还挺多
首先就是 cdn分流生成子域名与动态ip的关系
（一）入口层（子域名）与传输层（IP）的分工
子域名：这里的作用就像一个“门面”，用户通过它来访问服务。它主要负责把流量分配到不同的地方，让请求看起来更复杂、更分散，从而吸引监管的注意力，起到混淆视听的作用。
动态 IP：在底层传输过程中的“跳板”，通过不断更换，隐藏真实服务器的位置，避免被轻易封禁或追踪溯源。
关联逻辑：子域名指向 CDN（内容分发网络）节点，然后 CDN 节点再通过动态 IP 池回源到真实服务器，形成“子域名→动态 CDN IP→动态源站 IP”这样的链式隐匿结构，层层保护真实服务器。
（二）动态化对抗静态封锁
子域名动态生成：每隔一段时间，就会生成新的子域名（如从 a1x.abc.com 变为 b5y.abc.com），旧域名废弃后自动切换。这样就能绕过域名黑名单，某些意义上提升了封禁的难度。
IP 动态轮换：CDN 节点和源站 IP 也会定期更换（比如每 12 小时更换一次），避免 IP 被标记或封锁。
协同效果：即使某个子域名或 IP 被封锁了，其他子域名和 IP 仍然可以正常维持服务，就像“打地鼠”游戏一样，这边堵住一个，那边又冒出来一个，具备很强的抗封锁能力。
二、技术实现中的关联性
（一）子域名与 CDN 动态 IP 的绑定
多 CDN 节点分配：每个子域名绑定到不同的 CDN 节点，而每个 CDN 节点又配置了多个出口 IP（动态 IP 池），这样就形成了一个复杂的网络结构。
举个例子
用户访问 s1.abc.com，DNS（域名系统）解析到 CDN 节点 A 的 IP（比如 1.1.1.1）。
CDN 节点 A 通过动态 IP 池（比如 2.2.2.2→3.3.3.3→4.4.4.4）回源到真实服务器，每次回源都会使用不同的 IP。
如果 IP 2.2.2.2 被封锁了，CDN 会自动切换至 3.3.3.3，用户完全察觉不到这个过程。
（二）动态 IP 支撑子域名快速切换
IP 池预配置：提前在 CDN 服务商那里配置好多个 IP（比如 100 个轮换 IP），每个子域名可以随机分配到不同的 IP 池，这样就增加了灵活性。
自动化切换
当子域名 s1.abc.com 关联的 IP 池被封禁时，系统会自动将该子域名指向备用 IP 池。
如果整个 IP 池都失效了，就会废弃当前子域名，生成新的子域名（比如 s9.abc.com），并绑定到新的 IP 池。
（三）流量混淆与多层跳转
子域名路径分流：通过子域名路径参数来伪装请求，比如 img.abc.com/path?data=不良信息，看起来像是普通的图片请求，但实际上是由 CDN 动态 IP 转发至赌博 API。
代理链回源：
CDN 节点接收用户请求（子域名：api.abc.com）。
CDN 通过动态 IP（比如 5.5.5.5）回源到第一层代理服务器。
第一层代理再通过另一动态 IP（比如 6.6.6.6）跳转到真实服务器，形成 IP 隔离，更难追踪真实服务器的位置。
三、对抗监管的联合策略
（一）DNS 层与 IP 层的双重隐匿
DNS 随机化：子域名使用随机字符串（比如 3g7d.abc.com），这样可以避免被模式匹配检测到，让监管难以发现规律。
IP 地理欺骗：CDN 节点 IP 动态分配到不同国家（比如从美国跳到日本，再跳到荷兰），伪装成跨国企业流量，增加追踪与查封的难度。
（二）加密与协议混淆
HTTPS 子域名：所有子域名都强制使用 TLS 加密，这样可以避免明文传输特征被识别，让监管更难获取有效信息。
WebSocket over CDN：通过子域名（比如 ws.abc.com）建立 WebSocket 长连接，利用动态 IP 传输bc数据，伪装成普通聊天流量，让监管难以察觉其真实用途。
（三）对抗 IP 封锁的容灾机制
IP 池健康监测：实时监控 CDN 节点 IP 的可用性，如果某个 IP 请求失败率突然飙升（可能被封锁），系统会自动将其移出 IP 池。
冷备 IP 池切换：当主 IP 池被封禁后，会立即启用未公开的备用 IP 池，并通过新子域名分配流量，确保服务的持续性。
流程图
（一）子域名与 CDN 动态 IP 绑定及切换流程
（二）流量混淆与多层跳转流程
（三）对抗 IP 封锁的容灾机制流程
还有就是我刚刚很兴奋的以为支付逻辑的溢出
一、什么是“溢出”（Overflow）？
溢出 顾名思义就是 超出所容纳的范围 这里也是一样，一个数值不幸超出了 int 的最大值范围，超出int类型在内存中占用的最大值(4字节，能表示的数值范围是 -2³¹ ~ 2³¹-1（约 -21.47亿 ~ 21.47亿）导致数值突然变为负数或者其他bug
二、场景中的溢出风险
（一）场景一：某音平台直播人数过多导致的溢出（超过 21.47 亿人）
假设在直播系统中用 int 来表示人。当观看直播的人数的金额超过了 21.47 亿人时，问题就来了。
问题示例:
int people = 2_147_483_647; // int 最大值（21.47 亿人）
people += 1; // 尝试加 1 人
结果：price 会瞬间变成 -2_147_483_648（即 -21.47亿人）。
（二）场景二：积分 / 优惠券累计
用户在平台长期积累积分，如果用 int 来存储总积分，也会出现类似的问题。
问题示例：用户已经积累了 20 亿积分，此时又获得了 3 亿积分。
int totalPoints = 2_000_000_000; // 20 亿积分
int addPoints = 300_000_000; // 3 亿积分
totalPoints += addPoints; // 预期 23 亿，实际溢出为 -1_294_967_296
结果：积分从正数突然变成了负数，用户原本期待着用积分兑换优惠券或者享受其他，直接用不了
战果截图 部分
