针对给定登录代码的SQL注入攻击实现及风险缓解方案咨询

一、能否实施SQL注入？ #

结论很明确：这段代码采用了参数化查询，不管在用户名输入框输入什么内容，都无法触发SQL注入攻击。

你看代码里的查询语句用?作为占位符，随后将username和hashString以参数数组的形式传给db.get——这种参数化查询的机制下，数据库驱动会把传入的参数当作纯数据处理，不会将其解析为SQL指令的一部分。比如你输入' OR 1=1 --这类常见的注入字符串，数据库只会把它当作普通的用户名去匹配，不会篡改原SQL的逻辑。

至于密码输入框，正如你观察到的，密码在传入查询前已完成哈希处理，且同样通过参数化方式传递，所以更不可能通过密码框实施注入。

二、风险缓解措施 #

虽然这段代码在SQL注入防护上是安全的，但仍有可以优化的风险点：

• 坚持使用参数化查询：绝对不要改成字符串拼接的写法（比如SELECT * FROM users WHERE username = '${username}'），这种写法是SQL注入的高发区。
• 正确实现密码哈希加盐：不要用全局统一盐，给每个用户生成独立的随机盐，同时选用bcrypt、Argon2这类专门的密码哈希算法，避免使用MD5、SHA-1这类已被破解的弱算法。
• 隐藏数据库错误信息：代码中数据库出错时仅在控制台打印错误，不要将错误内容返回给前端，防止泄露数据库表结构、字段名等敏感信息。
• 限制登录失败次数：添加验证码或账号临时锁定机制，抵御暴力破解攻击。
• 对输入做基础校验：比如限制用户名仅允许字母、数字、下划线，控制输入长度，提前过滤明显的恶意输入。

内容的提问来源于stack exchange，提问作者BHughes