由 dawei SQL注入是PHP应用中最危险的漏洞之一，攻击者通过构造恶意SQL语句，绕过身份验证、窃取数据甚至删除整个数据库。其根本原因在于将用户输入直接拼接到SQL查询中，未做有效隔离。
AI生成内容，仅供参考
防护的核心原则是“数据与代码分离”。最可靠的方法是使用预处理语句（Prepared Statements），它将SQL逻辑与参数严格区隔。例如，用PDO时应调用prepare()和execute()，而非直接拼接$_POST[‘username’]到SQL字符串中；MySQLi同样支持bind_param()机制，确保用户输入仅作为参数值，不参与语法解析。
过滤函数如mysql_real_escape_string()已废弃且不可靠——它仅处理引号等特殊字符，无法防御宽字节注入或数值型注入场景。类似地，addslashes()完全不应出现在现代代码中，它既非标准又易被绕过。
类型强校验能形成额外屏障。对ID、价格等字段，应明确用is_numeric()、filter_var($id, FILTER_VALIDATE_INT)或intval()强制转换。若输入不符合预期类型，立即拒绝而非尝试“修复”。
最小权限原则必须落地。数据库连接账号不应拥有DROP、CREATE或FILE权限，生产环境应使用仅具备SELECT/INSERT/UPDATE权限的专用账户。配合数据库层面的白名单限制（如限定可访问的表名），可大幅压缩攻击面。
错误信息需彻底屏蔽。php.ini中设置display_errors=Off，并启用log_errors=On。避免将SQL错误细节（如表名、字段名）返回前端，防止为攻击者提供侦察线索。
代码审计要覆盖所有SQL入口点：不仅包括登录、搜索功能，还要检查导出报表、排序参数（order by）、分页limit子句等易被忽视的位置。自动化工具（如PHPStan配合安全插件）可辅助发现潜在拼接痕迹，但人工复核仍不可替代。
安全是持续过程，不是单次补丁。每一次用户输入进入SQL查询前，都必须经过预处理或强类型校验。没有银弹，只有层层设防的习惯与严谨的开发纪律。