17370845950

htmlspecialchars()仅用于HTML输出转义，非万能XSS防护；输入校验用filter_input()，数据库操作必须预处理，文件上传需验证MIME并重命名。

PHP 中最常用也最容易误用的过滤函数是 htmlspecialchars()

它不是用来“过滤输入”，而是专门用于“输出到 HTML 时转义特殊字符”。很多初学者把它当成万能防 XSS 的过滤器，结果在 SQL 查询、JSON 输出或文件写入场景中照常出问题。

常见错误现象：htmlspecialchars($_POST['name']) 后直接拼进 SQL 语句，导致单引号没被处理，SQL 注入依然存在；或者对已转义过的字符串反复调用，变成 zuojiankuohaophpcn 这类双重编码。

• 只在输出到 HTML/HTML 属性/JS 字符串内时使用，且必须指定 ENT_QUOTES 和真实字符编码（如 UTF-8）
• 永远不要用它替代数据库参数绑定，也不要用它处理非 HTML 场景的输入
• 如果用户输入要存进数据库，htmlspecialchars() 应该完全不出现——那是 mysqli_real_escape_string() 或预处理语句的事

从表单接收数据后，第一步该用 filter_input() 做类型校验

这是 PHP 内置但常被忽略的安全入口。它比手写 isset() + is_numeric() + trim() 更可靠，且支持白名单过滤逻辑。

$_id = filter_input(INPUT_GET, 'id', FILTER_VALIDAT
E_INT);
if ($$_id === false || $$_id === null) {
    die('Invalid ID');
}
// 此时 $$_id 是整数，可安全用于 WHERE id = ?

• 用 FILTER_SANITIZE_EMAIL 处理邮箱字段，比正则更轻量且符合 RFC 标准
• FILTER_SANITIZE_NUMBER_INT 可去掉所有非数字字符，适合手机号、邮编等，但会删掉负号和小数点
• 注意：所有 FILTER_SANITIZE_* 类型都会修改原始值，不能替代验证；真正需要强约束时，优先用 FILTER_VALIDATE_* + 显式判断

数据库写入必须用预处理语句，mysql_real_escape_string() 已废弃且不安全

PHP 7.0+ 已移除 mysql_* 函数族，而 mysqli_real_escape_string() 依赖连接上下文和字符集设置，一旦 SET NAMES 和实际连接编码不一致，就会绕过转义。

正确做法只有一条：无论 MySQLi 还是 PDO，全部走预处理。

$stmt = $pdo->prepare("INSERT INTO users (name, email) VALUES (?, ?)");
$stmt->execute([$_POST['name'], $_POST['email']]);

• PDO 需确保创建时设置了 PDO::ATTR_EMULATE_PREPARES => false，否则仍可能触发模拟预处理，失去防护效果
• 不要把 filter_var() 和预处理混用成“双重保险”——类型校验归校验，SQL 安全归预处理，职责分开才可控
• 如果必须动态拼表名或字段名（极少见），只能通过白名单硬编码比对，绝不可过滤后拼接

上传文件的 $_FILES 不能靠扩展名过滤，要验证 MIME 和内容

攻击者只需改个 .jpg 后缀，里面塞 PHP 代码，再配合 Apache 解析漏洞或 Nginx 配置失误就能执行任意代码。仅检查 $_FILES['file']['type'] 完全无效——那是浏览器传来的，可随意伪造。

• 用 finfo_open(FILEINFO_MIME_TYPE) 检查真实 MIME 类型，例如强制只允许 image/jpeg
• 重命名上传文件，用随机字符串 + 白名单扩展名（如 uniqid() . '.jpg'），彻底丢弃原始文件名
• 上传目录禁止执行权限，Nginx/Apache 配置中明确禁止该目录下解析 PHP

实际项目里，最常被跳过的环节是「输出上下文识别」：同一段用户数据，可能同时出现在 HTML 页面、JS 变量、CSS 属性、URL 参数、CSV 导出里——每个上下文需要不同的转义方式。漏掉一个，就等于在防火墙上凿了个洞。