HaE（HTTP Analysis and Extraction）是一款基于Burp Suite开发的插件，采用乐高积木式模块化设计理念，核心功能是通过多引擎自定义正则表达式，实现对HTTP消息的精细化标记与内容提取，广泛应用于HTTP消息分析、漏洞识别、敏感信息提取等场景，为渗透测试和安全分析工作提供高效支撑。要熟练运用HaE，掌握其正则表达式语法规则是关键，本文将从基本概念、核心语法、引擎特性、实战应用等方面，全面详解HaE正则表达式的使用方法与技巧。

一、HaE正则系统的基本概念

HaE的正则匹配系统基于8个核心字段构建，每个字段都有明确的功能定位和使用要求，共同构成完整的正则匹配规则，确保匹配的精准性和灵活性。各核心字段的具体说明如下：

字段	含义	必填
Name	规则名称，用于简短概括规则的核心作用，便于识别和管理	是
F-Regex	主正则表达式，用于在HTTP消息中初次匹配目标内容，是匹配的基础	是
S-Regex	次正则表达式，用于对F-Regex匹配的结果进行二次筛选和精确提取，可选使用	否
Format	格式化输出字段，用于控制提取内容的显示格式，让结果更具可读性	是
Scope	作用域，指定规则应用的HTTP消息部分，避免无差别匹配导致效率低下	是
Engine	正则引擎，支持DFA和NFA两种类型，根据匹配需求选择	是
Color	匹配内容的高亮显示颜色，便于在Burp Suite中快速识别匹配结果	是
Sensitive	大小写敏感性设置，取值为True（区分大小写）或False（不区分大小写）	是

二、HaE正则表达式核心语法规则

HaE的正则语法基于标准正则表达式扩展而来，增加了适配HTTP消息分析的特殊要求，其中最核心的规则是“需提取内容必须用括号包裹”，在此基础上衍生出F-Regex、S-Regex、Format等相关语法规范。

（一）括号包裹规则

这是HaE正则语法的基础要求，所有需要提取的目标内容，必须用圆括号()包裹，否则HaE无法识别并提取匹配结果。这一规则区别于普通正则表达式的自由匹配，是HaE实现内容提取的关键。

示例对比：普通正则（仅匹配，不提取）：rememberMe=delete HaE格式（匹配并提取）：(rememberMe=delete)

（二）F-Regex（主正则表达式）

F-Regex是HaE正则规则的核心，用于在指定作用域的HTTP消息中，初次查找并匹配目标内容。它完全支持标准正则表达式语法，但必须严格遵循“需提取内容用括号包裹”的规则。F-Regex的匹配范围直接决定了后续提取的基础，因此需要根据目标内容的特征，设计精准的正则表达式。

实际应用示例（YAML格式，HaE规则标准格式）：

# Shiro框架识别（匹配rememberMe或deleteMe特征）
f_regex: (=deleteMe|rememberMe=)

# JWT令牌识别（匹配标准JWT令牌格式）
f_regex: (eyJ[A-Za-z0-9_-]{10,}\.[A-Za-z0-9._-]{10,}|eyJ[A-Za-z0-9_\/+-]{10,}\.[A-Za-z0-9._\/+-]{10,})

# 邮箱地址识别（过滤常见静态资源后缀，避免误匹配）
f_regex: (([a-z0-9]+[_|\.])*[a-z0-9]+@([a-z0-9]+[-|_|\.])*[a-z0-9]+\.((?!js|css|jpg|jpeg|png|ico)[a-z]{2,5}))

上述示例分别针对Shiro框架特征、JWT令牌、邮箱地址设计了精准的F-Regex，通过括号包裹目标内容，确保HaE能够正确提取匹配结果。

（三）S-Regex（次正则表达式）

S-Regex是对F-Regex的补充和优化，用于对F-Regex匹配到的结果进行二次匹配和提取，适用于F-Regex匹配范围过大、需要进一步过滤精准内容的场景。通过S-Regex，可以剔除无效匹配，只保留符合更精细要求的内容，提升提取结果的准确性。

典型使用场景：1. F-Regex匹配范围较广，包含无关内容，需通过S-Regex筛选核心信息；2. 需对F-Regex匹配结果进行进一步过滤，提取特定子内容。

