Skip to content

v0.1

Choose a tag to compare

View all tags
@huaimeng666 huaimeng666 released this 21 Jul 06:23
· 14 commits to main since this release
v0.1
cf5e820

优化与改进记录

本工具在初始版本的基础上，进行了一系列旨在提升准确性、健壮性和可用性的核心功能优化。

1. 自定义敏感信息正则

  • 问题:
    • 原版本将敏感信息的正则表达式硬编码在程序中，用户无法根据自己的需求灵活地添加、修改或删除规则。
  • 解决方案:
    • 对配置加载逻辑进行了重构。现在，所有的敏感信息匹配规则（如AKSK, Email, Phone等）都已外置到 config.yaml 文件中。
    • 用户可以直接编辑 config.yaml 的 infoFind 部分，为任意一个类别（如Phone）添加新的正则表达式，或者创建全新的类别和规则，实现了完全的自定义和可扩展性。

2. 扩展敏感信息规则库

  • 问题:
    • 原版内置的正则规则较少，仅能覆盖几种常见的个人信息。
  • 解决方案:
    • 极大地扩展了默认的敏感信息规则库，新增了对 AK/SK, UUID Token, Webhook, Grafana密钥, 数据库连接字符串(JDBC) 等8种以上高价值目标的检测能力，使工具的发现范围和实战价值得到质的提升。

3. 敏感信息报告逻辑重构

  • 问题:
    • 原版在生成报告时，为每一种敏感信息（如手机、邮箱）都编写了独立的、重复的输出代码，导致代码冗长且难以维护和扩展。
  • 解决方案:
    • 对敏感信息的存储结构（mode.Info）和报告生成函数（如OutFileCsv, Print）进行了彻底重构。新的设计采用统一的键值对（Key-Matches）来存储所有类型的发现，并使用一段通用的循环逻辑来生成报告。
  • 价值:
    • 此项重构不仅减少了超过80%的重复代码，还极大地提升了程序的可扩展性。现在，当新增一种敏感信息规则时，开发者不再需要修改任何报告相关的代码，程序会自动适应并正确输出新类型的结果。

4. 邮箱发现功能优化

  • 问题:
    1. 漏报: 最初的正则只能匹配到位于行首的邮箱，导致遗漏大量硬编码在代码中间的邮箱地址。
    2. 误报: 简单的正则无法区分真实的邮箱和格式碰巧类似邮箱的普通字符串。
  • 解决方案:
    1. 修正正则: 去掉了正则表达式中的行首限定符 (^)，确保能发现所有位置的潜在邮箱。
    2. 引入二次验证: 在 crawler/find.go 中，对所有正则匹配到的结果，引入Go标准库 net/mail 进行权威的RFC格式校验，只有通过校验的才被认定为有效邮箱，极大地降低了误报率。

5. IP地址发现功能优化

  • 问题:
    1. 误报: 工具会将某些加密算法的OID常量（如2.16.840.1.101.3.4.1.42）错误地识别为IP地址。
    2. 代码健壮性: 原有的IP地址过滤逻辑为自定义实现，不够专业和全面。
  • 解决方案:
    1. 重构验证函数: 在 crawler/find.go 中，重写了 isLikelyRealIP 函数。新函数使用标准库 net.ParseIP 进行格式验证，并用 ip.IsUnspecified() 等标准方法替代了手写的过滤规则，使代码更健壮、意图更清晰。
    2. 更新黑名单: 根据实际案例，在OID过滤列表中加入了新的前缀，以精确屏蔽由加密常量导致的误报。

6. 正则表达式健壮性修复

  • 问题:
    • 程序中部分用于解析HTML的正则表达式存在语法缺陷，在遇到特定边缘情况时可能导致程序崩溃。
  • 解决方案:
    • 全面审查并修正了这些存在缺陷的正则表达式，通过使用反引号定义等方式，避免了特殊字符的转义问题，提升了爬虫的稳定性。

7. 敏感信息报告去重

  • 问题:
    • 如果同一个文件中多次出现相同的敏感信息（如同一个IP或同一个密钥特征），报告中会产生大量重复条目，干扰核心信息的提取。
  • 解决方案:
    • 在 crawler/find.go 的 infoFind 函数中，实现了一套精确的去重逻辑。该逻辑会以【来源文件名】和【具体匹配到的值】作为联合键，确保任何一个具体的值在同一个文件中只被报告一次，显著提升了报告的信噪比和可用性。

8. URL及JS链接去重优化

  • 问题:
    • 在对大型网站进行扫描时，经常会发现大量指向相同内容的URL（例如，多个API接口返回大小和内容都一致的JSON数据），导致最终报告中存在大量冗余信息，难以分析。
  • 解决方案:
    • 在 crawler/state.go 中，引入了一套全新的、基于结果属性的去重机制。
    • 去重策略: 程序不再使用对内容极其敏感的MD5哈希校验，而是根据 状态码(Status) + 响应大小(Size) + 页面标题(Title) 这三个核心字段组合成一个唯一键。
    • 实现效果: 只有当一个URL或JS的这三个属性组合是第一次出现时，它才会被记录。这能有效过滤掉所有内容实质上等价的重复链接，同时又保留了被标记为“疑似危险路由”的URL（因为它们的处理逻辑被刻意绕过了去重），极大地提升了报告的清晰度和可用性。
Assets 5
Loading