登录和注册是绝大多数Web应用的第一道门，也是攻击者最常试探的入口。很多开发者认为只要用了ORM框架或者参数化查询就万事大吉，但实际上登录注册模块的SQL注入风险远不止“拼SQL语句”这么简单。从表单字段、验证码校验、密码找回、手机号或邮箱验证，到登录状态令牌的生成与校验，任何一个环节如果存在拼接查询或错误处理不当，都可能导致攻击者绕过认证、批量拉取用户数据，甚至直接拖库。账户数据一旦泄露，不只是用户密码重置的问题，还涉及身份证、手机号、邮箱、地址等敏感信息的批量流出，后续的撞库、诈骗、精准钓鱼会持续放大损失。

真正有效的防注入设计，必须从登录注册模块的每一个数据入口和数据出口去审视。先看最基础的登录逻辑。很多系统登录时执行的SQL类似“SELECT * FROM users WHERE username='输入值' AND password='输入值'”。如果开发者为了省事，把用户输入直接拼接进SQL字符串，攻击者输入一个单引号就能破坏原有语法结构。例如用户名输入“admin' -- ”，后面的密码校验部分就被注释掉，直接以管理员身份登录。即便密码做了MD5或SHA加密，只要SQL本身是拼接的，攻击者依然可以通过构造永真条件绕过密码验证。所以登录模块的第一条铁律是：任何来自用户的输入都不能直接进入SQL执行链路，必须使用预编译语句或参数化查询。

参数化查询的核心在于SQL逻辑与数据分离。以Java的JDBC PreparedStatement为例，正确写法是把SQL模板固定，用问号占位，再通过setString等方法绑定参数。这样数据库驱动会把参数当作纯数据处理，不会解析其中的SQL关键字或引号。很多团队误以为ORM框架天然防注入，其实ORM在复杂查询、原生SQL、动态排序字段等场景下依然可能拼接字符串。比如根据用户选择的排序字段拼接“ORDER BY”后面的内容，如果这个字段值来自前端且未做白名单校验，攻击者可以传入“id; DROP TABLE users--”之类的载荷。登录注册模块里常见的动态查询包括“按用户名或手机号或邮箱登录”，有些代码会根据输入内容动态拼接不同的WHERE条件，这种位置必须逐一检查是否全部使用了绑定参数。

注册模块的注入风险往往比登录更隐蔽。注册时通常需要校验用户名、手机号、邮箱是否已存在。很多系统会执行类似“SELECT COUNT(*) FROM users WHERE username='输入值'”的查询。如果这个查询是拼接的，攻击者可以在注册表单里提交带有SQL片段的用户名，通过返回结果判断数据库结构，甚至利用时间盲注逐字符猜解数据。更危险的是，部分注册接口在插入数据时使用了拼接的INSERT语句，攻击者可以构造多语句执行，在插入用户的同时向其他表写入恶意数据。因此注册模块的所有存在性检查、插入操作、验证码校验查询，都必须参数化。

密码找回和重置功能是SQL注入的重灾区。很多找回流程会先根据用户提交的邮箱或手机号查询账户是否存在，再生成重置令牌。这个查询如果拼接，攻击者可以直接注入获取任意账户的关联信息。还有的系统在重置密码时执行“UPDATE users SET password='新密码' WHERE token='用户提交的token'”，如果token字段拼接了用户输入，攻击者可以构造永真条件，把全表用户的密码都改成自己指定的值。正确的做法是：重置令牌必须随机生成并单独存储，查询和更新时全部使用参数化绑定，同时限制令牌有效期和使用次数。

验证码和短信验证码环节也不能忽视。有些系统验证短信验证码时执行“SELECT * FROM sms_codes WHERE phone='手机号' AND code='验证码'”，如果拼接了手机号或验证码，攻击者可以通过注入绕过验证码校验，直接进入下一步重置密码或登录。即便验证码本身是数字，只要进入SQL语句的方式是字符串拼接，就存在被注入的可能。统一使用参数化查询后，这类风险基本可以消除。

除了参数化查询，数据库权限最小化是第二道防线。登录注册模块使用的数据库账号，不应该拥有DDL权限、文件读写权限或对其他无关表的访问权限。很多拖库事件之所以严重，是因为应用使用的数据库账号拥有过高权限，一旦注入成功，攻击者可以直接读取information_schema、执行LOAD_FILE、INTO OUTFILE，甚至通过xp_cmdshell执行系统命令。正确的做法是：为登录注册模块单独创建数据库账号，只授予对users、tokens、验证码表等必要表的SELECT、INSERT、UPDATE权限，禁止DELETE、DROP、ALTER等权限。这样即使某个查询点被注入，攻击者也无法直接拖走整库或破坏数据。

