前提条件HTML注入：别让“安全前置”变成摆设，我的血泪教训！
哎,说出来都是泪啊！上周我负责的一个内部系统差点被脱库，原因居然是——前提条件HTML注入，你可能会问，啥叫“前提条件HTML注入”？别急，听我慢慢吐槽，这事儿真不是危言耸听，咱们搞安全的，最怕的就是这种“看着没问题，一挖全是洞”的情况。
前提条件没设好，注入就是“白给”？
咱们先聊聊啥是“前提条件”，说白了，就是你写代码时，对用户输入的数据做了哪些“先决检查”——比如长度、类型、格式、黑白名单，可悲的是，很多开发兄弟觉得“HTML实体化一下”就完事儿了，但前提条件这关没把严，后面全是坑！
我那次遇到的漏洞,就是开发在搜索框里做了“转义输出”，但前提条件是“仅当输入包含尖括号时才转义”，结果呢？攻击者用<img src=x onerror=alert(1)>的变形写法，比如<img src=x onerror=alert(1)（少一个大括号）——嘿，前提条件直接绕过了！最后变成存储型XSS，管理员一登录就中招，你说气不气人？！
拟人化复盘：那晚我差点把浏览器砸了
我记得那天晚上排查日志,看到一堆乱七八糟的<svg/onload=...>请求，心脏都漏跳了一拍，我揪着头发想：“这前提条件咋能只认标准标签呢？” 更崩溃的是，过滤规则还只针对<script>，其他标签一概不管！你说这就像给小偷留了后门——你不设“禁止翻窗”的前提，他能不爬吗？
所以啊,前提条件HTML注入的根源，信任了不该信任的输入”，我们总以为用户会乖乖按规范填表单，可现实呢？攻击者连%3Cscript%3E这种URL编码都用上了，如果前提条件没解码后再校验，那可不就是“裸奔”嘛！
怎么设好“前提条件”？我的三条血泪建议
第一，别只做“输出编码”，得做“输入验证”！ 你可以在后端设前提条件：必须纯中文、长度≤20、禁止任何HTML标签（用白名单方式只允许<p>、<br>），但记住，验证逻辑千万别和“是否包含<”挂钩，因为变体太多了！要认准“只要不是白名单里的字符，一律拒绝”，这才是硬前提。
第二，上下文敏感的输出前提！ 如果数据要放到<div>里，那HTML实体化没问题；但如果插到<a href>或<script>里呢？光实体化可不够，还得考虑URL编码、JS转义，这就叫前提条件分场景设置——不能一个过滤器走天下啊亲！
第三，安全测试必须“恶意化”！别老用正常数据测，我那天就用Burp随便改了改请求头，把User-Agent都塞了<iframe src=javascript:alert(1)>，结果... 嘿，居然弹窗了！这就说明，前提条件根本没把“非表单字段”当回事，哎，真是一朝被蛇咬，十年怕井绳。
别让“前提”变成“坑前提”
现在的我,看到任何用户输入都条件反射地问：“前提条件真的严谨吗？” 如果开发说“我们做了转义”，我一定会追问：“哪里的转义？所有上下文都覆盖了吗？编码前还是解码后？” 真的，太容易出问题了！稍不留神，前提条件HTML注入就能让你辛辛苦苦的防护瞬间崩塌。
所以啊,各位小伙伴，安全开发的核心就是“前提前置”——把所有可能被绕过的路都堵死，就像我师傅说的：“你永远不知道黑客有多变态，但你可以为自己的代码设下‘前提条件’——该拒绝的绝不手软！”
最后送大家一句话：别让你的前提条件，变成黑客的注入乐园！ 咱们共勉吧！
📌 学习网络安全可以加QQ：3382688695 （备注“博客安全学习”） 一起交流踩坑经验，互相避雷！
