如何为安全扫描工具编写自定义配置文件？

在实际渗透测试或合规审计中，安全扫描工具往往只有默认配置难以覆盖业务特有的路径、鉴权方式或自定义插件。把配置文件当作“扫描指令的脚本”，把业务规则写进去，工具才能像遵循剧本的演员一样精准演出。

理解配置文件的核心要素

大多数扫描器（如 Xray、Rad、Nessus）采用结构化的文本格式——YAML、JSON 或 INI。核心要素通常包括目标定义、插件/插件组、网络层参数以及输出控制。缺一不可的原因在于：目标决定扫描范围，插件决定检测深度，网络层决定是否走代理或使用特定证书，输出控制则影响后期报告的可读性。

常见格式与语法要点

YAML 最受欢迎，主要是因为它的层级缩进直观。JSON 虽然冗长，却在机器解析时更安全。INI 则适合轻量级的本地工具。无论选哪种，都要注意：

• 键名区分大小写，误用会导致插件失效。
• 列表项必须使用破折号（-）或逗号分隔，不能混用。
• 字符串若包含冒号、空格或特殊字符，需要加引号。
• 文件编码统一为 UTF‑8，避免出现 BOM 造成解析错误。

实战：为 Xray 编写自定义 YAML

下面给出一个针对内部 API 网关的示例。假设网关只接受基于 JWT 的 Bearer Token，且所有请求必须走内部代理 127.0.0.1:1080。我们把这些细节写进 custom_xray.yaml，随后在启动时通过 -c 参数加载。

# custom_xray.yaml
target:
  - url: "https://api.internal.example.com"
    headers:
      Authorization: "Bearer {{jwt_token}}"
    proxy: "http://127.0.0.1:1080"
    timeout: 30

plugins:
  - name: "xss"
    enabled: true
    payloads:
      - "<script>alert(1)</script>"
  - name: "sql_injection"
    enabled: true
    level: "high"

output:
  format: "html"
  dir: "./reports/{{timestamp}}"
  include_raw: false

注意 {{jwt_token}} 与 {{timestamp}} 是占位符，实际运行前可以通过环境变量或前置脚本注入。这样做的好处是：同一套配置可以在不同环境间复用，只需替换几行变量。

调试与迭代

写完配置后，先用 xray -t https://dummy.com -c custom_xray.yaml --dry-run 进行干跑，观察日志里是否出现“未识别的插件”或“缺失必填字段”。如果报错指向某行缩进，直接在编辑器里把相应层级的空格数统一为两个空格；如果提示证书验证失败，检查 proxy 是否带协议前缀。

每一次扫描结束后，把生成的报告与手工复测结果对比，记录误报与漏报的插件名称，回到 plugins 区块里加上 exclude 或调低 level。如此循环，配置文件会逐渐逼近“业务真实感”。