输入验证和输出编码是防注入的第三道防线。参数化查询解决的是SQL执行层面的注入，但输入验证可以提前拦截明显非法的数据。登录用户名、手机号、邮箱、验证码等字段，应该在服务端做严格的白名单或格式校验。用户名只允许字母、数字、下划线，长度限制在合理范围；手机号必须符合数字格式；邮箱必须符合邮箱格式。对于不符合格式的输入，直接拒绝请求，不进入数据库查询。输出编码则主要防止存储型XSS与注入的联动攻击，虽然与SQL注入直接关系不大，但如果攻击者通过注册接口写入恶意脚本，后续在管理后台展示用户列表时触发XSS，同样可以窃取管理员会话，进而操作数据库。所以注册时对用户输入做HTML实体编码或过滤，是必要的补充。

登录注册模块还需要关注错误信息的泄露。很多系统在登录失败时会返回“用户名不存在”或“密码错误”，这本身不是注入问题，但攻击者可以通过注入手段让数据库报错，从错误详情中获取表名、字段名甚至数据片段。生产环境必须关闭数据库错误的直接回显，统一返回模糊的“登录失败”或“系统繁忙”。开发调试时使用的详细错误堆栈，绝对不能出现在生产响应中。同时，应用层要捕获所有数据库异常，记录到服务端日志，但不向前端输出任何SQL语句或数据库结构信息。

还有一个容易被忽略的点是登录注册接口的批量枚举风险。即使SQL注入被完全封堵，攻击者仍然可以通过自动化工具批量尝试用户名和密码。如果登录接口没有频率限制、锁定机制或验证码，攻击者可以用撞库方式获取大量账户。这与SQL注入属于不同的攻击类型，但同样会导致账户数据泄露。有效的防护包括：登录失败次数限制、账号临时锁定、IP维度限流、图形验证码或行为验证、短信验证码二次校验等。注册接口也要限制同一IP或设备在单位时间内的注册次数，防止攻击者批量注册垃圾账号用于后续攻击。

在代码实现层面，下面给出一个典型的登录查询参数化写法示例，以Java JDBC为例：

String sql = "SELECT user_id, username, password_hash, status FROM users WHERE username = ?";
try (PreparedStatement ps = connection.prepareStatement(sql)) {
    ps.setString(1, username);
    try (ResultSet rs = ps.executeQuery()) {
        if (rs.next()) {
            // 校验密码哈希、检查账户状态等
        }
    }
}

这个写法中，用户名完全作为参数绑定，无论用户输入什么内容，都不会改变SQL语句的结构。密码校验必须在查询后使用安全的哈希比对函数完成，不能在SQL中直接比较明文密码或简单哈希。对于注册时的存在性检查，同样使用参数化查询：

String checkSql = "SELECT COUNT(*) FROM users WHERE username = ? OR email = ? OR phone = ?";
try (PreparedStatement ps = connection.prepareStatement(checkSql)) {
    ps.setString(1, username);
    ps.setString(2, email);
    ps.setString(3, phone);
    try (ResultSet rs = ps.executeQuery()) {
        if (rs.next() && rs.getInt(1) > 0) {
            // 返回对应字段已存在的提示
        }
    }
}

对于动态排序或动态条件，不要直接拼接字段名。可以使用白名单映射，例如前端传入“sort=create_time”，服务端映射到一个允许的字段列表，只有匹配的字段才拼入SQL。任何不在白名单中的值，使用默认排序字段。这样可以从根源上避免通过排序参数注入。

在存储层面，用户密码绝对不能明文存储。推荐使用bcrypt、scrypt或Argon2等自适应哈希算法，并配合随机盐。即使数据库被拖走，攻击者也难以快速还原明文密码。对于手机号、邮箱、身份证等敏感信息，建议在数据库中使用加密存储或脱敏存储。登录注册模块涉及的用户表，应该单独设计，避免与其他业务表混在一起，缩小泄露影响范围。同时，定期审计数据库账号权限、慢查询日志和异常登录日志，可以及时发现注入尝试和异常访问行为。

很多企业认为只要上线前做一次渗透测试就够了，但登录注册模块的防护是持续的过程。新的攻击手法和绕过技巧不断出现，比如利用JSON格式输入绕过WAF、利用Unicode字符混淆、利用二次编码绕过过滤等。因此，除了代码层面的参数化查询，还应该在应用前面部署Web应用防火墙，配置针对SQL注入特征的检测规则。WAF不能替代代码修复，但可以作为应急拦截和攻击溯源的有效补充。同时，安全团队应定期对登录注册接口进行模糊测试和注入测试，验证防护措施是否仍然有效。

账户数据泄露的后果往往在泄露发生后很久才会完全显现。攻击者拿到一批用户名和密码后，会去其他平台尝试撞库，因为大量用户习惯在不同网站使用相同密码。即使你的系统本身没有存储明文密码，攻击者通过注入获取到密码哈希后，也可能离线破解弱密码，再用于其他平台。因此，登录注册模块的防注入不仅是保护自己的数据库，也是在保护用户在整个互联网上的账户安全。从参数化查询、权限最小化、输入验证、错误处理到频率限制，每一层都需要落实到位，才能最大程度杜绝因SQL注入导致的账户数据泄露。