如何过滤$_REQUEST以防范SQL注入与XSS攻击？求可行方案及代码

一、当前方案的核心问题 #

• SQL注入防护完全无效：黑名单式的字符替换（比如删select、=）很容易被绕过，比如大小写变形（sElEcT）、编码绕过、语句拼接等，根本防不住真正的注入攻击。而且PDO本身提供了更可靠的防护方式，不需要手动修改输入。
• XSS防护时机错误：htmlspecialchars应该在数据输出到HTML页面时使用，而不是在接收请求阶段处理。提前转义会导致数据失真——比如用户密码里的=被删掉、正常内容里的特殊字符被转义后存到数据库，后续如果要用于非HTML场景（比如邮件发送、API返回）就会出问题。
• 不必要的副作用：全局修改$_REQUEST会破坏原始输入，比如用户密码包含被你删除的字符时，会直接导致登录失败，必须强制重置密码，这完全是可以避免的糟糕体验。
• 负载问题是次要矛盾：遍历$_REQUEST的性能开销其实很小，但方案本身的逻辑错误才是最大风险，就算只在登录页执行，其他页面的注入和XSS风险依然存在。

二、最优实现方案 #

1. SQL注入防护：PDO参数化查询（唯一可靠的方式） #

不管用sqlsrv还是其他驱动，PDO的参数化查询是防范SQL注入的标准方案，原理是把SQL语句和用户输入分离，由数据库驱动自动处理参数的转义与绑定，从根源上避免注入。

示例代码（sqlsrv驱动）

// 初始化PDO连接（建议放在单独的配置文件中）
$dsn = "sqlsrv:Server=你的服务器地址;Database=你的数据库名";
$pdo = new PDO($dsn, "用户名", "密码");
$pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION); // 开启异常错误模式，方便调试
$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, false); // 禁用模拟预处理，提升安全性

// 示例1：查询用户（使用问号占位符）
$username = $_POST['username'];
$stmt = $pdo->prepare("SELECT id, username FROM users WHERE username = ?");
$stmt->execute([$username]); // 传入参数数组，自动绑定
$user = $stmt->fetch(PDO::FETCH_ASSOC);

// 示例2：插入数据（使用命名占位符）
$insertStmt = $pdo->prepare("INSERT INTO users (username, email, password) VALUES (:username, :email, :password)");
$insertStmt->execute([
    ':username' => $_POST['username'],
    ':email' => $_POST['email'],
    ':password' => password_hash($_POST['password'], PASSWORD_DEFAULT) // 密码要哈希存储，不要明文
]);

关键注意点：

• 永远不要把用户输入直接拼进SQL语句（比如"SELECT * FROM users WHERE username = '$username'"）
• 所有动态值（用户输入、变量）都必须用占位符（?或:name），由execute()方法传入参数

2. XSS防护：输出时转义 #

XSS的本质是用户输入的内容被当作HTML/JS代码执行，所以只需要在把数据输出到HTML页面的瞬间做转义即可，不要提前修改原始数据。

示例代码

// 从数据库取出用户昵称，输出到HTML页面时转义
$nickname = $user['nickname'];
echo "欢迎回来：" . htmlspecialchars($nickname, ENT_QUOTES, 'UTF-8');

关键注意点：

• 必须指定ENT_QUOTES参数（同时转义单引号和双引号），避免遗漏转义导致的XSS
• 明确指定编码（比如UTF-8），避免乱码或转义不彻底
• 如果是输出到JS代码中，要用json_encode()转义，而不是htmlspecialchars
• 如果是富文本内容（比如用户发布的带格式的文章），不要用htmlspecialchars，而是用HTML过滤库（比如HTMLPurifier）只允许安全的HTML标签（如<p>、<b>）

3. 辅助加固措施（配合已部署的WAF） #

• 输入格式验证：对邮箱、手机号、ID等字段做格式校验，比如用filter_var($_POST['email'], FILTER_VALIDATE_EMAIL)验证邮箱，提前拦截不符合规则的输入
• 限制输入长度：在数据库表字段设置长度限制的同时，代码中也检查输入长度（比如strlen($_POST['password']) >= 8），避免超长输入导致的问题
• 不要全局修改超全局变量：不要随意修改$_REQUEST、$_POST、$_GET，否则后续代码无法获取原始数据，容易引入隐蔽BUG
• 定期更新依赖：保持PHP、PDO sqlsrv驱动、服务器软件的版本更新，修复已知安全漏洞

三、关于负载的说明 #

• 参数化查询的性能和直接拼接SQL几乎无差异，甚至因为数据库可以缓存查询计划，性能反而更优
• htmlspecialchars的性能开销极低，完全不会对服务器造成压力
• 你之前的全局替换方案虽然负载不高，但逻辑错误带来的风险远大于这点性能消耗，所以完全没必要采用

内容的提问来源于stack exchange，提问作者baron_bartek