应用层攻击识别应结合请求行为与业务特征

应用层攻击识别的难点，不在于判断某个请求是否异常，而在于理解它是否符合真实业务流程。一个访问者连续打开商品详情页，可能只是正常浏览；但如果同一会话跳过页面加载，直接高频调用库存、优惠或订单接口，风险含义就不同。仅看请求数量，容易误伤真实用户，也可能漏掉低频、分散的攻击。

因此，识别过程应同时观察请求行为与业务特征，把技术信号放回登录、查询、提交、支付、导出等具体流程中分析。

先建立“请求—会话—业务”三层视角

请求层：看单次请求是否异常

请求层可检查方法、路径、参数、请求头、响应状态和响应大小。例如，正常的 REST API 请求通常具有稳定的参数结构；如果参数中出现明显的注入语句、异常编码、超长嵌套内容，或者同一路径持续返回大量错误响应，就需要进入进一步分析。对于 GraphQL，还应关注查询深度、字段数量和是否反复请求高成本字段。

会话层：看行为是否连贯

会话分析关注请求之间的顺序和间隔。真实用户往往先访问页面，再加载资源，随后提交表单；自动化程序可能直接调用提交接口，或者在失败后以固定间隔重复尝试。可以为会话记录登录状态、设备特征、令牌变化、接口序列和失败原因，用于形成请求指纹。单一来源地址只能作为辅助信号，因为移动网络、企业出口和代理服务都可能让多个用户共享地址。

业务层：看动作是否符合规则

业务特征决定了风险判断的上下文。例如，修改收货地址后立即更换支付方式，连续创建并取消多个订单，或在没有完成必要校验的情况下访问高权限数据，往往比普通页面访问更值得关注。业务规则不应只写成“次数过多”，还要描述前置条件、状态变化和结果是否合理。

几类常见场景的识别方法

表中的信号都不宜单独作为最终结论。例如，搜索接口出现大量请求，可能来自数据分析任务，也可能是抓取行为；应结合账号权限、请求内容、访问时段和业务结果判断。

一套可执行的应用层攻击识别流程

1. 梳理关键接口。列出登录、身份验证、搜索、数据读取、写入、导出和管理操作，并标注每个接口的资源消耗、权限要求及正常调用顺序。
2. 采集必要字段。记录时间、会话标识、账号、设备特征、接口路径、参数摘要、响应状态、耗时和业务结果。敏感字段应脱敏或只保存哈希，避免日志本身扩大泄露风险。
3. 建立正常基线。按接口和业务时段观察调用间隔、成功率、参数分布和会话路径。基线应覆盖工作日、活动时段和系统故障期，不能只取某一个安静时段。
4. 组合判断风险。把请求指纹、异常检测和业务规则结合起来。例如“失败登录增加”只是低强度信号；若同时出现设备重复、账号快速切换和验证码失败，风险等级才应明显提高。
5. 分级处置并复盘。低风险可记录并观察，中风险可增加验证或降低单次返回量，高风险再考虑阻断。上线后比较误报率、接口延迟、真实完成率和人工申诉情况，通常经过数个业务周期再调整规则。

规则、模型与人工审核如何取舍

静态规则容易解释，适合处理明确的参数攻击、权限缺失和流程跳步，优点是响应快、上线成本低；缺点是对新型行为和复杂协同不够敏感。统计模型能够发现访问节奏、设备关联和路径组合的异常，适合用户规模较大、行为样本较丰富的系统，但需要持续校准，解释成本也更高。

较稳妥的方式是分层使用：规则负责即时拦截明显风险，模型负责排序和补充信号，人工审核处理高影响动作。对于付款、账号找回、权限变更等不可逆操作，应优先采用可回退或二次确认的处置，而不是直接删除数据或永久封禁。

常见问题

只统计访问量能完成应用层攻击识别吗？

不能。访问量只能说明行为规模，无法解释请求内容、会话顺序和业务结果，低频攻击与分散攻击尤其容易被遗漏。

是否应该优先封禁来源地址？

通常不应直接依赖地址封禁。应结合账号、设备、会话和接口风险；共享网络环境下，单独封禁地址可能影响大量正常用户。

日志需要保存哪些信息？

至少保留时间、接口、会话、账号关联信息、结果状态和耗时，同时对密码、令牌、身份证号等敏感内容脱敏。

如何降低误报？

把规则放入具体业务流程中验证，区分只读与写入操作，并使用分级挑战、延迟处理和人工复核，避免“一次异常就永久阻断”。

归根结底，应用层攻击识别应回答两个问题：请求做了什么，以及它是否符合业务允许的行为路径。只有把技术信号与业务特征结合，才能在发现攻击的同时控制误伤和运营成本。