为什么黑客钟爱这个函数「include.《》」
这个实验针对一款把用户提交内容直接反射到页面的Web应用：
后端仅在字符串里用String.prototype。includes检测是否含有< >，然后原样输出。
攻击者借助Burp的Content-Type Converter把原本的表单数据改写成application/json格式，将输入封装为数组并发送。
在线学习：
https://www.bilibili.com/video/BV1h731zZETz
服务器因未校验数据类型，调用的是Array.prototype.includes；
它只检查元素本身而不会在元素内部逐字搜索，因此数组中的：
<img src=x onerror=alert(1)>字符串逃过了过滤，被浏览器插入DOM并立即触发XSS。
根因属于类型混淆漏洞。
如果过滤逻辑假设输入恒为字符串却缺少typeof等类型检查，攻击者就能通过JSON、URL参数或表单提交数组/对象来绕过黑名单；
当框架（如Express）自动把JSON解析为对象时，风险更高。
JavaScript中许多方法在String与Array上同名但行为不同，includes就是典型案例；
只要输入非字符串，比较与转义策略就会失效。此外，原本为防御而添加的字符串→HTML直写操作在这种情况下反而把恶意标签序列化进页面，触发跨站脚本。
防护需要在解析和输出两端同时加强：首先对req.body、req.query等入口做严格类型验证，拒绝非字符串；
随后统一使用成熟的转义或模板引擎处理输出，决不可依赖手写黑名单。
所有返回JSON的接口应设置Content-Type: application/json并加X-Content-Type-Options:nosniff，配合内容安全策略CSP限制脚本来源，防止浏览器把数据当HTML执行。
OWASP与PortSwigger的绕过清单展示了字符过滤的局限，社区案例也提醒开发者在任何包含检查前都应确认输入类型，否则一点点类型混淆就可能让攻击者轻松植入脚本。
评论区聊聊你的想法吧{:10_330:}
https://xxx.ilovefishc.com/forum/202505/12/120451wiv7viv5iebupbbr.png
>>万能兑换C币许愿池<<
如果有收获，别忘了评分{:10_281:} ：
https://xxx.ilovefishc.com/forum/202011/20/092334ggd6inlzfisfrdir.png.thumb.jpg
https://xxx.ilovefishc.com/forum/202505/21/111710rvxgdn90vaub5gag.gif 感谢分享 朕又在鱼C学到东西啦！非常满意{:10_275:} 感谢分享 朕又在鱼C学到东西啦！非常满意{:10_275:} 感谢分享 朕又在鱼C学到东西啦！非常满意{:10_275:} 感谢分享 朕又在鱼C学到东西啦！非常满意{:10_275:} 感谢分享 朕又在鱼C学到东西啦！非常满意{:10_275:} 小甲鱼 发表于 2025-7-8 18:06
感谢分享 朕又在鱼C学到东西啦！非常满意
{:10_288:}{:13_438:}{:10_288:}{:13_438:}{:10_288:}{:13_438:} 感谢分享 朕又在鱼C学到东西啦！非常满意{:10_275:}
页:
[1]