存储型XSS漏洞的存储形成，根子上就一句话：**开发者把用户输入当成了代码来信任，型x形成而不是漏洞当数据来处理。** 这话听起来简单，存储但拆开看，型x形成全是漏洞细节上的疏忽。

拿个真实例子说。存储某论坛的型x形成签名档功能，允许用户填写一段个人简介。漏洞开发者在后端做了长度限制和敏感词过滤，存储但没对HTML标签做转义。型x形成用户提交的漏洞简介里写``，系统原样存进数据库。存储等别的型x形成用户点开这个人的主页，浏览器解析这段签名档时，漏洞直接把script标签当代码执行了。就这么一下，所有访问者的cookie被偷走，攻击者拿着cookie就能冒充登录。

漏洞的起点在“存储”这一步。很多系统为了性能或便利，把用户提交的内容直接拼进数据库字段，不经过任何编码转换。这时候数据库里存的是“纯文本+HTML混合体”，而不是“纯文本”。等到输出阶段，页面模板把数据库内容原样渲染到HTML文档里，浏览器分不清哪部分是用户数据、哪部分是页面结构，于是一起当作HTML解析。攻击者只要在输入里塞进合法的HTML标签，就能劫持页面逻辑。

但光说存储和输出脱节还不够。更隐蔽的原因是**上下文混淆**。同一个用户输入，在不同位置输出，风险完全不同。比如用户填了个用户名，如果这个用户名出现在``里，那攻击者得用`" onfocus="alert(1)`这类属性逃逸手法；如果用户名出现在``里，就得用`" onclick="`或者`javascript:`协议。开发者往往只对输入做一次全局过滤，比如把`