二阶SQL注入是什么？为什么入库时转义还不够？-php教程-PHP中文网

二阶SQL注入是什么？

二阶sql注入是指攻击者提交的恶意数据在第一次被存入数据库后，程序在后续的业务逻辑中再次读取该数据并拼接到新的sql语句中执行，从而触发注入。与一阶注入不同，二阶注入的恶意代码在输入时并未直接执行，而是潜伏在数据库中，等待特定的业务场景将其“唤醒”。这种注入方式通常发生在用户提交数据后，系统将其保存（如注册、评论），然后在另一个页面或功能（如个人资料展示、搜索）中查询并处理这些数据时发生。

二阶SQL注入是什么？为什么入库时转义还不够？

为什么入库时转义还不够？

入库时转义（如使用`addslashes`或手动替换单引号）之所以不够，是因为它破坏了数据的语义完整性。当恶意数据被转义后存入数据库，虽然它在当前的插入语句中是安全的，但当它被取出并用于后续的动态SQL拼接时，转义字符本身可能成为SQL语法的一部分，或者因为上下文环境的变化（如从字符串变为数字比较，或与其他变量拼接）而失效。更关键的是，许多开发者误以为只要入库安全就万事大吉，忽略了后续查询时的二次拼接风险。

二阶SQL注入是什么？为什么入库时转义还不够？

import sqlite3
import os

# 模拟数据库文件
db_file = 'vulnerable.db'
if os.path.exists(db_file):
    os.remove(db_file)

conn = sqlite3.connect(db_file)
cursor = conn.cursor()

# 创建用户表
cursor.execute('CREATE TABLE users (id INTEGER PRIMARY KEY, username TEXT, bio TEXT)')

# 第一步：用户注册，输入包含恶意payload的bio
def register_user(username, bio):
    # 错误的做法：仅对输入进行简单的转义，但未使用参数化查询
    # 这里模拟一个常见的错误认知：认为转义后就安全了
    safe_bio = bio.replace("'", "''") 
    query = f"INSERT INTO users (username, bio) VALUES ('{username}', '{safe_bio}')"
    cursor.execute(query)
    conn.commit()
    print(f"User {username} registered with bio: {safe_bio}")

# 第二步：用户更新个人资料，读取之前的bio并拼接新内容
def update_profile(user_id, new_bio_part):
    # 获取用户的当前bio
    cursor.execute(f"SELECT bio FROM users WHERE id = {user_id}")
    row = cursor.fetchone()
    if not row:
        return "User not found"
    
    current_bio = row[0]
    # 危险操作：将数据库中的旧bio与新输入直接拼接，形成新的SQL值
    # 如果current_bio中包含未正确处理的引号，这里就会出错
    # 注意：这里没有使用参数化查询，而是字符串拼接
    final_bio = f"{current_bio} - {new_bio_part}"
    update_query = f"UPDATE users SET bio = '{final_bio}' WHERE id = {user_id}"
    
    try:
        cursor.execute(update_query)
        conn.commit()
        return "Profile updated successfully"
    except sqlite3.Error as e:
        return f"Error: {e}"

# 模拟攻击流程
# 1. 注册一个用户，bio字段包含一个闭合引号的payload
# payload: \' OR 1=1; --
# 经过replace(\"'\", \"''\")后变成: \'\' OR 1=1; --
# 存入数据库的值是: \'\' OR 1=1; --
register_user("attacker", "\'\' OR 1=1; --")

# 2. 尝试更新该用户的资料
# 此时，数据库中的bio是: \'\' OR 1=1; --
# 新输入的new_bio_part是: Hello
# 拼接后的final_bio是: \'\' OR 1=1; -- - Hello
# 生成的SQL是: UPDATE users SET bio = '\'\' OR 1=1; -- - Hello' WHERE id = 1
# 这个SQL语句在语法上是合法的，但逻辑上可能不会立即报错，除非我们尝试执行一个会导致语法错误的后续操作
# 为了演示二阶注入的典型后果，我们假设有一个搜索功能

