一、为什么 PHP 项目总被盯上做 PHP 开发这些年我见过太多项目上线后被黑的情况。说句实话大部分漏洞并不是什么高深的技术翻来覆去就是 SQL 注入和 XSS 这两类。很多新手写代码的时候图省事直接把用户输入拼进 SQL 语句或者原样输出到页面上结果就给黑客留了后门。这篇文章不聊那些虚的理论直接讲怎么修、怎么防。我会结合实际的代码片段把常见的坑一个个填平。二、SQL 注入别再把变量拼进查询里先看一段典型的反面教材。很多老代码里都有这种写法?php // 危险写法直接拼接用户输入 $id $_GET[id]; $sql SELECT * FROM users WHERE id . $id; $result mysqli_query($conn, $sql); ?这段代码的问题在于如果用户在地址栏输入?id1 OR 11那查询就变成了SELECT * FROM users WHERE id 1 OR 11整张表的数据全被捞走了。更狠一点的还能用UNION SELECT拖出其他表的数据。正确的做法是使用预处理语句也就是参数化查询。拿 PDO 举例?php // 推荐写法PDO 预处理语句 $pdo new PDO(mysql:hostlocalhost;dbnametest, 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 注入正好相反它是把恶意脚本塞进页面里。比如用户在留言板提交了这么一段内容scriptalert(你被黑了)/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); ?这段代码的问题在于如果用户在地址栏输入?id1 OR 11那查询就变成了SELECT * FROM users WHERE id 1 OR 11整张表的数据全被捞走了。更狠一点的还能用UNION SELECT拖出其他表的数据。正确的做法是使用预处理语句也就是参数化查询。拿 PDO 举例?php // 推荐写法PDO 预处理语句 $pdo new PDO(mysql:hostlocalhost;dbnametest, 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 注入正好相反它是把恶意脚本塞进页面里。比如用户在留言板提交了这么一段内容scriptalert(你被黑了)/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 漏洞也能降低危害。安全这东西从来不是一次修完就一劳永逸的。代码上线之后建议定期用扫描工具过一遍或者干脆请懂行的朋友帮忙做一次代码审计。毕竟漏洞往往藏在那些你觉得“应该没问题”的地方。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
