富文本内容易引发二次sql注入，因其允许html、引号等危险字符入库后看似安全，但被取出拼入新sql时若未再次参数化，便会触发攻击；核心在于数据复用路径中校验缺失。
富文本编辑器上传的内容本身不会直接触发二次SQL注入，但一旦这些内容被取出、拼进新SQL语句（比如用于搜索、统计、日志归档等场景），就可能成为二次注入的温床。核心问题不是“编辑器多危险”，而是“你后续怎么用它存的数据”。
为什么富文本内容特别容易引发二次注入
富文本字段（如 content、description）通常允许用户输入 HTML 标签、引号、分号、注释符甚至 JavaScript 片段。这些字符在入库时若只做简单转义或未用参数化查询，看起来“安全”；但当某天业务需要按内容关键词模糊搜索、导出带条件的报表、或批量更新关联状态时，代码里很可能出现类似这样的拼接逻辑：
sql = "UPDATE posts SET status = 'archived' WHERE content LIKE '%" + user_input_keyword + "%'"
——而这个 user_input_keyword 正是从数据库里查出来的某个富文本字段值。这时，哪怕当初入库时用了 mysqli_real_escape_string()，也拦不住它在第二次执行时被当作 SQL 语法解析。
- 富文本内容常被开发者默认为“只读展示”，忽略其作为查询条件的潜在用途
- 前端富文本组件（如 TinyMCE、Quill）默认不阻止 SQL 元字符，也不提供服务端校验钩子
- 很多 CMS 或后台系统会把富文本字段用于全文检索、标签提取、摘要生成等二次处理，这些环节极易漏掉参数化
入库时必须用参数化查询，且不能依赖客户端过滤
别信前端对 <script></script> 或单引号的拦截。攻击者可以绕过 JS 校验直接发 POST，或利用编辑器的“源码模式”粘贴恶意字符串。入库唯一可靠的方式是：无论来源是否可信，一律走预编译。
- PHP 中必须用
mysqli_prepare()或 PDO 的prepare()+bind_param()，禁用mysqli_real_escape_string()拼接 - Node.js 的
pg或mysql2库，必须用client.query('SELECT ... WHERE title = $1', [title])这类占位符写法 - Java 的
PreparedStatement同理，setString(1, content)是底线，executeUpdate("... '" + content + "'")是红线
从数据库读出后，再用于 SQL 查询前必须重新参数化
这是最容易被跳过的一步。很多人以为“入库安全了，取出来就安全了”，但二次注入恰恰发生在“取出→拼接→执行”这个链路。只要富文本字段值参与了任何 SQL 构建，就必须再次参数化。
- 例如：你要根据某篇文章的
content字段匹配其他文章的相似内容，不能写"WHERE other.content LIKE '%" + dbContent + "%'" - 正确做法是统一用占位符：
"WHERE other.content LIKE CONCAT('%', ?, '%')"，然后把dbContent作为参数传入 - 如果必须动态构造表名或列名（极不推荐），只能用白名单严格限制，绝不能拿数据库字段值去拼接
额外但关键的防护层：存储时剥离可执行上下文
参数化解决的是“执行时被解析为代码”的问题，但富文本本身还涉及 XSS、模板注入等风险。建议在入库前做轻量净化，不是为了防 SQL 注入，而是降低后续误用概率：
- 用
strip_tags()（PHP）或DOMPurify.sanitize()（JS）移除 script/style 标签，保留 p/br/em 等安全标签 - 对所有属性值（如
href、onclick）做 URL 编码或白名单校验，避免 javascript: 协议 - 不要用正则全局替换引号或分号——这既无效又易被绕过，反而干扰正常内容
真正难防的不是富文本本身，而是开发过程中对“数据复用路径”的忽视。一个字段今天只用于渲染，明天可能被拿去 join、group、甚至生成临时视图。只要它进过 SQL 执行引擎，就得按参数化规则走完每一程。