应用示例：

# 提取JavaScript文件路径后，进一步过滤包含敏感操作的路径
f_regex: (["'](/[^"']*\.js)["'])  # F-Regex匹配所有JS文件路径
s_regex: (token|password|auth|login|user)  # S-Regex筛选包含敏感关键词的路径

上述示例中，F-Regex匹配所有JavaScript文件路径，S-Regex则从这些路径中，筛选出包含token、password等敏感关键词的路径，实现更精准的提取。

（四）Format格式化输出

Format字段用于控制提取内容的显示格式，让输出结果更清晰、更符合使用需求。在NFA引擎中，可通过{0}、{1}、{2}等占位符引用捕获组，实现灵活的格式化输出；DFA引擎不支持捕获组，因此Format字段通常仅使用{0}引用完整匹配内容。

格式化语法说明：- {0}：引用F-Regex（或S-Regex）的完整匹配内容；- {1}、{2}等：引用F-Regex（或S-Regex）中第1、2个捕获组的内容；- 支持组合使用占位符，实现复杂的格式化输出。

应用示例：

# 简单格式化（直接输出完整匹配内容）
format: '{0}'

# 组合格式化（拼接两个捕获组的内容）
format: '{0}.{1}'

通过Format格式化，可将提取的内容按照指定格式展示，例如拼接前缀、补充说明等，提升结果的可读性。

三、HaE正则引擎详解

HaE支持两种主流正则引擎——DFA引擎和NFA引擎，两种引擎的特性、适用场景存在显著差异，需根据实际匹配需求选择合适的引擎，以兼顾匹配效率和功能需求。

（一）DFA引擎（Deterministic Finite Automaton）

DFA引擎即确定有限自动机，其核心特点是对文本串中的每个字符只扫描一次，匹配速度快、性能优异，适合大规模文本的快速匹配。但该引擎特性相对简单，不支持复杂的分组、回溯等高级功能，仅能实现基础的字符串匹配。

适用场景：1. 简单的字符串匹配，无需复杂捕获组；2. 大量HTTP消息的快速扫描，对匹配效率要求较高；3. 仅需识别目标内容是否存在，无需提取复杂子内容。

应用示例：

engine: dfa
f_regex: (Druid Stat Index)  # 简单匹配Druid监控页面特征

上述示例使用DFA引擎快速匹配HTTP消息中是否存在“Druid Stat Index”字符串，适合大规模扫描场景。

（二）NFA引擎（Non-deterministic Finite Automaton）

NFA引擎即非确定有限自动机，其核心特点是支持反复标注和取消标注字符，特性丰富，支持分组、替换、分割等高级功能，能够满足复杂正则表达式的匹配需求。但由于其匹配过程中可能存在回溯，速度相对DFA引擎较慢。

适用场景：1. 复杂的正则表达式匹配，需要使用分组、回溯等功能；2. 需要提取多个捕获组内容，或对匹配结果进行格式化输出；3. 对匹配效率要求不高，优先保证匹配的精准性和灵活性。

应用示例：

