金融网站防护的WAF规则集，核心是启用并调优OWASP核心规则集（CRS）。直接的问题是：默认规则虽全面但可能误拦正常交易请求，导致用户支付失败或登录异常。解决方法不是简单开启或关闭，而是基于金融业务流量的深度分析，进行规则裁剪、阈值调整和异常检测策略的定制化。例如，对转账、支付接口的SQL注入和跨站脚本（XSS）规则必须保持最高防护等级，而对某些扫描器探测的通用规则则可适度放宽频率限制。

金融网站为什么必须启用OWASP核心规则集？

金融网站处理着敏感的账户信息、资金交易和身份数据，是自动化攻击、数据窃取和欺诈的重灾区。OWASP核心规则集（CRS）提供了一个由安全专家维护的、针对常见Web攻击（如注入攻击、跨站脚本、文件包含等）的免费规则库。它就像是WAF的“标准语法词典”，能够识别和拦截绝大多数已知的攻击模式。对于金融行业，不启用CRS等同于将大门敞开给自动化攻击脚本。但关键点在于：CRS的默认设置是为通用Web应用设计的，其严格的阈值和规则可能将金融业务中某些合法但看似异常的操作（如短时间内多次验证码提交、跨境IP的登录尝试）误判为攻击。因此，启用是底线，精细化配置才是防护生效的关键。

OWASP CRS规则集的结构与核心防护领域

OWASP CRS通常以规则组（Rule Groups）的形式组织，每个组针对一类攻击向量。理解这些分组是进行有效配置的前提。主要分组包括：

1. REQUEST-910-IP-REPUTATION组：用于拦截来自已知恶意IP地址、僵尸网络或托管提供商的请求。对于金融网站，可以集成威胁情报源，但需注意避免封锁大型公共VPN出口IP，以免影响合法用户。

2. REQUEST-911-METHOD-ENFORCEMENT组：严格限制HTTP方法。金融网站通常只应允许GET、POST、OPTIONS，严格禁止PUT、DELETE、TRACE等高风险方法。

3. REQUEST-912-DOS-PROTECTION组：提供基础的拒绝服务攻击防护。金融网站需根据API接口的预期访问频率，精细设置请求速率限制（如每秒登录尝试次数、每秒查询交易记录次数）。

4. REQUEST-913-SCANNER-DETECTION组：识别常见的Web应用漏洞扫描器（如Acunetix, Nessus）的指纹。启用此组可有效减少扫描噪音，但需确保不影响安全团队自身的合规扫描。

5. REQUEST-921-PROTOCOL-ATTACK组：防护HTTP协议和编码规避攻击。这是防御注入攻击的前线，对金融网站至关重要。

6. REQUEST-930-APPLICATION-ATTACK-LFI组：防御本地文件包含（LFI）和远程文件包含（RFI）攻击。

7. REQUEST-931-APPLICATION-ATTACK-RFI组：专门针对RFI攻击。

8. REQUEST-932-APPLICATION-ATTACK-RCE组：防御远程命令执行攻击。

9. REQUEST-933-APPLICATION-ATTACK-PHP组：针对PHP应用特定攻击。

10. REQUEST-941-APPLICATION-ATTACK-XSS组：跨站脚本攻击防护。对于有用户交互、评论或客服功能的金融站点，此规则必须启用并调优。

11. REQUEST-942-APPLICATION-ATTACK-SQLI组：SQL注入攻击防护。这是金融网站防护的“心脏”，任何与数据库交互的接口（登录、查询、交易）都依赖于此规则组的保护。

12. REQUEST-949-BLOCKING-EVALUATION组 和 RESPONSE-950-DATA-LEAKAGE组：前者负责综合评分并决定是否拦截请求；后者防止敏感数据（如信用卡号、身份证号）在错误响应中泄露。

针对金融业务场景的规则调优实践

盲目启用所有规则会导致高误报率，影响业务。调优应遵循“学习-测试-部署”循环。