def search_bio(keyword):
    # 搜索功能也使用了字符串拼接
    query = f"SELECT * FROM users WHERE bio LIKE '%{keyword}%'
    cursor.execute(query)
    return cursor.fetchall()

# 如果攻击者在注册时注入了一个能改变查询逻辑的payload，比如:
# bio: \' UNION SELECT id, username, password FROM admin--
# 经过转义后存入: \'\' UNION SELECT id, username, password FROM admin--
# 当search_bio被调用时，如果keyword是空或者匹配到该用户，可能会泄露数据
# 但更典型的二阶注入是利用UPDATE或DELETE等写操作

# 让我们看一个更直接的二阶注入例子：删除用户

def delete_user_by_bio(bio_keyword):
    # 根据bio关键词删除用户
    # 这里的bio_keyword来自用户输入，但实际影响的是之前存入的数据
    # 假设我们想删除bio中包含特定标记的用户
    query = f"DELETE FROM users WHERE bio LIKE '%{bio_keyword}%'
    cursor.execute(query)
    conn.commit()
    return f"Deleted users matching: {bio_keyword}"

# 攻击者注册时，bio设置为: \' OR 1=1; DROP TABLE users; --
# 转义后存入: \'\' OR 1=1; DROP TABLE users; --
# 当delete_user_by_bio被调用，传入任意keyword，比如"test"
# SQL变为: DELETE FROM users WHERE bio LIKE '%test%'
# 这本身不会触发DROP TABLE，因为LIKE条件不匹配

# 真正的二阶注入往往发生在：
# 1. 数据存入DB
# 2. 数据被取出
# 3. 取出的数据被用于构建新的SQL语句，且未做充分的安全处理

# 修正后的安全代码示例（使用参数化查询）
def safe_register_user(username, bio):
    cursor.execute("INSERT INTO users (username, bio) VALUES (?, ?)", (username, bio))
    conn.commit()

def safe_update_profile(user_id, new_bio_part):
    cursor.execute("SELECT bio FROM users WHERE id = ?", (user_id,))
    row = cursor.fetchone()
    if not row:
        return "User not found"
    current_bio = row[0]
    final_bio = f"{current_bio} - {new_bio_part}"
    # 使用参数化查询
    cursor.execute("UPDATE users SET bio = ? WHERE id = ?", (final_bio, user_id))
    conn.commit()
    return "Profile updated successfully"

# 关闭连接
conn.close()
print("Script finished.")

上述代码展示了二阶注入的基本原理。在`register_user`函数中，虽然对`bio`进行了简单的转义，但这并不能防止二阶注入，因为转义后的数据仍然可能被后续的`update_profile`或`search_bio`等函数以不安全的方式使用。关键在于，所有与数据库交互的操作都应使用参数化查询（预编译语句），而不是字符串拼接。

Ponder AI

Ponder AI是一款AI思维导图工具，AI知识管理和思维导图工具。

下载

基于程序中某个输入、条件或结果的具体问题

在上面的代码示例中，如果我们关注`update_profile`函数的具体行为，会发现即使`register_user`使用了参数化查询，如果`update_profile`内部在拼接`final_bio`后直接使用字符串格式化生成SQL，依然可能存在风险。例如，如果`new_bio_part`包含特殊字符，而`current_bio`是从数据库中取出的原始数据，两者拼接后的字符串如果直接用于`f-string`生成SQL，且该SQL语句没有被参数化，那么就可能发生注入。具体来说，如果`current_bio`是`admin'--`，而`new_bio_part`是`hacker`，那么`final_bio`就是`admin'-- - hacker`，生成的SQL可能是`UPDATE users SET bio = 'admin'-- - hacker' WHERE id = 1`，这在某些SQL解析器中可能会被解释为注释掉后面的部分，从而导致逻辑错误。

二阶SQL注入是什么？为什么入库时转义还不够？

# 验证二阶注入的具体条件
import sqlite3
import os

