CodeIgniter安全过滤函数详解

本文深入剖析了CodeIgniter中常被误用的remove_invisible_characters函数，明确指出它绝非XSS或SQL注入防护工具——它仅粗略清理部分ASCII控制字符和宽松判定的无效UTF-8序列，对零宽空格、Unicode格式字符、HTML标签、危险协议等现代攻击载荷完全无感，且默认不处理URL编码；文章强调其设计初衷是“输入美化”而非“安全过滤”，并警示在CI 3.x中已被弃用的xss_clean()曾错误依赖它，而CI 4已彻底移除；同时给出务实替代方案：存库用预处理语句、输出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安全过滤函数详解》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！