CodeIgniter过滤函数：remove_invisible_characters安全使用指南

CodeIgniter 的 `remove_invisible_characters()` 函数常被误认为是 XSS 或 SQL 注入防护工具，实则它仅用于粗略清理少数 ASCII 控制字符和宽松判定的无效 UTF-8 序列，既不处理零宽空格、Unicode 格式字符等现代绕过手段，也不转义 HTML、校验协议或防范注入——把它用在安全关键环节等于裸奔；真正安全的做法是分层防御：存库用预处理语句、输出 HTML 用 `html_escape()` 或 `htmlspecialchars()`、需富文本则引入 HTMLPurifier，而若不得不沿用该函数，务必将其置于过滤链最前端、禁用 `$url_encoded` 参数，并清醒认知它只是“清洁工”，绝非“守门员”。

这个函数不安全，别在敏感场景用它做 XSS 或 SQL 注入防护。

remove_invisible_characters 会删掉哪些字符

它主要清理 ASCII 控制字符（\x00–\x08、\x0B、\x0C、\x0E–\x1F、\x7F），以及 UTF-8 中的“无效多字节序列”——但判断逻辑很宽松，比如把 \xE0\x80\x80 这类看似非法、实则可能被某些解析器接受的序列也放过了。

• 它不处理 Unicode 格式字符（如 \u202E RTL 覆盖）、零宽空格（\u200B）等现代 XSS 常用绕过手段
• 对 UTF-8 的“修复”只是简单截断或替换为 ?，不是标准化重编码
• 原始实现里还硬编码过滤了 %00–%08、%0B、%0C、%0E–%20 这些 URL 编码片段，但只在 $url_encoded 为 true 时触发，而默认是 false

为什么不能靠它防 XSS

它设计目标是“让输入更干净”，不是“让输入可信任”。比如输入 完全不会被它动一下；再比如 javascript:alert(1) 里的冒号和括号全是可见字符，照常通过。

• 它不做 HTML 实体转义，不剥离标签，不校验协议白名单
• 在表单提交、JSON 解析、SQL 拼接前直接调用它，等于什么防护都没加
• CodeIgniter 3.x 中该函数被 xss_clean() 内部调用，但后者本身也已被官方弃用（CI 4 彻底移除）

替代方案怎么选

根据你真正要解决的问题来定，不是找一个“看起来像过滤”的函数顶包。

• 存数据库前：用预处理语句（$this->db->query() 配绑定参数），别拼 SQL 字符串
• 输出到 HTML：用 html_escape()（CI 3）或原生 htmlspecialchars($str, ENT_QUOTES, 'UTF-8')
• 需要更严格净化：引入 HTMLPurifier，配置好白名单规则，而不是依赖内置函数
• 验证手机号/邮箱等：用 filter_var() + 对应 FILTER_VALIDATE_EMAIL 等，比清洗更可靠

如果必须用，至少注意这三点

有些老项目一时改不动，得继续用它，那就得知道边界在哪。

• 永远把它放在过滤链最前面，而不是唯一一步——比如先 remove_invisible_characters()，再 trim()，最后 html_escape()
• 别传 true 给第二个参数（$url_encoded），它会对 %3Cscript%3E 这类做解码再清洗，反而可能触发二次解析漏洞
• CI 3.1.11+ 版本修复了部分 UTF-8 截断 bug，但没改核心逻辑，升级不能当安全补丁用

真正麻烦的从来不是函数调不调用，而是调用位置、上下文、后续是否还有其他处理。一个字符清洗函数，救不了没分层的输入输出逻辑。

到这里，我们也就讲完了《CodeIgniter过滤函数：remove_invisible_characters安全使用指南》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！