4.3 蓝队防线：参数化、最小权限与WAF

4.3 蓝队防线：参数化、最小权限与 WAF

本节摘要：本节是注入回合的蓝队收官：参数化查询为何是根治（语句结构先行、数据永不当指令）、最小权限如何给失守封顶、WAF 在纵深里的真实定位（挡扫描器与规模化攻击，不挡定向高手）。三层各就各位，注入的期望损失才能压到可接受。

把入口焊死的三层

红队演示结束，蓝队进场。防线的骨架是三句话：根上不让注入成立（参数化），成立了也不让蔓延（最小权限），蔓延前先拦一道（WAF 与错误处理）。三层的关系不是备胎叠加，而是纵深序列——每一层假设前一层可能失效。把 WAF 当第一道且唯一一道防线的方案，在定向攻击面前等于裸奔。

根治：参数化查询

把上一节的反面教材改写成正确姿势，并看清"为什么"：

# 整改版：占位符传参，语句结构先行
def search_products(keyword: str):
    sql = "SELECT id, name, price FROM products WHERE name LIKE %s"
    return db.execute(sql, (f"%{keyword}%",)).fetchall()
# LIKE 的通配符属于"值"的一部分，随参数一起传，不进语句结构
​

语句先到达数据库完成解析与执行计划，用户输入在绑定阶段才进入——它没有机会改变结构，引号只是引号。ORM 的默认查询接口同样走参数化，但要注意两个例外：手写原生语句片段、以及"表名/列名不能当参数"的场景（排序字段、动态表名）——这两处必须走白名单映射（允许值集合外的输入一律拒绝），而不是拼接入语句：

# 动态排序字段的正确处理：白名单映射
ALLOWED_SORT = {"price": "price", "created": "created_at", "name": "name"}

def list_products(sort_key: str):
    col = ALLOWED_SORT.get(sort_key, "created_at")   # 非白名单一律回落默认
    sql = f"SELECT id, name, price FROM products ORDER BY {col} LIMIT %s"
    return db.execute(sql, (page_size,))
# 结构性输入走白名单，值输入走参数——两类输入两条路，都不拼接原始值
​

封顶：最小权限

应用连接数据库的账号，权限应该穷酸到"多一条都嫌多"：只授业务库、只授必要的表、只授必要的操作，禁掉系统表访问、文件读写、跨库与管理权限。这样即使注入成立，红队能摸到的也只是一个空荡的展馆：

-- 应用账号授权基线（示例）
CREATE USER app_shop IDENTIFIED BY '<托管轮换的强凭证>';
GRANT SELECT, INSERT, UPDATE ON shopdb.products TO app_shop;
GRANT SELECT, UPDATE ON shopdb.orders TO app_shop;
GRANT SELECT ON shopdb.users TO app_shop;      -- 口令列单独视图收窄
-- 不授：DROP/ALTER/FILE/系统库/跨库；管理操作走独立账号与审批流
​

配套动作：迁移脚本的执行账号与运行时账号分离；凭证进密钥管理（呼应密码学误用回合）；定期审计权限清单的膨胀。

外围：WAF 的能与不能

WAF 的真实定位是"流量侧的安检门"：拦已知攻击指纹（上一节那类规则）、挡无差别扫描器的规模化尝试、给来不及改造的旧接口争取时间窗。它拦得住脚本小子，拦不住执意的定向攻击者——编码变形、注释切分、大小写混淆、时序分摊都是成熟的对抗手段。所以 WAF 规则要配"检测模式先行、观察误报、再切拦截"的节奏上线，规则示例：

# WAF 规则示例（语义：命中联合查询注入特征则拦截并记录）
location /api/ {
    if ($arg_kw ~* "(union(\s|\+|%20)+select|or(\s|\+|%20)+'?\d+'?='\d+|extractvalue\(|sleep\(\d+)") {
        return 403;
    }
    proxy_pass http://app_upstream;
}
​

错误处理与 WAF 同属外围：统一错误响应（不回显数据库报错细节）、日志里保留完整细节供蓝队取证——对外沉默，对内透明。

落地清单

注入防御的验收清单压缩成可勾选的几条：代码里不再有用户输入直接拼接的语句（静态扫描纳入持续集成门禁）；动态结构输入全部白名单映射；应用数据库账号按最小权限审计通过；错误响应统一；WAF 规则覆盖注入指纹且处于拦截模式；数据库主机禁止出网。六条全绿，注入回合才算真正收官——此时红队即使再扫一遍，得到的只是报表上干净的拒绝记录。

参数化的本质不是一种写法，而是一种纪律：指令在先、数据在后，边界永远不谈判。守住这条线，注入家族连开场的机会都没有。

存量系统怎么改：一场现实的改造仗

清单是终点，改造是路程。真实项目里最难的从来不是"新代码写对"，而是"旧代码改得动"。按阵痛从小到大排三条路线。路线一：网关层虚拟补丁——对高危接口先上精准 WAF 规则与输入校验，当天止血，为后续改造买时间；适合正在被扫、下周就发版的团队。路线二：热区改造——按"暴露面 × 数据敏感度"给接口排序，先改公网可达且读敏感表的模块，参数化改造通常可在一两个迭代内完成热区覆盖。路线三：框架级收编——把数据访问统一收口到带参数化的封装层，静态扫描把"绕过封装的裸语句"挡在合并请求之外，让旧问题不再新增、新代码永不复发。

# 改造进度看板（示例指标）
拼接语句存量：112 → 84 → 41 → 12     # 静态扫描口径，应单调下降
热区覆盖率：  43% → 78% → 96%        # 公网敏感接口的参数化比例
绕过封装的新增：0 / 月                # 合并请求门禁，违反即驳回
​

改造仗里最值得投资的其实是第三列——门禁。没有门禁，改造速度永远追不上新代码的产生速度，注入面像漏水船舱一边舀一边进。把静态扫描接进持续集成的合并前检查，规则只需一条：新增代码里出现用户输入直拼 SQL 即阻断。这一条规则的价值，往往超过前面所有规则的总和。