★ FEATURED ARTICLE 做安全测试这行最怕的不是系统有多难攻而是自己人的结论对不上。上个月我们三个工程师对同一套预发环境分别测完一份说“高风险漏洞已修复”一份说“还存在会话固定问题”第三份压根没跑到那个模块。没人偷懒问题出在流程没有可验证的出口。后来我把整个渗透测试流程拆成一个个能用 pytest 断言验收的子任务每个子任务回答一个明确的问题跑完直接出结构化报告。这个工程仓库内部代号就叫 arxiv算是把自己从论文归档的思路搬到了安全测试上。这篇文章把整套方法讲一遍为什么拆、怎么拆、如何落地以及我踩过的坑。1. 为什么把渗透测试拆成 pytest 能断言的子任务1.1 传统渗透测试的三个致命痛点先别急着写代码得把问题说清楚。我跑过不少渗透测试项目也带过新人做安全测试发现传统模式有几个绕不开的痛点。第一是结论不可复现。人工测试时“我发现管理后台密码可以被暴力猜解”这句话换一个人来测可能就是“我试了常见弱口令没成功”。操作路径、请求参数、当时环境都没完整记录结论就像一场实验结果没法重复。做工程的人都知道不能复现的结果等于没有结果但安全测试偏偏长期停留在这个阶段。第二是回归成本高。开发同学修完高危漏洞之后我们要把相关模块重新测一遍这不是改一行代码就能验证的事。很多漏洞能不能被利用取决于周围配置、依赖版本、网关策略人工回归通常只能抽查抽查就意味着漏掉边缘情况。安全测试如果能像单元测试一样被自动触发修复后的验证就是点一下“运行”而不是跟人协调一周时间。第三是边界和责任不清晰。多人分工测一套系统时A以为B负责了某台机器的口令策略B以为那是C的范围最后一个高危配置项没人测过。传统渗透测试靠聊天记录和周会协调边界很难真正闭环。安全负责人最怕听到的一句话就是“我以为你测过了”。这三个痛点看着是流程问题本质上都是工程化缺失。解决思路其实很朴素把测试过程拆成粒度合适、可独立运行、执行结果能明确判定通过还是不通过的小任务这正是 pytest 最擅长干的事。1.2 为什么是 pytest而不是一堆 shell 脚本把渗透测试写成 shell 脚本也能跑跑完也能输出文本结果但脚本只能告诉你“命令执行成功或失败”很多校验点需要你自己写逻辑而且脚本之间的状态共享非常痛苦。pytest 给了三样实打实的东西。一是断言机制。一个用例是否通过就看断言表达式是否成立。断言失败时 pytest 会直接打印出左右两个值让你立刻知道期望是什么、实际是什么定位问题比翻 shell 输出日志轻松太多。二是 fixture 管理。安全测试里几乎所有用例都依赖目标连接、授权标记、前置探测pytest 的 fixture 可以统一维护这些状态还能控制作用域和清理逻辑。这正好解决渗透测试最头疼的前置条件和后置清场。三是生态和报告。pytest 有 junitxml、html、allure 等报告插件也有-k、-m标记选择器。你可以只跑高优先级用例也可以按模块跑结果直接汇入 CI 平台。这些能力用 shell 脚本堆出来要费不少功夫而且越堆越乱。当然选型理由不只是功能对比。真正让我下定决心的是 pytest 的底层哲学测试用例是“可以被验证的文档”。渗透测试本质上应该是“可以被验证的论断”而不是“我觉得这里有风险”的个人感觉。这两个理念天然合拍。1.3 拆解原则一次检查对应一条断言能复现才算数拆得细不是目的拆得对才是关键。我给自己定的原则是三条一个子任务只验证一个稳定的安全属性子任务必须能在相同输入条件下复现不能复现的“发现”在工程上等于不存在。举个例子“检测目标服务器返回的 HTTP 响应头是否携带安全基线要求的字段”是一个合格子任务而“测一下这个网站的安全性”就不是它太模糊没法写断言。子任务的输入必须是明确的目标标识比如域名、IP、接口路径输出必须是断言函数能判断的结果。断言语义要贴近“安全属性”而不是贴近“攻击动作”。登录爆破这类动作我通常不会写进自动运行的用例里只做一个“检查口令策略是否存在”的断言用例验证密码最短长度、是否强制复杂度、是否开启锁定。真实爆破动作留给人工在授权沙盒里执行因为自动化爆破很容易触发锁定策略、制造日志风暴脏数据还会污染后续回归。这个边界划分清楚之后整套体系既安全又实用。每个用例跑完结论只有三种通过、失败、跳过。失败就是失败不再有“好像有问题”的中间状态。2. 核心设计可断言子任务的抽象模型2.1 一个子任务的五要素我把 arxiv 仓库里每个子任务抽象成五个要素要求显式声明缺一个都算不合格目标标识、前置条件、执行动作、预期状态、清场动作。目标标识是被测对象的唯一地址比如https://staging.example.com或某台内网主机的 IP。它必须来自配置文件或 fixture不能散落在测试代码里变成魔法字符串否则换环境时你会改到怀疑人生。前置条件是用例开始前必须具备的状态比如目标服务已启动、已获得授权标记、已拿到登录会话。前置条件不满足时用例应直接 skip而不是 fail。这里有个细节skip 表示环境没准备好fail 表示目标的安全属性不达标两者一定要分清否则统计报告里一堆红色失败负责人分不清是环境问题还是真实风险。执行动作是真正的检查请求比如发起 HTTP 请求、读取响应头、解析 TLS 证书、探测端口状态。动作必须有超时和重试策略最怕一个用例卡住整个测试队列跟着卡住。预期状态用断言表达例如“响应头不包含Server字段”“Strict-Transport-Security头存在”。清场动作放在 teardown 阶段删除临时账号、清理上传文件、恢复被修改的配置。很多安全用例会污染被测环境不清场的话下一次回归会拿上一次的脏数据当基线误报率直接飙升。2.2 断言规范从“有没有”到“严重级别”刚开始我把所有断言都写成assert result[status] pass跑起来一团糟因为 pass 这个词含义太宽泛。后来引入三级断言分级P0 阻塞级、P1 严重级、P2 提示级。P0 断言失败意味着目标的某个关键安全属性完全不符合基线比如“不应允许匿名登录”“不应存在默认口令配置”这类失败必须立刻阻断发布流程。P1 断言失败表示发现明确风险点需要人工复核例如“缺少 CSP 响应头”。P2 断言失败只是提示信息比如“TLS 版本低于业界建议但该环境当前可以接受”。在 pytest 里用标记实现分级pytest.mark.p0 def test_default_password_disabled(authed_target): ...运行时用-m参数选择级别pytest -m p0 pytest -m p0 or p1这里必须配合一个习惯断言失败消息要描述“期望状态”而不是单纯描述“发生了什么”。比如assert Strict-Transport-Security in headers, 目标必须配置 HSTS 响应头实际缺失失败时的报错信息能直接贴进缺陷单省去二次转述。这个细节看似很小但在跟开发同事沟通时价值巨大他们拿到报错信息一眼就知道要改什么。2.3 方法论到测试用例的映射表拆子任务不能拍脑袋我参考的是 PTES、OWASP WSTG、CIS Benchmarks 这套公开方法论把检查项逐个转成表格再映射成 pytest 用例。这里得说回项目代号 arxiv。它本意是“归档”我把从论文和标准库整理出来的检查项按照主题归档成 markdown 卡片每张卡片对应一个或一组参数化用例。卡片上写清楚检查项名称、对应标准编号、风险级别、预期状态、依赖数据源。这就等于给每个用例做了一个可追溯的“引用列表”以后别人审代码时能直接看到这条断言依据来自哪里。举个例子OWASP WSTG 里“HTTP 安全头测试”一章可以拆成多个参数化用例数组里写全需要检查的头名称pytest.mark.parametrize(header_name, [ Content-Security-Policy, X-Content-Type-Options, Strict-Transport-Security, X-Frame-Options, ]) def test_security_header_present(authed_target, header_name): ...参数 ID 就是头名跑挂了直接能看到是哪个头缺失。为什么缺失安全头要定成 P1 而不是 P0因为安全头属于纵深防御的一部分缺失不一定造成直接可利用漏洞但会显著放大其他风险的被利用概率。这个“为什么”写在映射表里比写在代码注释里更清晰因为代码注释会被删方法论映射表不会。3. 实操过程搭建 arxiv 安全测试用例仓库3.1 仓库结构与依赖准备先给一个可以直接复制的目录结构arxiv/ ├── conf/ │ ├── targets.yaml │ └── baselines/ │ └── http_headers.yaml ├── src/ │ └── arxiv/ │ ├── http_client.py │ └── service_probe.py ├── tests/ │ ├── conftest.py │ ├── test_http_headers.py │ ├── test_tls_config.py │ ├── test_auth_policy.py │ └── test_service_probe.py ├── reports/ ├── requirements.txt ├── pytest.ini └── README.mdrequirements.txt 保持精简pytest7.0 requests2.31 pytest-html4.0 PyYAML6.0pytest.ini 里注册标记和默认参数[pytest] markers p0: 阻塞级断言 p1: 严重级断言 p2: 提示级断言 addopts -ra --strict-markers --maxfail5--strict-markers这一项强烈建议加上。它会在用了未注册标记时报错而不是静默通过我早期因为标记名拼写错误导致用例分类失效排查了很久最后发现是少了一个字母从那以后就再也不敢去掉这个参数。3.2 编写授权与目标管理的 conftest安全测试最讲究边界所以 conftest 里我放了一个授权检查 fixture。目标地址必须落在预授权网段否则直接跳过避免误测不属于自己的资产。# tests/conftest.py import yaml import pytest with open(conf/targets.yaml, encodingutf-8) as f: TARGETS yaml.safe_load(f) pytest.fixture(scopesession) def target(): target_url TARGETS[target_url] target_ip TARGETS[target_ip] if target_ip not in TARGETS[allowed_cidrs]: pytest.skip(f目标 {target_ip} 不在授权范围内跳过全量测试) return {url: target_url, ip: target_ip}这套设计的价值在换环境时最能体现。测试人员拿同一套仓库跑到客户的测试环境只需要改targets.yaml里的 URL 和 IP授权网段配好之后跑出红色失败就意味着目标有问题而不是配置错了。有一次同事把内网targets.yaml提交到公共分支CI 里跑用例直接连上了不该连的地址幸好有授权网段检查用例提前 skip否则就是一次安全事故。这个 fixture 相当于给整套测试流程加了一道闸门。3.3 第一个可断言的子任务HTTP 安全头检查现在写第一个正经用例。目标验证预发环境的 HTTP 响应头是否满足安全基线。# tests/test_http_headers.py import yaml import pytest from src.arxiv.http_client import request_with_retry with open(conf/baselines/http_headers.yaml, encodingutf-8) as f: BASELINE yaml.safe_load(f) pytest.fixture() def response_headers(target): resp request_with_retry(GET, target[url] /healthz) return resp.headers pytest.mark.p1 pytest.mark.parametrize(header_name, BASELINE[required_headers]) def test_security_header_present(response_headers, header_name): assert header_name in response_headers, f{header_name} 缺失 pytest.mark.p2 def test_no_server_version_leak(response_headers): server response_headers.get(Server, ) assert nginx/1. not in server, f响应头不应泄露精确版本: {server}第一项断言检查的是 P1每个安全头缺失时缺陷单能直接引用。第二项检查版本泄露我故意定成 P2因为版本信息本身不会直接造成漏洞但它会给后续攻击者提供精确的版本情报。你不希望生产环境把Server: nginx/1.18.0大大方方暴露出来。注意 response_headers 这个 fixture 是函数级作用域每个用例都会重新请求一次。为什么不用 session 级复用响应头因为安全头检查类用例通常还会配合其他动作比如登录后页面、错误页面不同路径返回的头可能不一样所以每次请求独立更可靠。3.4 跑测试与生成报告完整跑一遍仓库时我推荐带两个参数pytest tests/ \ --htmlreports/latest.html --self-contained-html \ --junitxmlreports/junit.xml--html生成可视化报告适合发给非技术的负责人看--junitxml给 CI 平台解析结果方便做质量门禁。在 CI 里我一般配置两类触发。一是代码合并到安全测试分支时跑 P2 及以上用例做快速筛查主要防新功能引入明显配置退化二是临近发布时跑 P0 全量阻断校验所有阻塞级断言必须全绿才能发版。这样设计不会让每次小改动都经历完整的测试过程太重的任务反而没人愿意跑。还有个细节不建议在addopts里加--disable-warnings。测试过程中的 warning 往往是接口变更、依赖升级的前兆比如 requests 库某个方法被标记弃用提前看到可以早做准备上线之后再发现就被动了。4. 常见问题与排查技巧实录4.1 用例跑完目标服务崩溃并发与噪音控制第一次把整仓库用例接到预发环境后目标服务直接重启了一次。排查发现是参数化用例在内部用ThreadPoolExecutor并发跑得太猛瞬时打了几百个请求触发网关的限流保护服务被误判为异常自动重启。解决思路是给可能产生较大请求量的用例固定并发上限或者干脆串行。pytest 默认是串行执行的只有当你用了pytest-xdist或测试内部自己开线程时才需要担心。我的约定是攻击面检查和可用性检查串行纯读配置的检查可以小并发。还有一类问题来自噪音。很多“发现漏洞”动作比如频繁登录尝试、批量参数探测会给目标制造大量日志噪声甚至触发封禁规则运维同事会非常不满。我的原则是自动化用例只做“判定”不做“暴力尝试”。真正需要手工验证的攻击路径在报告中标记为manual_verify并给出精确复现步骤而不是让 pytest 去帮目标系统做压测。4.2 fixture 生命周期不当导致目标连接失效测试时遇到过诡异现象第一个用例能连上目标后面批量用例全部报ConnectionResetError。查了很久才发现我把目标连接做成 session 级 fixture 的 socket但 TLS 配置测试用例里会强制目标重置连接下一个用例复用的还是旧连接自然全部失败。修改方案是把“可能改变目标状态”的用例独立不使用共享连接对连接类 fixture 给每个用例创建新连接teardown 里明确关闭。还有一个更隐蔽的经验如果目标在负载均衡器后面有多个实例session 级连接可能会钉住一台实例测出的结果对全量实例没有代表性这种情况下反而应该用 function 级 fixture让每个用例都打一次负载均衡入口。4.3 断言过脆网络抖动让用例变“薛定谔的测试”我最早把所有请求超时都设成 2 秒结果经常出现“本地过了CI 挂了”的情况。CI 容器到目标机房的首轮握手延迟可能就有 1.5 秒2 秒超时卡在临界点测试结果完全取决于网络心情。后来统一了网络层策略连接超时 3 秒读取超时 5 秒整体重试 1 次重试间隔 500 毫秒。并且在断言层不对响应时间做硬编码判断除非那是一个专门的性能测试用例。如果确实要断言性能我会连续请求多次取中位数再跟基线比较而不是一次定生死。对响应头做断言时还有一个容易踩的坑目标如果经过 CDN 或网关部分代理会追加、改写头部字段比如Via、X-Forwarded-For。你断言的Server头可能是 CDN 的而不是源站的。这种情况建议单独解析源站响应头或者配置一个不经 CDN 的测试域名。被 CDN 挡在前面做安全测试就像是隔着手套摸温度不准。4.4 方法论更新与用例长期维护安全领域变化很快去年认为安全的配置今年可能就被证明有新的利用手法。我维护 arxiv 仓库时会定期检查方法论文档的版本PTES 是稳定指导框架变化快的是 OWASP WSTG 和各家 CIS benchmark。每次版本升级后我都会跑一次全量 P0/P1 用例把“新检查项没有用例”当作待办事项排进迭代。这里给一个非常实用的建议每个用例文件顶部写“引用版本”注释。比如# 参考: OWASP WSTG v4.2 - WSTG-CONF-12几年后回来看代码你很难记得当时为什么写这条断言。版本注释等于给自己留了线索也让后接手的人知道该去查哪份文档。安全测试的用例跟业务测试不一样业务需求会变但安全基线是外部标准驱动的标准一更新用例就必须跟着复查。没有版本记录你连该复核哪些用例都找不到。这套东西跑了快半年我最大的体会是把渗透测试拆成 pytest 可断言的子任务收获的最重要资产不是某个漏洞报告而是“可复现的结论”。同样的目标任何人在任何时间跑同一套用例得到的结果应该一致不一致就是测试体系的问题而不是被测系统的玄学。最后再分享一条建议如果团队刚开始做这件事别急着把所有安全测试都塞进自动化先挑“配置类、验证类”的检查项落地这类用例稳定、低风险、见效快比如安全响应头、TLS 配置、授权网段边界。攻击性和利用类的工作留给人工在授权范围里执行pytest 只负责把人工验证过的结论沉淀成可反复运行的安全基线。安全测试如果真的要做成工程就得允许别人在一个周一的早上只敲一条命令就知道系统现在还是安全的吗
阅读完成 · 觉得有帮助？
