体育站群SQL注入防护实战：入口拦截、参数化查询与数据库加固全流程

搞体育站群的人都明白，这类站点访问量大、页面数量多、模板复用程度高，只要有一个注入点没堵上，整批域名就可能被挂马甚至拖库。我手上这套体育站群方案前前后后调整过好几轮防注入设置，从最早只挂个安全狗，到后来逐个查询点改代码，中间踩的坑不少。下面把整套做法展开聊聊，拿去就能照着改。

一、入口层先把脏参数拦掉

站群程序大多用PHP写，入口文件就那么几个——index.php、search.php、list.php，体育站群常见的赛程查询、比分筛选、球队ID传参，全是注入的高发位置。我现在的习惯是在入口处统一加一层过滤，不靠某一个函数单打独斗，而是对GET、POST、COOKIE三路输入同时下手：数字型参数强转int，字符串参数走白名单校验，像球队ID、联赛ID这种本来就该是数字的字段，直接(int)强转，后面多出来的字符一律丢掉。

过滤规则得写进公共引导文件，别散在各个业务页面里。早些年我图省事，在单个页面写过滤，结果新增一个比分接口就漏掉一处，后来被扫出布尔盲注，教训很直接。入口层再加一条：请求里带union、select、sleep、benchmark这类关键词的，直接记录并拒绝，注意是记录加拒绝，光拒绝不留痕，事后排查根本不知道谁在试。

二、查询层换成参数化，别拼字符串

过滤只是第一道门，真正让注入失效的是参数化查询。体育站群的数据表结构不复杂，赛事表、球队表、赔率表，查询条件多是ID和日期区间，用PDO预处理把变量绑进去，SQL结构就固定死了。这套方案里我把所有拼SQL的地方过了一遍，凡是变量直接嵌进双引号字符串的，全部改成占位符绑定。改的时候顺手统一了数据库访问类，业务层只传参数，不碰SQL文本。

有个细节值得说：ORDER BY后面的字段名没法用占位符绑定，这类地方我用映射数组处理，前端传sort=1就对应固定字段，传别的值直接回落默认排序。体育站群列表页经常带排序参数，这里不处理等于留了个现成的注入口子。

三、数据库账号权限收到最小

不少站群部署图省事，程序连库直接用root，这种配置一旦被注入，攻击者能直接读information_schema、写文件、甚至提权。我这套体育站群给每个站点单独建库账号，只授予SELECT、INSERT、UPDATE、DELETE四类权限，DROP、ALTER、FILE、PROCESS全部收回。站点之间账号不共用，一个站被拿下不影响其余域名。

账号密码也别拿域名拼凑，生成随机串存进配置文件，配置文件放到Web根目录之外。之前接手过一个站群，config.php直接躺在网站根目录，浏览器一访问就下载下来，库账号密码全暴露，这种低级问题在批量建站时特别容易犯。

四、错误回显和日志两头都要管

生产环境把display_errors关掉，数据库报错信息绝不能吐到页面上，注入探测很多时候就是靠报错内容判断表结构。错误日志单独写到非公开目录，按天切分，保留30天。体育站群页面量大，日志文件涨得快，我一般配个定时任务压缩归档，磁盘写满导致站点挂掉的事也遇到过。

日志里重点盯几类特征：参数里带单引号、and 1=1、注释符、编码后的union，出现频率高的IP直接拉黑。站群共用一套WAF规则时，注意各子站业务参数不一样，白名单要按站点配置，别一刀切把正常的比分查询参数也拦了。

五、定期自查比事后补救划算

防注入设置不是配完就完事。我每个季度会用sqlmap对站群抽样跑一遍，重点测新增的接口和改过查询逻辑的页面。体育站群经常加活动页、改版列表页，新代码带进来的注入点往往就是突破口。数据库账号权限也定期复核，发现多授的权限当场收回。

整套下来工作量不算小，但比起被拖库后换域名、重新收录的代价，这点投入完全值得。体育站群防SQL注入说到底就一句话：入口收紧、查询参数化、权限最小化、日志看得住，四件事做到位，绝大部分自动化扫描就过不了第一关。