db_file = 'second_order_test.db'
if os.path.exists(db_file):
    os.remove(db_file)

conn = sqlite3.connect(db_file)
cursor = conn.cursor()
cursor.execute('CREATE TABLE items (id INTEGER PRIMARY KEY, name TEXT, description TEXT)')

# 攻击者A注册一个商品，description包含恶意payload
# 目标：当管理员查看商品列表时，触发SQL注入
# payload: \' UNION SELECT sql, 2, 3, 4, 5 FROM sqlite_master--
# 注意：sqlite_master表的sql列包含创建表的SQL语句

# 步骤1：插入恶意数据
# 假设我们使用参数化查询插入，确保数据原样存入
cursor.execute("INSERT INTO items (name, description) VALUES (?, ?)", ("Item1", "\' UNION SELECT sql, 2, 3, 4, 5 FROM sqlite_master--"))
conn.commit()

# 步骤2：管理员查看商品详情，系统根据ID查询并显示description
# 假设这是一个管理后台的功能，用于编辑商品
def get_item_for_edit(item_id):
    # 这里模拟一个不安全的查询，直接拼接ID
    # 实际上，ID通常是整数，但如果ID来自用户输入且未验证类型，也可能有问题
    # 更常见的是，description被取出后，用于构建另一个查询
    cursor.execute(f"SELECT * FROM items WHERE id = {item_id}")
    item = cursor.fetchone()
    return item

# 步骤3：管理员修改商品描述，系统将旧的description和新输入拼接
# 假设新输入是"New Info"
# 如果系统直接将取出的description和新输入拼接，然后更新到数据库，且更新语句使用字符串拼接，则可能触发注入

def edit_item_description(item_id, new_desc_part):
    item = get_item_for_edit(item_id)
    if not item:
        return "Item not found"
    old_desc = item[2] # description is the 3rd column
    new_full_desc = f"{old_desc} | {new_desc_part}"
    
    # 不安全的更新：使用字符串拼接
    update_sql = f"UPDATE items SET description = '{new_full_desc}' WHERE id = {item_id}"
    try:
        cursor.execute(update_sql)
        conn.commit()
        return "Description updated"
    except Exception as e:
        return f"Error: {e}"

# 执行编辑
result = edit_item_description(1, "Updated by Admin")
print(result)

# 此时，数据库中的description变成了: \' UNION SELECT sql, 2, 3, 4, 5 FROM sqlite_master-- | Updated by Admin
# 如果接下来有一个搜索功能，或者导出功能，直接使用该description字段进行SQL操作，就可能触发注入

def export_item_description(item_id):
    item = get_item_for_edit(item_id)
    if not item:
        return "Item not found"
    desc = item[2]
    # 假设导出功能需要将description放入一个CSV，但同时也需要记录日志
    # 日志记录可能使用SQL
    log_sql = f"INSERT INTO audit_log (action, details) VALUES ('export', '{desc}')"
    try:
        cursor.execute(log_sql)
        conn.commit()
        return "Exported and logged"
    except Exception as e:
        return f"Log Error: {e}"

log_result = export_item_description(1)
print(log_result)

# 如果audit_log表存在，且details列是TEXT类型，那么上面的INSERT语句会成功
# 但是，如果audit_log的details列有长度限制，或者有其他约束，可能会失败
# 更重要的是，如果攻击者的payload足够长，或者包含特殊的SQL结构，可能会导致整个数据库的结构被泄露

# 验证是否成功注入
# 我们可以检查audit_log表是否有异常数据
cursor.execute("SELECT * FROM audit_log")
logs = cursor.fetchall()
for log in logs:
    print(log)

conn.close()

这个例子展示了二阶注入的一个典型场景：恶意数据在第一次插入时被安全地存储，但在后续的编辑和导出过程中，由于使用了字符串拼接来构建SQL语句，导致恶意数据被执行。关键点在于，任何从数据库中取出的数据，如果再次用于构建SQL语句，都必须被视为不可信，并应使用参数化查询进行处理。