SQL注入防護不能依賴addslashes()，因其不處理多字節(jié)編碼且僅轉(zhuǎn)義有限字符，易被繞過；應使用預處理語句（如PDO或MySQLi的參數(shù)化查詢）將數(shù)據(jù)與SQL邏輯分離，確保輸入不被解析為代碼；若無法使用預處理，需根據(jù)上下文采用數(shù)據(jù)庫特定的轉(zhuǎn)義函數(shù)（如real_escape_string并設(shè)置正確字符集）、標識符白名單或引號包裹、整型輸入強制類型轉(zhuǎn)換等方法，實現(xiàn)分層防御。

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.

The above is the detailed content of Beyond `addslashes()`: Contextual Escaping for Robust SQL Injection Defense. For more information, please follow other related articles on the PHP Chinese website!