Discuz 论坛防止 SQL 注入的核心是保持程序版本最新、严格管控第三方插件权限，并在服务器层部署 WAF 防护。适用场景为所有基于 Discuz 搭建的公开论坛，风险边界在于旧版本插件可能无法兼容最新核心导致功能失效。
先说结论：Discuz 安全加固必须依赖官方版本更新配合服务器端策略，单靠修改代码无法根除风险。
- 先判断：确认当前 Discuz 核心版本及已安装插件来源是否可信
- 优先做：备份数据库与源码后升级至官方最新稳定版
- 再验证：通过日志监控与安全扫描确认注入接口已闭合
快速处理思路
SQL 注入防护没有单一命令可解决，需按以下顺序执行操作：
- 全站文件与数据库完整备份
- 登录 Discuz 后台检查系统版本并申请升级
- 移除来源不明或长期未更新的第三方插件
- 在 Web 服务器（Nginx/Apache）前配置 WAF 规则
- 限制数据库账号权限，禁止 DROP 等高危操作
为什么会这样
SQL 注入发生的根本原因是程序未对用户输入数据进行严格过滤便拼接到数据库查询语句中。Discuz 核心代码虽经过安全处理，但第三方插件开发者水平参差不齐，常留下注入漏洞。此外，旧版本 Discuz 已知漏洞若未及时修补，攻击者可直接利用公开 exploit 脚本获取数据库权限。服务器层面若未关闭 PHP 危险函数或未限制数据库账号权限，会放大注入成功后的危害。
分步处理
第一步：备份现有环境
操作动作：使用 FTP 或 SSH 下载全站文件，通过 phpMyAdmin 或命令行导出完整 SQL 数据库文件。
风险边界：升级失败时可立即回滚，避免数据丢失。
第二步：升级 Discuz 核心
操作动作：访问 Discuz 官方下载页获取最新稳定版压缩包，覆盖除 config 配置文件外的核心文件，运行升级脚本。
验证结果：后台首页显示最新版本号，无报错信息。
第三步：清理高风险插件
操作动作：进入后台“应用”菜单，卸载非官方认证且长期未更新的插件。
风险边界：部分插件卸载可能导致关联数据丢失，需提前确认依赖关系。
第四步：配置数据库权限
操作动作：登录 MySQL，执行REVOKE DROP, SUPER ON database.* FROM 'discuz_user'@'localhost';。
验证结果：该账号无法执行删库或提权操作。
第五步：部署 WAF 防护
操作动作：在 Nginx 或 Apache 配置中启用 ModSecurity 或接入云盾 WAF，开启 SQL 注入防护规则集。
验证结果：访问带有典型注入特征（如' OR 1=1）的 URL 时被拦截返回 403。
怎么验证是否生效
查看 Web 服务器错误日志，确认是否有拦截记录。使用通用 SQL 注入扫描工具对论坛搜索框、登录接口进行非破坏性测试，观察是否返回数据库错误信息。公开资料中没有看到可靠的量化数据表明具体拦截率，但正常业务请求不应受影响。若开启 PHP 错误显示，确保生产环境中display_errors设置为Off，防止报错信息泄露表结构。
常见坑
1. 直接覆盖升级未备份，导致配置文件丢失无法连接数据库。
2. 盲目信任第三方市场插件，未审查代码即安装。
3. 数据库账号使用 root 权限运行论坛，一旦注入成功后果不可控。
4. 仅依赖 Discuz 自带防护，忽略服务器层面 WAF 配置。
常见问题
Discuz 多久需要检查一次安全更新？
建议每月登录官方论坛查看一次公告，遇紧急安全通告需立即处理。
第三方插件如何判断是否安全？
优先选择官方应用中心认证插件，避免使用来源不明或作者已停止维护的插件。
开启 WAF 会影响论坛访问速度吗？
合理配置的 WAF 对正常请求影响极小，但规则过严可能误拦截正常提交内容。
参考来源
- Discuz 官方文档 - 安全指南，https://www.discuz.com/
- PHP 官方手册 - 安全数据库操作，https://www.php.net/manual/zh/security.database.php