SQL 注入（保姆级教程）

SQL 注入：一场隐藏在代码背后的“数字风暴”

在开发 Web 应用时，数据库是数据的“仓库”，而 SQL 语句则是通往这个仓库的“钥匙”。但你有没有想过，这把钥匙可能被别人悄悄复制、甚至篡改？这就是我们今天要聊的“SQL 注入”——一种常见却危险的网络安全漏洞。

想象一下，你开了一家便利店，顾客要买商品时，需要输入商品编号。你让收银员根据编号去后台系统查询库存。如果系统没有检查输入内容，有人故意输入 1 OR 1=1 --，系统可能就会把所有商品都显示出来。这就像你把钥匙交给别人，还允许他们随意修改钥匙的形状。

这种漏洞不是虚构的，而是真实存在于许多网站中。2017 年，某知名电商平台因 SQL 注入导致数百万用户数据泄露，就是典型案例。所以，作为开发者，我们必须正视它，理解它，防范它。

什么是 SQL 注入？原理与风险

SQL 注入（SQL Injection）是一种攻击手段，攻击者通过在用户输入中插入恶意 SQL 代码，让数据库执行非预期的操作。它的本质是：将用户输入当作代码来执行。

我们来看一个典型的例子。假设有一个登录系统，用户输入用户名和密码后，后端会拼接 SQL 查询：

SELECT * FROM users WHERE username = 'admin' AND password = '123456';

如果前端传来的用户名是 ' OR '1'='1，那么最终拼接出的 SQL 语句就变成：

SELECT * FROM users WHERE username = '' OR '1'='1' AND password = '123456';

由于 '1'='1' 永远为真，整个条件成立，系统会返回所有用户信息，甚至让攻击者绕过密码验证。

这就像你让收银员根据顾客说的“商品编号”查货，结果顾客说“编号是 1 或 1=1”，收银员没检查，直接把所有货都搬出来了。

常见的 SQL 注入类型

这些类型虽然技术细节不同，但核心思想一致：利用输入不验证，让数据库执行攻击者构造的语句。

代码实战：一个危险的登录系统

我们用 Python + SQLite 演示一个存在 SQL 注入漏洞的登录逻辑。

import sqlite3

def login(username, password):
    # 连接数据库
    conn = sqlite3.connect('example.db')
    cursor = conn.cursor()

    # 拼接 SQL 查询语句（危险做法！）
    query = f"SELECT * FROM users WHERE username = '{username}' AND password = '{password}'"
    
    print(f"执行的 SQL: {query}")  # 用于调试，实际环境不应打印

    cursor.execute(query)
    result = cursor.fetchone()

    conn.close()

    if result:
        return "登录成功"
    else:
        return "用户名或密码错误"

print(login('admin', '123456'))        # 正常登录
print(login('admin', "123456' OR '1'='1"))  # 攻击：绕过验证

关键问题就在这行：

query = f"SELECT * FROM users WHERE username = '{username}' AND password = '{password}'"

这里直接把用户输入拼接到 SQL 字符串中，没有任何过滤。攻击者只要输入 admin' OR '1'='1，就能让条件永远为真。

💡 注释：f-string 拼接是常见但危险的操作。它让输入像“调料”一样混进 SQL 语句，一旦被恶意利用，后果严重。

如何防御 SQL 注入？安全实践指南

1. 使用参数化查询（推荐做法）

参数化查询是防御 SQL 注入的“黄金标准”。它将 SQL 语句和数据分开处理，数据库引擎只把输入当作数据，不会当作代码执行。

def safe_login(username, password):
    conn = sqlite3.connect('example.db')
    cursor = conn.cursor()

    # 使用参数占位符，而不是字符串拼接
    query = "SELECT * FROM users WHERE username = ? AND password = ?"
    
    # 传入参数，由数据库引擎安全处理
    cursor.execute(query, (username, password))
    result = cursor.fetchone()

    conn.close()

    if result:
        return "登录成功"
    else:
        return "用户名或密码错误"

