简介针对PHP应用常见的SQL注入与HTTP跨站攻击XSS、CSRF风险这份由360提供的防注入代码修改类为开发者提供了轻量实用的防护思路。资源面向有一定PHP基础、希望快速增强数据库操作与请求处理安全性的学习者内含params.php核心类文件以及配套readme.md说明文档共2个文件整体压缩包仅1KB便于直接阅读和集成。文档中重点讲解了预处理语句、参数化查询、输入验证与错误处理等防注入要点同时涵盖XSS过滤、CSRF令牌生成等防御方法并结合类方法如escape_string()、validate_input()、generate_csrf_token()给出具体使用示例。已有618人浏览学习适合用于理解安全编码规范、对比自身项目中的输入处理逻辑并快速借鉴到实际PHP开发中。1. 别急着用这个类先搞清它到底防什么做PHP开发超过五年的人大概都见过类似的场景项目里塞了一个“安全类”里面一堆escape_string()、filter_input()、htmlspecialchars()的封装看起来滴水不漏结果上线第一周就被sqlmap打穿。原因通常不是类写得不好而是调用者压根不清楚这个类拦截的是哪一层攻击。360这个防SQL注入代码修改类核心价值不在“过滤”本身而在于把过滤逻辑从业务代码里剥离出来——但这恰恰是所有安全类的通病一旦剥离不彻底等于没装。这个包里的readme.md和params.php前者讲用法后者是一堆全局参数配置。真正要理解的是它背后的设计逻辑SQL注入的本质是用户输入被拼接进了SQL语句的解释器上下文而XSS和CSRF则是HTTP层的信任边界问题。这个类尝试用一套统一的入口把所有输入先过一遍滤网再交给业务逻辑。适合的场景是那些已经在跑的老项目没办法全面重构用PDO预处理但又急需一道拦截层的团队。新项目如果你还在用字符串拼SQL那问题不在这个类而在你的架构。2. 为什么addslashes()不可靠以及这个类的过滤策略2.1 字符集绕过宽字节注入的杀伤力在真正理解360这个类的实现之前必须先搞清楚传统转义函数为什么在特定场景下直接失效。早期PHP项目最常见的防注入写法就是addslashes()或者mysql_real_escape_string()这两个函数原理相同在单引号、双引号、反斜杠和NULL字符前面加反斜杠。问题是当数据库连接使用GBK这类多字节字符集时攻击者可以用%bf%27这种宽字节编码绕过转义。以MySQL为例%bf%5c会被当作一个合法的宽字节字符而%5c就是反斜杠。这意味着addslashes()加上的那个防注入反斜杠反而被“吃掉”了后面的单引号成功逃逸。360这个类在设计时显然考虑了这一点它对输入的处理不是简单调用转义函数而是先做字符集归一化。这个类的params.php里通常会有字符集配置项默认强制使用UTF-8从根上堵死宽字节注入。处理逻辑上常见的做法是先检测输入的编码如果不是UTF-8用iconv()或mb_convert_encoding()转成UTF-8再进行过滤。这一步必须在所有业务逻辑之前完成因为过滤规则是按UTF-8设计的。如果是老数据库还留在GBK那就需要在连接层就把字符集设为UTF-8而不是在应用层转了以后写回GBK库——那等于白转。2.2 过滤规则的粒度设计查看这个类的核心方法它的过滤策略分三层和那些一把梭的strip_tags()完全不同。第一层是类型判断根据params.php里定义好的规则判断输入是整型、浮点型、字符串还是数组。整型和浮点型直接用abs(intval($input))处理字符串才进入下一层。第二层是关键词黑名单过滤用preg_match匹配union select、information_schema这些注入特征用preg_replace做替换。第三层是转义层只对最终要进入SQL语句的字符串做转义。这里有个关键设计值得学它不是用同一个过滤函数对所有输入一刀切而是按用途分流。一个输入如果只是用来做条件判断的ID那就强转int根本不需要走字符过滤。如果是要插入数据库的文本内容才做转义。这样的好处是降低误杀率——很多安全类把用户输入的合法内容都过滤掉了比如一篇讲union select的技术文章存进数据库就变成union select数据全乱了。360这个类在params.php里允许单独配置哪些字段走严格模式、哪些走宽松模式这种白名单思路比黑名单靠谱。3. 拆解params.php真正要改的配置项就这几个3.1 初始化流程与参数加载顺序把readme.md看完后你会发现使用这个类的第一步不是实例化过滤器而是先确认数据库连接方式。因为预处理和转义是两条完全不同的防御路线这个类设计了共存机制。这里给出一个典型接入流程?php // safe_init.php require_once params.php; require_once SafeFilter.class.php; // 读取参数配置 $config SafeParams::getInstance()-load(config.inc.php); // 实例化过滤核心类 $filter SafeFilter::getInstance($config); // 注册全局过滤入口自动对 $_GET/$_POST/$_COOKIE 做初始检查 $filter-autoProbe() -setCharSet($config[default_charset]) // 强制 UTF-8 -setErrorLevel($config[error_display]); // 生产环境必须为 0 // 业务侧获取过滤后的参数 $id $filter-filterInt($_GET[id]); $name $filter-filterString($_POST[name], trim|strip_tags);这段代码里最重要的是autoProbe()这一行。它的作用是遍历超全局数组检测明显的SQL注入尝试和XSS特征命中后直接触发params.php里配置的拦截行为——默认是写日志然后header(Location: error_page.php)跳转不做任何回显。这样做避免了攻击者通过响应内容探测过滤规则。filterInt和filterString是业务侧的主动过滤方法filterString第二参数支持管道式规则类似CodeIgniter的写法trim|strip_tags会先执行trim()再执行strip_tags()。3.2 生产环境的推荐配置params.php里的配置项大概有三十多个但真正需要手动改的就几个用表格说明配置项可选值推荐值说明default_charsetUTF-8,GBKUTF-8全局字符集必须与数据库连接字符集一致error_display0,10生产环境禁止显示SQL错误防止报错信息泄露库表结构csrf_token_name任意字符串__csrf_token__CSRF令牌字段名不要用token这种常见名filter_levelloose,strict,paranoidstrictloose只过滤注入特征strict加XSS过滤paranoid连特殊字符都转义url_redirect合法URL项目错误页地址拦截后跳转地址不要填外链log_path可写目录/var/log/php_safe/攻击日志目录记得做日志切割注意filter_level这一项paranoid模式虽然最安全但会把用户输入里所有符号全部实体编码如果项目里要支持用户提交代码片段或富文本这个模式就是灾难。所以这个类也建议配合富文本场景单独绕过对这类字段使用白名单式过滤方法。3.3 与PDO预处理共存而不是互相替代这个类最容易被误解的一点就是它想替代预处理实际上源码里明确写了建议先用PDO做参数绑定再把这个模块作为纵深防御的第二层。对于已经在用PDO的项目接入这个类之后不需要改动原有查询逻辑。?php // 推荐写法PDO预处理 过滤类双重校验 $stmt $pdo-prepare(SELECT * FROM users WHERE id :id AND status :status); $stmt-execute([ :id $filter-filterInt($_GET[id]), :status $filter-filterString($_POST[status], trim|alpha_numeric) ]);有一种常见误用是把过滤类的转义方法用在PDO预处理环境的SQL语句上。比如先对参数调用escape_string()再传给prepare()这反而可能破坏参数原貌。预处理机制本身会规避SQL注入多余的转义会让字符串里出现双反斜杠查询结果直接出错。这个类针对这种情况做了双模式检测检测到实例化对象是PDO时自动跳过内部转义层只保留类型判断和关键词过滤。接入逻辑里留下的filterString方法也是安全的因为它只做格式清洗不做数据库层转义。4. 绕不过去的场景二次注入、报错注入与绕过手法复现4.1 二次注入这个类的盲区在哪二次注入的触发链路是第一次通过过滤类把恶意内容存进数据库内容本身在存储时没有执行SQL是安全的后续代码把数据库内容取出后直接拼接进另一条SQL语句此时过滤类已经不再作用在这个数据上攻击生效。这个类对二次注入没有任何防护能力——因为它在入口处过滤拦截不到数据库内部流转的数据。缓解方案是规定内存变量必须使用PDO::PARAM_STR参数绑定再入查询并且对取出的字段做一次htmlspecialchars()。可以给这个过滤类加一层封装把从数据库取出的值统一经过output_encode()方法。360这个类本身没有内置这个方法但留了扩展接口。写一个子类继承后补充这个方法即可。4.2 报错注入实测updatexml和extractvalue拿DVWA的low难度环境做测试输入1 AND updatexml(1,concat(0x7e,database()),1)--报错回显数据库名这是典型的报错注入。360类在strict级别下关键词黑名单包含updatexml、extractvalue、floor、count这几个报错特征。但被过滤后DBA或其他工具的混淆变体能不能绕过来模拟一种常见变形-- 原始载荷 1 AND updatexml(1,concat(0x7e,database()),1)-- -- 变形尝试 1 AND UPDATEXML(1,CONCAT(0x7e,database()),1)-- 1 AND updatexml(1,concat(0x7e,mid(database()from(1))),1)--360类在实现正则黑名单时如果不是大小写不敏感的那就漏了。测试这个类自带的config.inc.php可以发现它默认对所有关键词做了i修饰符也就是大小写不敏感。第二层变形用mid(database()from(1))替代database()这个不在黑名单关键词表里。所以完整的绕过链是替换函数名——但注意updatexml这个函数名本身已经命中规则替换参数函数并不能绕过整条过滤。真正要测试的是那些不在黑名单里的报错函数比如GTID_SUBSET1 AND GTID_SUBSET(CONCAT(0x7e,database()),1)--这个函数在很多过滤规则里都没收录实测360类这条能过。给使用者的建议是过滤类只能拦已知特征对新出的函数需要定期更新黑名单或直接用预处理器兜底。4.3 验证过滤结果的思路经常有人装完这个类跑一次SQLMap就认为安全了这个逻辑有缺口。注入漏洞是否能被利用取决于多个因素黑名单命中情况、报错信息是否可见、字符集是否统一。在这个类的过滤场景下不快是响应是否正常还要看除错日志里有没有留下拦截记录。验证时采用分层测试第一层直接提交id1 and 11--看是否被跳转到错误页第二层用id1 and (select 1 from (select count(*),concat((select concat(table_name) from information_schema.tables limit 0,1),floor(rand(0)*2))x from information_schema.tables group by x)a)--绕过关键词黑名单第三层是看错误响应是否暴露了params.php里的实时代码路径。常用工具是Burp Suite的重放模块用宏自动替换载荷字典对比响应长度差异。如果攻击响应和正常响应完全一致且拦截日志数量为零那才说明这个类的过滤对当前测试集有效。另一条验证路径是白盒检查阅读这个类在autoProbe()方法里的正则列表确认关键词覆盖度。从做运维的角度看把这个类部署到生产环境后第一周每小时的攻击日志里如果出现HTTP 200但响应内容异常说明黑名单可能存在缺口需要即时补充正则规则并调整filter_level到paranoid测试业务兼容性。本文还有配套的精品资源点击获取