PHP安全进阶：防注入实战与站长必备逻辑
|
AI设计稿，仅供参考 PHP应用中，SQL注入仍是高危威胁。攻击者通过构造恶意输入，绕过应用逻辑直接操作数据库。比如用户登录时提交用户名' OR '1'='1，若代码直接拼接SQL，就可能跳过密码验证。防御核心在于“绝不信任外部输入”，所有来自GET、POST、COOKIE、HTTP头的数据都必须视为潜在攻击源。预处理语句（Prepared Statements）是当前最可靠的技术方案。它将SQL结构与数据彻底分离：先定义含占位符的语句，再绑定参数执行。MySQLi和PDO均原生支持。例如使用PDO时，写法为$stmt = $pdo->prepare("SELECT FROM users WHERE email = ?"); $stmt->execute([$email]); 即使$email含单引号或分号，数据库也只将其视作字符串值，无法改变语句逻辑。 过滤与转义仅作辅助，不可替代预处理。mysql_real_escape_string已废弃， addslashes更不安全——它无法防御宽字节注入或非MySQL环境。若必须处理动态表名或字段名（如排序字段），应严格白名单校验：$allowed = ['title', 'created_at', 'status']; if (!in_array($sort, $allowed)) { die('Invalid sort field'); }。 命令注入常被忽视。当PHP调用exec、shell_exec等函数拼接用户输入时风险极高。例如system("ping " . $_GET['host'])可被传入127.0.0.1; rm -rf /造成灾难。解决方法是禁用危险函数（php.ini中设置disable_functions=exec,system,passthru,shell_exec），或改用escapeshellarg()包裹参数——但仅限确定需执行外部命令的场景，多数业务应避免调用系统命令。 文件操作类漏洞同样致命。文件上传功能若未校验类型、扩展名和内容，可能让攻击者上传webshell。正确做法是：禁用upload_tmp_dir执行权限；检查$_FILES['file']['type']不可信，须用finfo_file()检测MIME；重命名文件为随机字符串+白名单后缀（如.png/.pdf）；保存至Web目录之外，通过下载脚本控制访问。 会话安全是站长易漏环节。默认PHPSESSID可通过URL泄露，应在php.ini中开启session.cookie_httponly=1、session.cookie_secure=1（HTTPS环境下），并定期调用session_regenerate_id(true)防止会话固定。同时避免将敏感数据（如用户ID、权限）明文存入$_SESSION，必要时可结合Redis存储并加密会话标识。 错误信息需严格管控。开发环境可显示错误，生产环境务必关闭display_errors=Off，并启用log_errors=On。否则数据库结构、路径、代码片段可能被暴露，为攻击者提供关键线索。可配合自定义错误处理器，统一记录日志而不返回任何细节给客户端。 安全不是一次性配置，而是持续习惯。定期更新PHP版本（避免5.6等EOL版本）、使用Composer管理依赖并扫描漏洞（如php-scanner）、部署WAF作为纵深防御层，都是务实选择。真正的防护意识，在于每次接收用户输入时本能思考：“这个值，我敢让它进SQL？进系统命令？进文件名？进响应体？” （编辑：51站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
