PHP防SQL注入：从addslashes的陷阱到现代安全实践

在CTF竞赛和实际开发中，SQL注入始终是Web安全领域的头号威胁。许多开发者习惯性地使用 addslashes() 作为防御手段，却不知这仅是安全防护的最表层。本文将深入剖析传统转义方法的致命缺陷，并系统介绍预处理语句、ORM等更可靠的防护方案。

1. addslashes()为何成为安全幻觉

addslashes() 函数通过转义单引号、双引号等特殊字符来"防御"SQL注入，这种看似简单的解决方案背后隐藏着多重隐患：

1.1 字符编码的致命漏洞

当数据库使用GBK等宽字符集时，攻击者可构造特殊payload绕过转义。例如输入 %bf%27 时， addslashes() 会将其转换为 %bf%5c%27 ，而MySQL的GBK编码会错误解析为 縗' ，导致单引号逃逸：

// 危险示例：宽字节注入
$username = addslashes($_GET['username']); 
// 输入%bf%27时依然可闭合SQL语句

1.2 数据库差异带来的兼容性问题

不同数据库对特殊字符的处理规则不同：

数据库	转义要求	addslashes适用性
MySQL	需转义 ' " \ \0	部分有效
PostgreSQL	需转义 '	不完全有效
SQLite	需转义 '	不完全有效

1.3 二次注入攻击

即使经过转义的数据存入数据库，当再次被取出使用时仍可能引发注入：

// 第一次插入时转义
$data = addslashes("admin'-- ");
$sql = "INSERT INTO logs VALUES('$data')";

// 取出时未转义直接使用
$log = query("SELECT data FROM logs WHERE id=1");
$sql = "DELETE FROM users WHERE name='$log'"; // 注入成功

2. 预处理语句：安全防线的基石

参数化查询（Prepared Statements）通过分离SQL结构与数据，从根本上杜绝注入可能。

2.1 PDO的正确使用姿势

$pdo = new PDO('mysql:host=localhost;dbname=test', 'user', 'pass');
$stmt = $pdo->prepare('SELECT * FROM users WHERE username = :user AND password = :pass');

// 命名参数绑定
$stmt->bindValue(':user', $_GET['username'], PDO::PARAM_STR);
$stmt->bindValue(':pass', $_GET['password'], PDO::PARAM_STR);

// 或使用问号占位符
$stmt = $pdo->prepare('SELECT * FROM users WHERE username = ? AND password = ?');
$stmt->execute([$_GET['username'], $_GET['password']]);

注意：必须禁用模拟预处理 $pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, false) ，否则某些情况下仍存在风险

2.2 MySQLi的预处理实践

$mysqli = new mysqli("localhost", "user", "pass", "db");
$stmt = $mysqli->prepare("SELECT * FROM users WHERE username = ? AND password = ?");
$stmt->bind_param("ss", $_GET['username'], $_GET['password']);
$stmt->execute();

预处理语句的优势对比：

防护方式	防注入效果	性能影响	代码可读性
addslashes	❌ 脆弱	低	一般
PDO预处理	✅ 完善	较高	优秀
MySQLi预处理	✅ 完善	中等	良好

3. 深度防御策略组合

3.1 输入验证白名单

预处理语句虽强，但结合白名单验证能构建更坚固的防线：

// 用户名只允许字母数字
if (!preg_match('/^[a-zA-Z0-9]{3,20}$/', $_GET['username'])) {
    die('无效用户名格式');
}

// 密码强度要求
if (strlen($_GET['password']) < 8) {
    die('密码至少8位');
}

3.2 最小权限原则

数据库账户应遵循最小权限原则：

-- 错误做法
GRANT ALL PRIVILEGES ON *.* TO 'webuser'@'%';

-- 正确做法
GRANT SELECT, INSERT ON project_db.users TO 'webuser'@'localhost';

3.3 框架ORM的安全优势

现代PHP框架内置的ORM系统提供更高级别的防护：

// Laravel Eloquent示例
$user = User::where('username', request('username'))
           ->where('password', request('password'))
           ->first();

// Symfony Doctrine示例
$user = $entityManager->getRepository(User::class)
        ->findOneBy([
            'username' => $request->get('username'),
            'password' => $request->get('password')
        ]);

ORM安全特性对比：

框架	ORM系统	自动参数化	查询构造器	迁移工具
Laravel	Eloquent	✅	✅	✅
Symfony	Doctrine	✅	✅	✅
CodeIgniter	Query Builder	✅	✅	❌

4. CTF实战中的加固技巧

基于BUUCTF Ezsql题目的进阶加固方案：

4.1 多层防御实现

// 输入验证层
if (!is_string($_GET['username']) || strlen($_GET['username']) > 20) {
    die('非法输入');
}

// 预处理语句层
$stmt = $mysqli->prepare("SELECT * FROM users WHERE username = ? AND password = ?");
$stmt->bind_param("ss", $_GET['username'], $_GET['password']);

// 输出过滤层
echo htmlspecialchars($result['username'], ENT_QUOTES, 'UTF-8');

4.2 日志监控策略

记录异常登录尝试：

$logData = [
    'ip' => $_SERVER['REMOTE_ADDR'],
    'time' => date('Y-m-d H:i:s'),
    'username' => $_GET['username'],
    'user_agent' => $_SERVER['HTTP_USER_AGENT']
];

if ($stmt->num_rows === 0) {
    file_put_contents('auth_fail.log', json_encode($logData)."\n", FILE_APPEND);
}

安全防护不是单一技术点的应用，而是需要建立从输入验证、参数化查询到权限控制的完整体系。在最近参与的某企业级项目中，我们发现即使使用了预处理语句，缺乏合理的输入验证仍然会导致业务逻辑漏洞。真正的安全之道在于理解每项技术背后的原理，根据实际场景构建纵深防御。