engine: nfa
f_regex: (jdbc:[a-z:]+://[a-z0-9\.\-_:;=/@?,&]+)  # 匹配数据库连接字符串，需分组提取

上述示例使用NFA引擎匹配数据库连接字符串，利用其分组功能提取完整连接信息，同时支持后续的Format格式化输出。

四、作用域（Scope）设置

Scope字段用于定义正则规则应用的HTTP消息部分，通过精准设置作用域，可以避免在无关内容中进行匹配，大幅提升匹配效率，减少误匹配概率。HaE支持多种作用域类型，覆盖HTTP请求和响应的各个部分，可根据匹配目标灵活选择。

（一）常用作用域类型及应用范围

作用域	应用范围	适用场景示例
any	整个HTTP消息（请求消息+响应消息）	通用内容识别，无需区分请求和响应
request	整个请求消息（请求行+请求头+请求体）	请求特征识别，如请求参数、请求方法等
response	整个响应消息（响应行+响应头+响应体）	响应特征识别，如响应状态码、页面内容等
any header	所有头部（请求头+响应头）	头部信息提取，如Cookie、Token等
request header	仅请求头部	请求头分析，如User-Agent、Referer等
response header	仅响应头部	响应头分析，如Location、Set-Cookie等
any body	所有消息体（请求体+响应体）	消息体内容提取，如POST数据、页面源码等
request body	仅请求体	POST数据分析、请求参数提取等
response body	仅响应体	页面内容分析、敏感信息提取等
request line	仅请求行	URL分析、请求方法（GET/POST等）识别
response line	仅响应行	响应状态码（200/404/500等）识别

（二）作用域实际应用示例

# 在响应体中查找Swagger UI相关特征
scope: response body
f_regex: ((swagger-ui.html)|(\"swagger\":)|(Swagger UI)|(swaggerUi)|(swaggerVersion))

# 在任意头部（请求头+响应头）中查找Shiro框架特征
scope: any header
f_regex: (=deleteMe|rememberMe=)

# 在整个请求消息中查找调试参数（如access、admin等）
scope: request
f_regex: ((access=)|(adm=)|(admin=)|(debug=))

上述示例通过精准设置作用域，分别针对响应体、任意头部、请求消息进行匹配，避免了无关内容的干扰，提升了匹配效率和精准度。

五、HaE正则高级语法特性

除了核心语法规则外，HaE还支持大小写敏感性控制、复杂正则匹配、多行匹配和转义等高级特性，能够满足更复杂的HTTP消息分析需求，进一步提升正则规则的灵活性和精准性。

（一）大小写敏感性控制

Sensitive字段用于控制正则匹配是否区分大小写，取值为True（区分大小写）或False（不区分大小写）。在实际应用中，可根据目标内容的特征选择，例如识别大小写敏感的密钥、令牌时，需设置为True；识别不区分大小写的页面路径、框架特征时，可设置为False。

应用示例：

# 区分大小写（匹配阿里云AccessKey，大小写敏感）
sensitive: true
f_regex: (LTAI[a-z0-9]{12,20})

# 不区分大小写（匹配Swagger UI路径，不区分大小写）
sensitive: false
f_regex: (swagger-ui.html)

上述示例中，阿里云AccessKey的前缀“LTAI”为固定大小写，因此设置sensitive为True；而swagger-ui.html路径可能存在大小写变体（如Swagger-UI.html），因此设置为False。

（二）复杂正则表达式示例

针对常见的敏感信息、特征内容，HaE支持复杂正则表达式的编写，实现精准匹配。以下为几个典型的复杂正则应用示例：

# 身份证号码识别（支持18位身份证，包含校验位X/x，避免前后非数字字符干扰）
f_regex: '[^0-9]((\d{8}(0\d|10|11|12)([0-2]\d|30|31)\d{3}$)|(\d{6}(18|19|20)\d{2}(0[1-9]|10|11|12)([0-2]\d|30|31)\d{3}(\d|X|x)))[^0-9]'

# 手机号码识别（支持中国大陆手机号，包含+86/0086前缀，避免前后非单词字符干扰）
f_regex: '[^\w]((?:(?:\+|0{0,2})86)?1(?:(?:3[\d])|(?:4[5-79])|(?:5[0-35-9])|(?:6[5-7])|(?:7[0-8])|(?:8[\d])|(?:9[189]))\d{8})[^\w]'

# 内网IP地址识别（匹配127.0.0.1、10段、172.16-31段、192.168段内网IP）
f_regex: '[^0-9]((127\.0\.0\.1)|(10\.\d{1,3}\.\d{1,3}\.\d{1,3})|(172\.((1[6-9])|(2\d)|(3[01]))\.\d{1,3}\.\d{1,3})|(192\.168\.\d{1,3}\.\d{1,3}))'
   

上述正则表达式分别针对身份证号码、手机号码、内网IP地址进行精准匹配，通过复杂的正则逻辑，避免误匹配，确保提取结果的准确性。

（三）多行匹配和转义

HaE支持标准正则表达式的转义字符和多行匹配功能，可应对HTTP消息中包含换行、特殊字符的场景。例如，匹配Windows文件路径中的反斜杠（需转义为\\），匹配包含换行的头部信息等。

应用示例：

# 匹配Windows文件路径（反斜杠需转义，避免正则解析错误）
f_regex: '[^\w]([a-zA-Z]:\\\\?(?:[^<>:/\\|?*]+\\\\?)*)([^<>:/\\|?*]+(?:\.[^<>:/\\|?*]+)?)'

# 匹配Location头部（匹配Location: 后的内容，直到换行结束）
f_regex: 'Location: (.*?)\n'
    

上述示例中，Windows文件路径中的反斜杠通过转义字符\\表示，确保正则能够正确识别；Location头部的匹配使用.*?非贪婪匹配，结合\n匹配换行，精准提取Location头部的内容。

六、HaE正则实战应用场景

HaE正则表达式的核心价值在于实战应用，结合其语法规则和特性，可广泛应用于漏洞识别、敏感信息提取、技术指纹识别等场景，为渗透测试和安全分析提供高效支撑。以下为典型实战场景及对应正则规则示例。

（一）漏洞识别

通过匹配漏洞相关的特征字符串，可快速识别HTTP消息中的潜在漏洞，例如Java反序列化漏洞、SSRF漏洞等。

# Java反序列化漏洞识别（匹配javax.faces.ViewState特征，常见于Java反序列化漏洞场景）
name: Java Deserialization
f_regex: (javax\.faces\.ViewState)
scope: response body
engine: dfa
color: yellow

# SSRF漏洞识别（匹配URL作为参数值的场景，可能存在SSRF风险）
name: URL As A Value
f_regex: (=(https?)(://|%3a%2f%2f))
scope: any
engine: nfa
color: cyan
    

上述规则分别针对Java反序列化漏洞和SSRF漏洞的特征进行匹配，通过设置合适的作用域和引擎，实现快速识别。

（二）敏感信息提取

敏感信息提取是HaE的核心应用之一，通过正则匹配，可快速提取HTTP消息中的云服务密钥、数据库连接字符串、账号密码等敏感信息。

# 云服务密钥提取（匹配常见云服务密钥格式，如AccessKey ID/Secret）
name: Cloud Key
f_regex: (((access)(|-|_)(key)(|-|_)(id|secret))|(LTAI[a-z0-9]{12,20}))
scope: any
engine: nfa
color: yellow

# 数据库连接字符串提取（匹配JDBC连接字符串，包含数据库地址、账号等信息）
name: JDBC Connection
f_regex: (jdbc:[a-z:]+://[a-z0-9\.\-_:;=/@?,&]+)
scope: any
engine: nfa
color: yellow
    

上述规则可快速提取云服务密钥和数据库连接字符串，帮助安全人员及时发现敏感信息泄露问题。

（三）技术指纹识别

通过匹配各类技术框架、组件的特征字符串，可识别目标系统使用的技术栈，为渗透测试提供方向。

# 前端框架识别（匹配Ueditor富文本编辑器特征）
name: Ueditor
f_regex: (ueditor\.(config|all)\.js)
scope: response body
engine: dfa
color: green

# PDF.js Viewer识别（匹配PDF.js的worker文件特征）
name: PDF.js Viewer
f_regex: (pdf.worker)
scope: response body
engine: dfa
color: green
    

上述规则通过匹配Ueditor、PDF.js等组件的特征文件，快速识别目标系统使用的前端组件，为后续的漏洞挖掘提供参考。

七、HaE正则性能优化建议

在实际使用中，若正则规则设计不合理，可能导致匹配效率低下、误匹配率高，甚至影响Burp Suite的运行性能。以下从引擎选择、作用域设置、正则优化三个方面，提供性能优化建议。

（一）引擎选择策略

引擎的选择直接影响匹配效率，需根据正则规则的复杂度和匹配需求合理选择：1. 简单字符串匹配、大规模扫描场景，优先选择DFA引擎，利用其快速匹配的优势；2. 复杂正则、需要分组提取、格式化输出的场景，选择NFA引擎，兼顾功能需求；3. 避免在简单匹配场景中使用NFA引擎，减少不必要的性能消耗。

（二）作用域优化

精准设置作用域是提升匹配效率的关键，核心原则是“最小化匹配范围”：

1. 明确匹配目标所在的HTTP消息部分，避免使用“any”（整个消息）作用域；
2. 例如，匹配页面内容中的特征，设置为“response body”，而非“any”；
3. 合理区分header和body，避免在header中匹配body的内容，反之亦然。

（三）正则表达式优化

正则表达式的编写质量直接影响匹配效率和精准度，可通过以下方式优化：

1. 使用非贪婪匹配.*?替代贪婪匹配.*，避免过度回溯，减少匹配时间；
2. 避免过度使用回溯和嵌套分组，复杂场景可拆分正则，通过F-Regex+S-Regex实现；
3. 合理使用字符类[a-z0-9]替代选择结构(a|b|c|...)，提升匹配速度；
4. 增加边界限制（如[^0-9]、[^w]），避免部分匹配导致的误匹配。

八、HaE正则匹配核心实现原理

HaE的正则匹配核心逻辑在RegularMatcher类中实现，其核心流程包括缓存检查、多线程处理、作用域筛选、引擎匹配、二次提取、格式化输出等步骤，确保匹配效率和功能完整性。

核心代码片段（Java）

public Map<String, Map<String, Object>> match(String host, String type, String message, String header, String body) {
    // 缓存检查：避免重复匹配同一HTTP消息，提升效率
    String messageIndex = HashCalculator.calculateHash(message.getBytes());
    Map<String, Map<String, Object>> map = MessageCache.get(messageIndex);
    
    // 多线程并行处理所有规则，提升匹配速度
    Config.globalRules.keySet().parallelStream().forEach(i -> {
        // 1. 根据scope字段，选择当前规则需要匹配的内容（header/body/message等）
        // 2. 根据engine字段，选择DFA或NFA引擎进行匹配
        // 3. 先执行F-Regex匹配，若存在S-Regex，对结果进行二次匹配
        // 4. 应用Format字段，对提取结果进行格式化处理
        // 5. 将匹配结果存入缓存，返回给前端展示
    });
    return map;
}

上述代码展示了HaE正则匹配的核心流程，通过缓存机制和多线程处理，大幅提升匹配效率，同时通过引擎选择、作用域筛选等步骤，确保匹配的精准性。

完整匹配流程

HaE的正则匹配流程可分为5个步骤，环环相扣，确保匹配结果的精准性和高效性：

1. 缓存检查：首先检查当前HTTP消息是否已匹配过，若有缓存结果，直接返回，避免重复计算；
2. 作用域处理：根据规则的Scope字段，筛选出需要匹配的HTTP消息部分（如响应体、请求头）；
3. 引擎选择：根据Engine字段，调用对应的DFA或NFA引擎，执行F-Regex匹配；
4. 二次匹配：若规则包含S-Regex，对F-Regex的匹配结果进行二次筛选，提取更精准的内容；
5. 格式化输出：应用Format字段的格式化规则，对提取结果进行处理，最终返回给用户。

九、最佳实践总结

结合HaE正则语法规则和实战经验，总结以下最佳实践原则，帮助用户快速编写高效、精准的正则规则，提升HTTP消息分析效率。

（一）规则设计原则

1. 精确性：正则表达式应精准匹配目标内容，避免过度宽泛导致误匹配，可通过边界限制、字符类优化等方式提升精确性；
2. 效率性：根据匹配需求选择合适的引擎和作用域，优化正则表达式结构，减少回溯和无效匹配，提升匹配速度；
3. 可读性：规则名称（Name）应简洁明了，正则表达式可适当添加注释（HaE支持YAML注释），便于后续维护和复用；
4. 可扩展性：复杂场景可拆分规则，通过F-Regex+S-Regex实现分层匹配，便于后续修改和扩展。

（二）常见问题规避

1. 忘记用括号包裹需提取内容：这是最常见的错误，会导致HaE无法提取匹配结果，需牢记“提取内容必用括号包裹”；
2. 过度使用NFA引擎：简单匹配场景使用NFA引擎会浪费性能，应优先选择DFA引擎；
3. 作用域设置过宽：使用“any”作用域会增加匹配范围，导致效率低下，应精准设置作用域；
4. 正则表达式过度复杂：复杂正则易出现回溯过多、误匹配等问题，可拆分规则或优化正则结构。