一、为什么 PHP 项目总被盯上做 PHP 开发这些年，我见过太多项目上线后被黑的情况。说句实话，大部分漏洞并不是什么高深的技术，翻来覆去就是 SQL 注入和 XSS 这两类。很多新手写代码的时候图省事，直接把用户输入拼进 SQL 语句，或者原样输出到页面上，结果就给黑客留了后门。这篇文章不聊那些虚的理论，直接讲怎么修、怎么防。我会结合实际的代码片段，把常见的坑一个个填平。二、SQL 注入：别再把变量拼进查询里先看一段典型的反面教材。很多老代码里都有这种写法：<?php // 危险写法：直接拼接用户输入 $id = $_GET['id']; $sql = "SELECT * FROM users WHERE id = " . $id; $result = mysqli_query($conn, $sql); ?>这段代码的问题在于，如果用户在地址栏输入?id=1 OR 1=1，那查询就变成了SELECT * FROM users WHERE id = 1 OR 1=1，整张表的数据全被捞走了。更狠一点的，还能用UNION SELECT拖出其他表的数据。正确的做法是使用预处理语句，也就是参数化查询。拿 PDO 举例：<?php // 推荐写法：PDO 预处理语句 $pdo = new PDO('mysql:host=localhost;dbname=test', 'root', 'password'); $stmt = $pdo->prepare('SELECT * FROM users WHERE id = :id'); $stmt->execute([':id' => $_GET['id']]); $user = $stmt->fetch(); ?>这样写，参数和 SQL 语句是分开传输的，数据库会先把语句编译好，再把参数当纯数据处理，无论用户输入什么，都只是一串字符，不会变成可执行的 SQL 片段。如果你还在用老旧的mysqli，同样有对应的预处理写法：<?php // mysqli 预处理写法 $stmt = mysqli_prepare($conn, 'SELECT * FROM users WHERE id = ?'); mysqli_stmt_bind_param($stmt, 'i', $_GET['id']); mysqli_stmt_execute($stmt); $result = mysqli_stmt_get_result($stmt); ?>这里有个小细节：bind_param的第二个参数'i'表示整数类型，如果字段是字符串就写's'。养成绑定类型的习惯，能少踩不少坑。三、XSS 跨站脚本：输出之前先过滤XSS 的攻击思路和 SQL 注入正好相反，它是把恶意脚本塞进页面里。比如用户在留言板提交了这么一段内容：<script>alert('你被黑了')</script>如果后端直接把这个内容原样输出到 HTML 里，那所有访问这个页面的用户都会弹窗，更严重的还能窃取 Cookie、伪造登录状态。修复的核心思路就一句话：输出到 HTML 之前，把特殊字符转义掉。PHP 自带的htmlspecialchars函数就是干这个的：<?php // 安全输出：转义 HTML 特殊字符 echo htmlspecialchars($user_input, ENT_QUOTES, 'UTF-8'); ?>这个函数会把<、>、&、引号等字符转成对应的 HTML 实体，浏览器拿到之后只会显示成普通文本，不会当成标签去解析。另外要提醒一点，htmlspecialchars的第二个参数建议用ENT_QUOTES，这样单引号和双引号都会被转义。有些老代码只写了第一个参数，结果单引号没被处理，照样能绕过。如果项目里用了模板引擎，比如 Twig 或者 Blade，它们默认就开启了自动转义，这能省不少事。但要注意，如果用了|raw之类的过滤器强制输出原始内容，那安全责任就又回到自己身上了。四、顺手再补几个小习惯除了上面两个核心修复，还有几个日常开发里容易忽略的点，一起列出来：数据库账号权限：给应用用的数据库账号，只授予它需要的权限，别一上来就给root或者ALL PRIVILEGES。关闭错误回显：生产环境把display_errors关掉，避免把 SQL 语句和文件路径直接暴露给用户。设置字符集：连接数据库时显式指定utf8mb4，能避免一部分编码相关的注入绕过。内容安全策略：在响应头里加上Content-Security-Policy，限制脚本来源，即使有 XSS 漏洞，也能降低危害。安全这东西，从来不是一次修完就一劳永逸的。代码上线之后，建议定期用扫描工具过一遍，或者干脆请懂行的朋友帮忙做一次代码审计。毕竟，漏洞往往藏在那些你觉得“应该没问题”的地方。
一、为什么 PHP 项目总被盯上做 PHP 开发这些年，我见过太多项目上线后被黑的情况。说句实话，大部分漏洞并不是什么高深的技术，翻来覆去就是 SQL 注入和 XSS 这两类。很多新手写代码的时候图省事，直接把用户输入拼进 SQL 语句，或者原样输出到页面上，结果就给黑客留了后门。这篇文章不聊那些虚的理论，直接讲怎么修、怎么防。我会结合实际的代码片段，把常见的坑一个个填平。二、SQL 注入：别再把变量拼进查询里先看一段典型的反面教材。很多老代码里都有这种写法：<?php // 危险写法：直接拼接用户输入 $id = $_GET['id']; $sql = "SELECT * FROM users WHERE id = " . $id; $result = mysqli_query($conn, $sql); ?>这段代码的问题在于，如果用户在地址栏输入?id=1 OR 1=1，那查询就变成了SELECT * FROM users WHERE id = 1 OR 1=1，整张表的数据全被捞走了。更狠一点的，还能用UNION SELECT拖出其他表的数据。正确的做法是使用预处理语句，也就是参数化查询。拿 PDO 举例：<?php // 推荐写法：PDO 预处理语句 $pdo = new PDO('mysql:host=localhost;dbname=test', 'root', 'password'); $stmt = $pdo->prepare('SELECT * FROM users WHERE id = :id'); $stmt->execute([':id' => $_GET['id']]); $user = $stmt->fetch(); ?>这样写，参数和 SQL 语句是分开传输的，数据库会先把语句编译好，再把参数当纯数据处理，无论用户输入什么，都只是一串字符，不会变成可执行的 SQL 片段。如果你还在用老旧的mysqli，同样有对应的预处理写法：<?php // mysqli 预处理写法 $stmt = mysqli_prepare($conn, 'SELECT * FROM users WHERE id = ?'); mysqli_stmt_bind_param($stmt, 'i', $_GET['id']); mysqli_stmt_execute($stmt); $result = mysqli_stmt_get_result($stmt); ?>这里有个小细节：bind_param的第二个参数'i'表示整数类型，如果字段是字符串就写's'。养成绑定类型的习惯，能少踩不少坑。三、XSS 跨站脚本：输出之前先过滤XSS 的攻击思路和 SQL 注入正好相反，它是把恶意脚本塞进页面里。比如用户在留言板提交了这么一段内容：<script>alert('你被黑了')</script>如果后端直接把这个内容原样输出到 HTML 里，那所有访问这个页面的用户都会弹窗，更严重的还能窃取 Cookie、伪造登录状态。修复的核心思路就一句话：输出到 HTML 之前，把特殊字符转义掉。PHP 自带的htmlspecialchars函数就是干这个的：<?php // 安全输出：转义 HTML 特殊字符 echo htmlspecialchars($user_input, ENT_QUOTES, 'UTF-8'); ?>这个函数会把<、>、&、引号等字符转成对应的 HTML 实体，浏览器拿到之后只会显示成普通文本，不会当成标签去解析。另外要提醒一点，htmlspecialchars的第二个参数建议用ENT_QUOTES，这样单引号和双引号都会被转义。有些老代码只写了第一个参数，结果单引号没被处理，照样能绕过。如果项目里用了模板引擎，比如 Twig 或者 Blade，它们默认就开启了自动转义，这能省不少事。但要注意，如果用了|raw之类的过滤器强制输出原始内容，那安全责任就又回到自己身上了。四、顺手再补几个小习惯除了上面两个核心修复，还有几个日常开发里容易忽略的点，一起列出来：数据库账号权限：给应用用的数据库账号，只授予它需要的权限，别一上来就给root或者ALL PRIVILEGES。关闭错误回显：生产环境把display_errors关掉，避免把 SQL 语句和文件路径直接暴露给用户。设置字符集：连接数据库时显式指定utf8mb4，能避免一部分编码相关的注入绕过。内容安全策略：在响应头里加上Content-Security-Policy，限制脚本来源，即使有 XSS 漏洞，也能降低危害。安全这东西，从来不是一次修完就一劳永逸的。代码上线之后，建议定期用扫描工具过一遍，或者干脆请懂行的朋友帮忙做一次代码审计。毕竟，漏洞往往藏在那些你觉得“应该没问题”的地方。