token本身不防sql注入，盲注风险源于后端未参数化拼接sql——无论jwt、oauth2 token或自定义字符串，只要原始token被直接拼入sql（如where token = 'xxx'），攻击者即可构造abc' and sleep(5)=sleep(5) -- 触发时间盲注；必须通过标准库解析、强转类型、参数化查询，并禁用token字段参与业务sql查询。
Token本身不防SQL注入，盲注风险来自后端拼接SQL时未参数化——无论Token是JWT、OAuth2 access_token 还是自定义字符串，只要它被直接拼进SQL语句，就可能触发盲注。
为什么 Authorization: Bearer xxx 头里的 Token 会引发 SQL 盲注？
常见错误是后端用 Token 做用户身份识别时，没走标准解析流程，而是直接拿原始 Token 字符串去查数据库：
- 比如写成
SELECT * FROM users WHERE token = 'xxx'，而没对xxx做参数绑定 - 攻击者可构造恶意 Token（如
abc' AND SLEEP(5)=SLEEP(5) --），让数据库响应延迟暴露逻辑分支 - 即使 Token 是 JWT，若后端跳过签名验证、直接 base64 解码后取
sub或user_id字段并拼 SQL，同样危险
必须禁用的 Token 使用方式
以下操作在移动端接口中属于高危模式，应立即排查代码库：
Auth0 Token Vault
下载
通过 Auth0 Token Vault，代表已认证用户访问 Gmail、Slack、Google Calendar、GitHub 等第三方服务以及自定义 Auth0 连接。使用...
- 用
req.headers.authorization的原始值（如Bearer eyJhbGciOi...）直接传给db.query()或knex('users').where('token', rawToken) - 从 JWT 中提取
payload.user_id后，不做类型校验和转义，直接拼进WHERE id = ${userId} - 把 Token 当作“可信输入”绕过 ORM 的参数化机制，例如用
sequelize.query('SELECT * FROM logs WHERE token = "' + token + '"')
真正有效的防护组合
防御盲注不是加一层 Token 就行，关键在数据流终点是否安全：
- 所有 Token 解析必须走标准库（如
jsonwebtoken.verify()或oauth2-server），且只取明确字段（如payload.sub），丢弃其余内容 - 取出的用户标识（如
user_id）必须强转为数字或 UUID 格式，再通过参数化查询使用：db.get('SELECT * FROM users WHERE id = ?', userId) - 避免在 SQL 中用 Token 字段做条件查询——改用关联的
user_id或session_id字段；Token 表本身应仅用于校验，不参与业务查询 - 日志中禁止打印原始 Token，
console.log(req.headers.authorization)必须替换为脱敏输出（如log('auth: Bearer ***' + token.slice(-4))）
容易被忽略的边界点
盲注常发生在你以为“这里不会走 SQL”的地方：
- 刷新 Token 接口：若用旧 Token 查询
refresh_tokens表且未参数化，就是盲注入口 - 设备绑定接口：传入的
device_token（APNs/FCM token）若被拼进 SQL，同样可被利用 - 灰度发布开关：用
user_token查feature_flags表时，哪怕只是EXISTS子查询，也得参数化
Token 是认证凭证，不是数据源。任何把它当字符串直接喂给 SQL 的做法，都等于给盲注开后门。