print(safe_login('admin', '123456'))           # 正常登录
print(safe_login('admin', "123456' OR '1'='1")) # 无效，输入被当作字符串处理

💡 注释：? 是 SQLite 的参数占位符。数据库会自动对参数进行转义，即使输入包含 ' 或 OR，也不会被当作 SQL 代码解析。

2. 输入验证与过滤

即使使用参数化查询，也应进行输入校验。例如，限制用户名只能包含字母、数字、下划线：

import re

def validate_input(username, password):
    # 只允许字母、数字、下划线，长度 3-20
    if not re.match(r'^[a-zA-Z0-9_]{3,20}$', username):
        return False, "用户名格式错误"
    if len(password) < 6:
        return False, "密码至少6位"
    return True, ""

valid, msg = validate_input('admin123', '123456')
if not valid:
    print(msg)  # 输出错误信息

3. 使用 ORM 框架（如 SQLAlchemy）

ORM（对象关系映射）框架会自动处理 SQL 安全问题。例如：

from sqlalchemy import create_engine, Column, Integer, String
from sqlalchemy.ext.declarative import declarative_base
from sqlalchemy.orm import sessionmaker

Base = declarative_base()

class User(Base):
    __tablename__ = 'users'
    id = Column(Integer, primary_key=True)
    username = Column(String(50))
    password = Column(String(50))

engine = create_engine('sqlite:///example.db')
Session = sessionmaker(bind=engine)
session = Session()

user = session.query(User).filter_by(username='admin', password='123456').first()

💡 注释：ORM 会自动生成参数化查询，极大降低 SQL 注入风险。但需注意，避免使用 text() 函数直接写 SQL。

常见误区与陷阱

误区 1：只过滤单引号就安全了

很多人觉得只要把 ' 替换成 '' 就安全了，这是错误的。攻击者可以使用其他方式绕过，比如：

• 使用 UNION SELECT 拼接查询
• 利用注释符 -- 截断 SQL 语句
• 使用编码（如 URL 编码）绕过检测

误区 2：只在前端做校验

前端校验可以提升用户体验，但不能作为安全屏障。攻击者完全可以通过浏览器开发者工具或 Postman 直接发送请求，绕过前端逻辑。

误区 3：认为“小项目”不需要担心

哪怕是一个个人博客，只要涉及数据库查询，就可能存在 SQL 注入风险。攻击者可能利用它窃取管理员账号、上传恶意内容，甚至控制整个服务器。

检测与扫描工具推荐

虽然我们强调“预防为主”，但定期检测也很重要。以下是几个实用工具：

• sqlmap：开源自动化注入工具，可用于测试系统是否易受攻击（仅限授权测试）
• OWASP ZAP：Web 应用安全扫描器，支持 SQL 注入检测
• Burp Suite：专业安全测试工具，支持手动与自动检测

⚠️ 提示：使用这些工具时，务必获得目标系统的合法授权，否则可能触犯法律。

总结：安全是开发者的责任

SQL 注入不是“黑客专属技能”，而是每一个开发者都应掌握的基本安全常识。它就像代码中的“地雷”，可能藏在最不起眼的拼接语句里。

我们不能依赖“运气”或“没被攻击过”来判断系统安全。真正的安全，来自于习惯：使用参数化查询、校验输入、避免拼接 SQL。

记住：每一条动态 SQL，都是一个潜在的入口。你写的每一行代码，都可能成为别人攻击的跳板，也可能成为保护系统的盾牌。

作为开发者，我们不仅在写功能，更在守护用户的数据与信任。从今天起，把“安全”写进代码习惯里，让每一次数据库操作都经得起考验。

SQL 注入虽然危险，但只要我们用对方法，它就不再是“数字风暴”，而是可以被驯服的“数据助手”。