SQL注入防护与管理员账号越权防范策略

如何防止SQL注入导致的管理员账号越权

SQL注入防护必须从参数化查询开始

道理很简单：如果不改变查询的构造方式，无论在前端加多少层校验，都拦不住类似 admin' OR '1'='1 这样的输入。核心原则就一条——让用户输入的数据，永远不要直接参与SQL语句的拼接。

• PHP：务必使用 mysqli_prepare() 或 PDO::prepare() 配合 bindParam() 进行参数绑定。像 mysqli_query("SELECT * FROM user WHERE name = '$name'") 这种写法，必须彻底杜绝。
• Ja va：使用 PreparedStatement，将SQL写成 SELECT * FROM user WHERE username = 的形式，再通过 setString(1, input) 来设置参数。
• Node.js：使用 pg 库时，记得传递数组参数：client.query('SELECT * FROM user WHERE username = $1', [input])；mysql2 库同理，使用 占位符加参数数组。
• ORM框架：像 Django ORM、Sequelize 这类框架，默认的查询方法是安全的。但一旦调用了 raw() 或 extra() 这类执行原始SQL的方法，防护墙就可能被击穿。因此，所有此类调用都必须经过严格的人工审查。

登录验证逻辑里混入多因子不是加个信息就完事

多因子认证（MFA）必须与初始的身份认证步骤解耦，否则极易被绕过。举个例子，如果登录接口直接返回 {"status":"success","token":"xxx"}，前端收到后就跳转到后台页面，那么后面的MFA校验就完全成了摆设。

• 会话级绑定MFA挑战：用户密码验证通过后，服务端应生成一个唯一的 mfa_challenge_id 并存入Redis（务必设置TTL）。后续所有的信息或OTP验证请求，都必须携带这个ID。
• 后端掌控流程：切忌在前端用Ja vaScript判断“密码正确就显示验证码框”。所有流程分支的决策权都应交给后端，通过返回明确的状态码（例如 401 MFA_REQUIRED）来驱动。
• 敏感操作二次验证：对于修改管理员权限这类高危操作，不能只依赖登录时的一次MFA。需要在执行操作前进行二次激活验证。可以通过 session.get('mfa_verified_at') 来检查验证状态是否过期（建议有效期设为15分钟）。
• 密钥分离存储：TOTP的密钥和备份码必须分开存放。TOTP密钥应存入数据库的加密字段，而备份码则需要哈希处理后存入另一张表。这样做是为了避免单点泄露导致整个认证体系失效。

管理员账号越权的关键拦截点在会话与权限分离

许多系统将“登录成功”与“拥有管理员权限”这两个概念混为一谈，这正是越权漏洞滋生的温床。管理员身份必须作为独立的一环进行校验，并且最好在每次关键请求时都重新确认。

• JWT令牌内容：不要在JWT里直接放入 "role": "admin" 这类静态权限字段。正确的做法是只存放 user_id，然后在每个需要权限判断的接口处，通过查询数据库（或缓存）来实时确认当前用户的权限，例如执行 SELECT is_admin FROM users WHERE id = 。
• RBAC权限检查：权限判定不能依赖于前端传来的 action 字符串。比如一个 POST /api/user/update 请求，即使请求体里带着 {"target_id": "1", "role": "admin"}，后端也必须根据当前登录者的ID和目标ID，进行严格的关系判断（例如是否属于同一租户、是否拥有 assign_role 的权限）。
• 超级管理员也需设限：即使是 root 用户，也不应无条件放行所有API。可以为其增加 scope 字段，明确限定可访问的范围，例如 ["user:read", "tenant:manage"]。
• 审计日志记录：在操作日志中，必须同时记录 auth_user_id（认证用户ID）和 effective_user_id（实际操作生效的用户ID，例如代管场景）。缺少任何一环，都将无法追溯越权操作的真正来源。

测试时最容易漏掉的其实是“组合路径”

单独测试SQL注入，或者单独测试MFA逻辑，往往都能通过。但攻击者擅长“组合拳”：先用SQL注入获取一个低权限账号的会话凭证，再利用这个凭证绕过登录流程，直接攻击MFA验证接口，最终实现权限提升。

• 检查Cookie属性：使用Burp Suite等工具抓包重放时，要重点关注 /login 接口返回的 Set-Cookie 头是否设置了 HttpOnly 和 Secure 属性。如果没有，Cookie可能被前端Ja vaScript窃取，使得MFA形同虚设。
• 验证接口防护：测试 /api/mfa/verify 这类接口时，检查其是否校验了请求的 Referer 或 Origin 头，以防止CSRF攻击伪造验证请求。
• 警惕令牌复用：检查密码重置流程是否与MFA激活流程复用了同一套令牌机制。如果重置密码的token也能用来激活MFA，就等于为攻击者开辟了第二条提权路径。
• 缓存Key安全：检查Redis中存储的 mfa_challenge_* 这类Key。如果未设置合理的过期时间，或者使用了易于枚举的固定前缀（如 mfa:123），就可能面临被爆破的风险。

说到底，越权问题从来不是某个函数写错那么简单。它往往是权限判定逻辑分散在各处、用户状态未能严格隔离、系统信任边界模糊所共同导致的结果。最危险的状况，或许不是没有部署MFA，而是部署了MFA，却错误地把它当成了登录验证的终点站。