Au-delà de `Addslashes () ': Échappement contextuel pour une défense d'injection SQL robuste

SQL注入防护不能依赖addslashes()，因其不处理多字节编码且仅转义有限字符，易被绕过；应使用预处理语句（如PDO或MySQLi的参数化查询）将数据与SQL逻辑分离，确保输入不被解析为代码；若无法使用预处理，需根据上下文采用数据库特定的转义函数（如real_escape_string并设置正确字符集）、标识符白名单或引号包裹、整型输入强制类型转换等方法，实现分层防御。

When it comes to defending against SQL injection, relying solely on addslashes() is a dangerous shortcut. While it might seem to work in some cases, it’s fundamentally flawed and insufficient for robust security. True protection requires contextual escaping—applying the right escaping method based on the specific context in which user data enters the SQL query.

Let’s break down why addslashes() fails and what you should use instead.

Why addslashes() is not enough

addslashes() adds backslashes before quotes and a few other characters (', ", \, and NULL). But here’s the problem:

• It doesn’t account for different character encodings (like multi-byte encodings such as GBK), where an escaped character might be interpreted as part of a two-byte sequence, leading to exploitable vulnerabilities.
• It only escapes a limited set of characters, and its behavior isn’t tied to the actual SQL grammar or database driver.
• It assumes single-byte encodings and may fail under edge cases, making it unreliable.

Example: In a GBK encoding context, '\' followed by %bf%27 can be interpreted as a single character, allowing an attacker to bypass addslashes() and inject ' into the query.

Bottom line: Never use addslashes() for SQL escaping.

Use Prepared Statements (Parameterized Queries)

The gold standard for preventing SQL injection is prepared statements with parameterized queries. This approach separates SQL logic from data, so user input is never interpreted as part of the SQL command.

Example using PDO (PHP):

$pdo = new PDO($dsn, $user, $pass);

$stmt = $pdo->prepare("SELECT * FROM users WHERE email = ?");
$stmt->execute([$userEmail]);

$user = $stmt->fetch();

Example using MySQLi:

$mysqli = new mysqli("localhost", "user", "pass", "db");

$stmt = $mysqli->prepare("SELECT * FROM users WHERE email = ?");
$stmt->bind_param("s", $userEmail);
$stmt->execute();
$result = $stmt->get_result();

✅ Why it works:

• The SQL structure is fixed at prepare time.
• User data is sent separately and treated strictly as data.
• No amount of clever input can alter the query logic.

This is context-aware by design—you don’t need to escape manually because the database driver handles it safely.

When You Can’t Use Prepared Statements (Rare)

In rare cases—like dynamic table names or complex full-text search—you can’t use placeholders. In these situations, contextual escaping becomes essential.

1. Escaping Strings: Use Database-Specific Functions

Instead of addslashes(), use the escaping function provided by your database driver:

• PDO: $pdo->quote($string) (but prefer prepared statements)
• MySQLi: $mysqli->real_escape_string($string)

Note: real_escape_string() only works correctly if:

• The connection charset is properly set (e.g., SET NAMES utf8mb4)
• You’re using a supported MySQL client library

$mysqli->set_charset("utf8mb4");
$escaped = $mysqli->real_escape_string($userInput);
$query = "SELECT * FROM posts WHERE title = '$escaped'";

Still risky—only acceptable when prepared statements aren’t feasible.

2. Escaping Identifiers (Table/Column Names)

You can’t use placeholders for table names. Instead:

• Use backticks (in MySQL) and escape them properly.
• Whitelist allowed identifiers when possible.

function quoteIdentifier($identifier) {
    return '`' . str_replace('`', '``', $identifier) . '`';
}

$query = "SELECT * FROM " . quoteIdentifier($tableName);

Even better: avoid dynamic identifiers entirely or use a whitelist:

$allowedTables = ['users', 'posts', 'comments'];
if (!in_array($tableName, $allowedTables)) {
    die("Invalid table name");
}

3. Integers and Other Types

Always cast or validate:

$userId = (int)$input;
$query = "SELECT * FROM users WHERE id = $userId"; // Safe if cast

Or use prepared statements anyway:

$stmt = $pdo->prepare("SELECT * FROM users WHERE id = ?");
$stmt->execute([(int)$input]);

Summary: Defense-in-Depth with Context

The key takeaway: escaping is not one-size-fits-all. The correct defense depends on where and how untrusted data enters your SQL query. Prepared statements handle most cases safely and should be your default. When they can’t be used, apply strict input validation, whitelisting, and proper escaping—with full awareness of the context.

Basically: drop addslashes(), use parameterized queries, and escape intelligently when you absolutely have to.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!