第一步：基线学习与规则裁剪。在WAF上为金融应用开启CRS的“检测模式”（DetectionOnly）或记录模式，运行一个完整的业务周期（如一周），收集所有触发的规则告警。分析日志：哪些规则频繁触发？触发的请求是否来自真实用户的合法操作？例如，规则942100（SQL注入检测）可能因某些复杂的账户查询参数而触发。这时，不是禁用规则，而是通过创建“排除规则”（Exception）或调整“参数解析”（paranoia）级别，将该特定URL或参数从检查中排除。

# 示例：在ModSecurity中为特定API路径禁用特定规则
SecRule REQUEST_URI "@beginsWith /api/v1/transfer" \
    "id:1001,\
    phase:1,\
    nolog,\
    pass,\
    ctl:ruleRemoveById=942100"

第二步：阈值与评分的精细化设置。OWASP CRS使用动态评分机制（Anomaly Scoring）。每个匹配的规则会增加威胁分数，当总分超过阈值（默认5分）时，请求被拦截。金融网站可以对不同风险等级的接口设置不同阈值。例如，核心支付接口的拦截阈值可以降低至3分以提高安全性；而公开的产品信息查询页面阈值可升至7分以减少误报。

# 示例：针对管理后台路径设置更低的拦截阈值
SecRule REQUEST_URI "@contains /admin/" \
    "id:1002,\
    phase:1,\
    nolog,\
    pass,\
    setvar:tx.inbound_anomaly_score_threshold=3"

第三步：业务逻辑攻击防护的补充。标准CRS擅长防御技术漏洞，但对业务逻辑漏洞（如撞库、批量注册、交易金额篡改）防护有限。金融WAF需要定制规则：

撞库攻击防护：监控同一IP在短时间内使用不同用户名/密码对登录接口的尝试，即使每次尝试都符合密码复杂度要求。

# 示例：简易的撞库防护逻辑（需结合WAF的持久化存储功能）
SecRule ARGS:username ".*" \
    "id:1003,\
    phase:2,\
    capture,\
    t:none,\
    setvar:’TX.username_counter_%{time_epoch}’=+1"
SecRule TX:username_counter_%{time_epoch} "@gt 10" \
    "id:1004,\
    phase:2,\
    deny,status:403,\
    msg:’Possible credential stuffing attack detected.’"

敏感操作序列验证：确保关键操作（如大额转账）遵循“登录->验证身份（短信/令牌）->确认”的正确序列，防止直接调用最终确认接口。

部署架构与性能考量

金融网站流量巨大，WAF不能成为性能瓶颈。建议采用：

1. 反向代理模式部署：将WAF（如ModSecurity with Nginx/Apache）部署在应用服务器之前，实现请求过滤和卸载SSL。

2. 关键API的专用规则集：为高频、核心的交易API编写精简、高效的定制规则，减少不必要的正则表达式匹配。

3. 定期规则更新与回归测试：订阅OWASP CRS的稳定版更新，但每次更新前必须在预发布环境进行完整的业务流回归测试，确保新规则不会阻断正常功能。

超越规则集：构建纵深防御体系

WAF及OWASP规则集是重要的一层，但非银弹。完整的金融网站防护需要：

应用层安全开发（DevSecOps）：在代码层面解决安全漏洞，减少对WAF的绝对依赖。

实时监控与智能分析：将WAF日志与SIEM（安全信息和事件管理）系统集成，利用用户行为分析（UEBA）识别偏离基线的异常交易模式。

DDoS专项防护：在网络边界或使用云服务提供商的DDoS缓解服务，应对大规模流量攻击。

最终，金融网站的WAF规则管理是一个持续的过程，其核心是在“安全”与“业务可用性”之间找到动态平衡点。启用OWASP核心规则集是构建可靠安全基线的第一步，而基于对自身业务逻辑的深刻理解进行的持续调优，才是真正发挥其防护价值的关键。