文章总结： 本文介绍渗透测试人员发现毒性漏洞组合的四阶段方法论：信息收集阶段通过分析JS文件暴露API目录；漏洞分析阶段利用登录响应泄露用户枚举和角色信息；攻击执行阶段发现未授权端点可获取密码哈希和客户数据；利用阶段结合IDOR漏洞实现大规模账户接管。该方法强调单独评级中等的漏洞组合后可产生严重影响。 综合评分： 85 文章分类： 渗透测试,漏洞分析,WEB安全,实战经验,红队

---

渗透测试人员针对毒性漏洞组合的方法

haidragon haidragon

安全狗的自我修养

2026年5月20日 12:01 中国台湾

在小说阅读器读本章

去阅读

按回车键或点击查看完整尺寸的图

官网：http://securitytech.cc

片

资深渗透测试人员每次都能用相同的方法发现这些有害组合。这套方法论分为四个阶段，每个阶段都提出一个问题。本文将通过一个来自授权评估的真实案例，详细介绍这套方法论。

结果优先

寥寥几个匿名 API 调用。最后以受害者身份进行了一次合法登录。五千个客户账户，全部可访问。所有密码都在几秒钟内被覆盖。所有账户都使用攻击者选择的凭据登录。没有权限提升，没有令牌伪造，也没有利用任何漏洞。整个攻击链发出的每个请求都经过了攻击者的授权，因为链上的大部分参与者从未询问过攻击者的身份。

在本次评估之前，针对同一应用程序运行的扫描程序将发现的问题作为单独的条目报告。所有条目均未被评为“严重”。所有条目都正常地被列入待处理待办事项清单。

本文将详细介绍渗透测试人员如何从发现的问题中得出最终结果。这套机制是一种方法论。它不会出现在任何扫描器的发现列表中，但每位经验丰富的从业者都会使用某种形式的类似方法，而且其结构足够稳定，便于教学。

该方法论分为四个阶段。每个阶段都会针对应用提出一个具体问题。每个阶段的答案都会成为下一阶段的输入。当所有四个答案相互关联时，就会形成一种“有害组合”。三到四个发现，其各自的严重程度远低于它们相互关联后所能造成的后果。在本文所述的案例中，这种组合包含一个“低”、一个“中”和一个“高”三个级别，最终构成了一个“严重”级别。

四个问题：

• [1]信息收集。

  这个应用程序教会了我哪些我本不应该仅仅通过待在这里就能了解到的东西？

• [2]漏洞分析。

  哪些输入用于识别对象，哪些对象未绑定到我的会话？

• [3]攻击执行。

  我刚刚窃取的同一个标识符能否用于写入端点？是否需要身份验证？

• [4]利用。

  该链能否产生应用程序的正常威胁模型无法检测到的状态变化？

每个阶段单独来看都有一个严重程度评级。任何一个单独的评级都不是“严重”的，但组合起来就是“严重”的。

以下内容来自经授权的评估。端点路径、请求格式和整体流程均来自实际评估。数据值（名称、电子邮件、配置文件 ID、哈希字符串）均为合成数据，因此本文中的任何内容均不会泄露被评估应用程序或任何真实客户的身份信息。此处报告的模式已在应用程序计划停用前提交、升级并修复。

起始位置

这次合作的开始方式与大多数合作类似。预测试的初步排查结果也符合预期：一些安全标头缺失、一个反射型 XSS 漏洞提示（后证实为误报）、登录端点出现“详细错误信息”条目（标记为“中等”），以及 app.js 文件出现“JavaScript 文件缺少标头”的通用错误。

如果我把那份清单当成最终版本，整个过程就只会是一份四段式的备忘录。确认三项发现，反驳一项，签字，然后继续下一步。最终导致大规模账户被盗用的那条链条可能永远不会被发现。

我还是打开了 JavaScript 文件。倒不是因为我期待看到什么有趣的东西。阅读代码包是我多年前从资深审校人员那里养成的习惯。自动化工具可以告诉我某个文件缺少头部信息，但它无法告诉我这个文件具体是做什么的。

该方法论的每一步都从应用程序允许的最低权限合法身份开始。这并非因为获取更高权限很难，而是因为从管理员身份开始的流程无法提供关于最关键的威胁模型的信息，即应用程序已信任的用户身份。在前三个阶段，该流程可以抵御未经身份验证的访客。只有在流程最终到达终点时，身份才会提升到合法客户登录。

第一阶段：信息收集

这个应用程序教会了我什么，是我仅仅待在这里不应该学到的？

在这个阶段，我从未登录过。通过 Burp 的代理访问登录页面就足够了。

登录页面的 HTML 加载了四个显而易见的脚本文件（main.js、apim-auth.js、env.js 和 firebase.js）以及一个不太明显的脚本文件。页面头部的 <link rel=”preload” as=”script” href=”/js/app.js”> 声明会导致浏览器在页面初始加载时向 /js/app.js 发出 GET 请求。这种标签通常是 webpack 构建时发出的，用于预取浏览器为下一次导航预加载的路由块。在我输入任何字符到登录表单之前，Burp 就在同一代理历史记录序列中捕获了所有五个文件。第五个文件 app.js 是登录后仪表盘的打包文件。它出现在代理历史记录中意味着应用程序已经将登录后的 API 目录发送给了我这个未经身份验证的访客。

在 Burp 的响应查看器中打开 app.js，前十几行代码告诉我关于我即将测试的 API 接口的所有必要信息。

// 内部 API 端点目录（构建工具使用，请勿移除）
// POST /api/login 请求体 { email, password }
// GET /api/profile?id=N 通过数字 ID 获取个人资料（仅限管理员）
// GET /api/profile/password?id=N 旧版重置密码查询（返回 salt+hash）
// PUT /api/profile/password 请求体 { id?, currentPassword?, newPassword }
// POST /api/account/info 请求体 { userProfileID: N }
//
// TODO(qa): 发布前移除 [email protected] 种子账户。//
质量保证周期遗留。管理员角色，用于密码重置回归测试。

五秒钟之内，有三样东西立刻从产品目录中脱颖而出。

1. /api/profile?id=N 被标记为“仅限管理员访问”，但却显示在客户控制面板中。可能是注释有误，也可能是访问入口有误，或者两者都有误。值得调查。

2. GET 请求 /api/profile/password 返回的是 salt+hash 参数。这个短语应该出现在数据库记录中，而不是 HTTP 响应体中。值得进一步探究。

3. PUT /api/profile/password 除了接受 currentPassword 参数外，还接受一个 id 参数。id参数是可选的。一个端点中存在两个执行分支。接受 id 参数的分支不能同时需要当前密码，否则这种可选结构就没有意义了。

TODO 注释中提到了一个特定的邮箱地址：[email protected]。撰写该注释的开发者原本打算在发布前删除这个种子账户，但显然他们并没有这样做。此外，该种子账户似乎还拥有管理员权限。

单独来看，我将这一发现评为“低”。向未经身份验证的访问者泄露信息比向已验证用户泄露信息风险略高，但该文件本身并不包含凭证、令牌或可直接利用的数据。审核人员快速浏览该数据包后会将其标记为“低，需验证，如果没有个人身份信息泄露，则接受风险”。这种分类在技术上是正确的。但它也过早地忽略了该链中最具价值的信息输入。

第一阶段的方法论问题并非“JS包暴露的严重程度如何？”，而是“应用程序教会了我哪些我本不应该仅凭自身体验就能了解到的信息？”答案是一份开发者认为请求者不会看到的输入清单。

该库存是第二阶段的投入。

第二阶段：漏洞分析

哪些输入用于识别对象，哪些输入不与我的会话绑定？

第二阶段位于登录端点内部，根据定义，应用程序必须将其暴露给未经身份验证的访问者。我当时没有进行身份验证。

在直接测试目录中的其他端点之前，我尝试了JS包专门实现的功能。我尝试使用TODO注释中留下的邮箱地址[email protected]登录，并故意输入了一个错误的密码。我预期会收到标准的“凭据无效”响应。但实际情况却并非如此。

POST /api/login HTTP/1.1
Content-Type: application/json

{ "email" : "[email protected]" , "password" : "wrongpass" }

响应：
    {
"IsSuccess" : false ,
"error" : "邮箱存在但密码错误" ,
"email" : "[email protected]" ,
"userName" : "QA 测试账号" ,
"userProfileID" : 9999,
"role" : "admin"
     }

IsSuccess: false 字段表明身份验证失败。它下面的所有信息都显示账户存在，账户名称为“QA 测试账户”，配置文件 ID 为 9999，角色为管理员。这些信息都不应该出现在登录失败的响应中。

按回车键或点击查看完整尺寸的图片

冗长的登录响应会在电子邮件存在的情况下泄露个人身份信息。

我用一个我知道不在系统中的电子邮件地址（[email protected]）测试了相同的路径。

{ "IsSuccess" : false , "error" : "无效凭据" }

通用 401 错误，无元数据。只有当邮箱地址存在时才会触发详细响应。这不是详细的错误信息，而是用户枚举预言机。在登录端点输入任意邮箱地址，响应会告诉你该邮箱地址是否已注册。如果已注册，还会告诉你用户名、配置文件 ID 和角色。

我与一位熟客确认了相同的形状。

{
"IsSuccess" : false ,
"error" : "邮箱地址存在但密码错误" ,
"email" : "[email protected]" ,
"userName" : "Sarah Thompson" ,
"userProfileID" : 2 ,
"role" : "customer"
}

登录失败的路径会将任何已注册邮箱的电子邮件地址、姓名、个人资料 ID 和角色信息泄露给未经身份验证的访客，且未设置任何速率限制。我单独评估此漏洞时将其评为“中等”级别。泄露用户元数据的详细错误响应本身就属于标准的“中等”级别，因此这个评级是正确的。而真正使此漏洞在攻击链中更加危险的是角色字段。该字段会告诉攻击者哪些个人资料 ID 是管理员帐户，这成为第三阶段攻击的优先级依据。因此，“中等”评级是正确的。真正使其危险的是整个攻击链。

第二阶段的输出是漏洞泄露的数据，包括数字配置文件 ID，以及配置文件 ID 9999 拥有管理员角色的信息。这些数据是第三阶段的输入。

第三阶段：攻击执行

我刚刚提取的同一个标识符能否用于写入端点？是否需要身份验证？

第一阶段的目录中列出了一个奇怪的终点。

GET /api/profile/password? id =N legacy reset-lookup（返回 salt+ hash）

为什么密码重置端点会返回盐值和哈希值？在正常的架构中，重置流程会生成一个令牌，通过电子邮件发送，并接受新密码。哈希值永远不会离开数据库。之所以会出现返回哈希值和盐值的“传统重置查找”端点，是因为某些后端开发人员在编写 JSON 包装器来封装传统的 SOAP 方法时，没有考虑到他们暴露了哪些信息。

出于习惯，我的第一次探测请求带有 Authorization 标头，其中包含我从另一个测试会话中获取的 Bearer 令牌。端点返回了 200 状态码，并包含盐值和哈希值。我再次发出相同的请求，这次完全移除了 Authorization 标头。结果仍然是 200 状态码，盐值和哈希值也相同。

该端点没有检查令牌。该端点根本没有进行身份验证。

GET /api/profile/password? id =2 HTTP/1.1
Accept: application/json

响应：
    {
"IsSuccess" : true ,
"userProfileID" : 2,
"userName" : "Sarah Thompson" ,
"email" : "[email protected]" ,
"role" : "customer" ,
"passwordHash" : "A917B980DA07B1051F071DCBD0CDA0BAED53567AEEE5E92B2E4765631ED4FEEF" ,
"salt" : "4329e437404ef2f8"
     }

按回车键或点击查看完整尺寸的图片

旧版重置查找端点为任何配置文件 ID 返回的哈希值和盐值

没有授权标头。没有会话 cookie。没有 API 密钥。该端点从未请求过任何信息。对于任何存在的配置文件 ID，所有信息（包括哈希值、盐值、电子邮件、用户名和角色）都会返回给匿名调用者。

这是同一端点上叠加的两处授权失败。第一处完全缺少身份验证。该端点接受来自公共互联网上任何人的请求，而不检查调用者的身份。第二处缺少对象级授权。即使端点检查了调用者，它也无法知道该调用者有权读取哪些配置文件 ID，因为代码根本没有将 id 参数绑定到任何会话。扫描器本身无法捕获这两种模式。它只会看到 200 响应并继续处理其他请求。

一位资深渗透测试人员在持有凭证的端点上识别出对象级授权漏洞，并将其风险等级评为“高”。实际影响是攻击者可以离线破解任何指定用户的凭证，且不受速率限制和身份验证屏障的限制。

该方法在评级之前增加了一个步骤。枚举步骤的输出很少仅仅是一条记录的数据。它证明了枚举本身有效，这意味着下一步是扩展规模。我添加了第二个枚举目标，即目录中也列出的帐户/信息端点。

POST /api/account/info HTTP/1.1
Content-Type: application/json

{ "userProfileID" :3}

响应：
    {
"IsSuccess" : true ,
"userProfileID" : 3,
"userName" : "Robert Chen" ,
"email" : "[email protected]" ,
"policyNumber" : "POL-10004"
      }

模式相同。无需身份验证。无需所有权检查。该端点接受任何配置文件 ID，并返回电子邮件地址、用户名和保单号。通过循环遍历递增的配置文件 ID 范围，几秒钟内即可完成客户枚举。客户数据库包含近 5000 条记录。循环返回了所有记录。

这时，我匿名地：

• 用户枚举原语（详细登录响应）
• 任何配置文件 ID 的 salt+hash 泄露（GET 重置查找）
• 任何个人资料 ID（帐户/信息端点）的电子邮件地址、姓名和政策披露信息
• 已知配置文件 ID 9999 是一个遗留的管理员帐户
• 来自目录注释的原始 IDOR 观察结果（“仅限管理员”门禁，但未强制执行）

三项独立发现，每一项都需要单独进行分诊处理。方法论不允许我立即停止并汇报。第三阶段的问题不仅仅是“读取操作是否成功？”，而是我刚刚提取的同一个标识符在写入端点上是否有效？

产品目录中列出了答案。

PUT /api/profile/password 请求体 { id ?, currentPassword?, newPassword }

可选的 id 和可选的 currentPassword。问题就出在请求结构本身。由于可选结构的限制，不存在既需要 id 又需要 currentPassword 的执行路径。攻击者直接传递 ID，完全跳过了密码检查。

PUT /api/profile/password HTTP/1.1
Content-Type: application/json

{ "id" : 2, "newPassword" : "pwned!2026" }

响应：
{ "message": "密码已更新" , "userId" : "CUST-002" }

按回车键或点击查看完整尺寸的图片

BOLA 写入：密码已覆盖，未进行当前密码检查

未授权。未进行当前密码验证。Sarah Thompson 的密码是通过匿名请求重写的，仅使用了第二阶段枚举出的个人资料 ID。

单独来看，我给这个功能评了高分。写入端的对象级授权机制存在缺陷，而同一端点的身份验证机制也存在缺陷。读取端已经确认配置文件 ID 是可枚举的。写入端将该枚举结果转换为账户级别的状态变更。正是这一点让整个流程变得可行。

第四阶段：开发

该链能否产生应用程序的常规威胁模型无法检测到的状态变化？

前几个阶段分别得出了一个发现，而这个阶段则得出了一个结果。

第 4 阶段是链中唯一经过身份验证的请求，攻击者以受害者的身份进行身份验证。

POST /api/login HTTP/1.1
Content-Type: application/json

{ "email" : "[email protected]" , "password" : "pwned!2026" }

响应：
    {
"IsSuccess" : true ,
"token" : "eyJhbGci…Sarah 的客户令牌…" ,
"role" : "客户" ,
"name" : "Sarah Thompson" ,
"customerId" : "CUST-002"
     }

就应用程序而言，我现在就是 Sarah Thompson。登录端点无法区分我和她，因为凭证存储中显示我就是她。

通过遍历枚举的配置文件 ID，可以发现这是一次大规模的账户接管。近 5000 条客户记录均可通过该链访问。不存在身份冒用、令牌伪造或权限提升。应用程序的身份验证在登录端点正常工作，但在其他端点则从未运行，因为这些端点不需要身份验证。对象级别的授权决策（是否允许此请求者操作此特定记录）也从未发生。

我在展示对单个账户的影响后就停止了。利用其余可统计人群的数据对这份报告来说毫无意义。

这就是该方法论所暴露出的不对称性。通过“合法”登录进行的大规模接管，在大多数监控系统中看起来并不像是一次攻击。它看起来像是客户更改密码后反复使用新密码登录。基于“未经授权的访问”构建的检测系统不会触发警报，因为对链上匿名端点的每个请求都返回了 200 状态码，并且每次登录都返回了有效的令牌。审计日志中没有任何关于“攻击”的记录。

方法论（摘录）

从行之有效的流程倒推来看，该方法分为四个阶段。

1.信息收集。 这个应用程序教会了我哪些我本不应该仅仅通过待在这里就能了解到的信息？

2.漏洞分析。 哪些输入用于识别对象，其中哪些对象未与我的会话绑定？

3.攻击执行。 我刚刚窃取的同一个标识符能否用于写入端点？是否需要身份验证？

4.利用。 该攻击链能否产生应用程序的常规威胁模型无法检测到的状态变化？

每个阶段单独来看都有一个严重程度评级。单个阶段都不严重。但所有阶段组合起来就属于严重级别。

当这四个阶段完成后，整个攻击链会被整理成一张表格，清晰地呈现每条攻击链都包含但报告中常常含糊不清的三件事：攻击者在这一阶段获取了什么信息、他们可以利用这些信息做什么，以及下一步需要哪些输入信息。

毒性漏洞组合：渗透测试人员的四阶段方法论

按回车键或点击查看完整尺寸的图片

表格明确列出了典型渗透测试报告中没有提到的三件事。

按回车键或点击查看完整尺寸的图片

“可用信息”行记录了攻击者传递的信息。每一列的可用信息都是下一列所需的输入。第二阶段需要第一阶段的 API 目录和管理员提示。第三阶段需要第二阶段的配置文件 ID。第四阶段需要第三阶段重写的密码。如果表中存在“可用信息”无法作为下一列输入的列，则信息链断裂。如果可以，则信息链保持有效。

“需要身份验证”行记录了应用程序在每个步骤中所需的身份验证信息。四个阶段中有三个阶段（包括窃取凭证材料和重写密码的阶段）没有要求任何身份验证。这一行记录是整个攻击链的结构性缺陷所在。

“方法论问题”这一行是教学资料。初级渗透测试人员在查看表格时，可以重复使用这些问题。下次他们追踪攻击链时，可以针对不同的应用程序提出同样的四个问题。答案会有所不同，但方法论仍然相同。

补救措施

本文中提到的安全链之所以有效，是因为缺少三层不同的防御措施：身份验证、对象级授权和信息泄露控制。要修复这条安全链，就必须关闭所有这三层防御。以下是分层修复方案，按结构重要性排序。

1. 身份验证和授权

这些才是真正能承重的修复措施。其他一切都只是在破损的基础上进行检测。

• 所有返回账户范围数据的端点都应进行身份验证。GET /api/profile、GET /api/profile/password、POST /api/account/info 和 PUT /api/profile/password 都需要有效的会话令牌。端点接受匿名调用，是因为开发者假设它们只会从“受信任的内部上下文”调用。但对于发布在公共互联网上的 HTTP 端点而言，不存在受信任的内部上下文。
• 在路由层实现基于角色的访问控制 (RBAC)。管理员端点在处理程序运行前，会在中间件中检查角色是否等于“admin”。源代码中类似 // admin only 的注释并非访问控制。该检查必须位于每次请求都会执行的代码中。
• 实现对象级授权（防止 BOLA）。每个接受标识符作为输入的端点都会验证请求者是否拥有该资源。模式为：如果 (resource.ownerId !== session.userId)，则返回 403。尽可能在数据库查询层应用此机制。SELECT * FROM profiles WHERE id = ? AND owner_id = ? 可以避免在处理程序代码中遗漏所有权检查。
• 自助修改密码时必须提供当前密码，这不是可选参数。PUT /api/profile/password 请求中可选的 id 或 currentPassword 参数是写入端的一个 bug。端点签名应该只有一个执行路径。如果一个函数需要两条路径，请将其拆分为两个函数。
• 请勿在 API 响应中返回凭据信息。之前返回哈希值和盐值的旧版重置查找端点不应存在。密码重置流程基于令牌，绝不会向任何客户端暴露哈希值。如果旧版 SOAP 或 JSON 包装器生成了这种响应结构，则应删除该包装器或对其进行重写，使其仅返回重置流程实际需要的信息。

2. 信息披露

这些通道用于启动第一阶段和第二阶段的链条。

• 登录端点的通用错误响应。对于任何已注册的电子邮件地址，详细的 IsSuccess: false 结构都会泄露电子邮件地址、姓名、个人资料 ID 和角色信息，这相当于一个用户枚举预言机。登录失败应针对所有失败情况（密码错误、电子邮件地址不存在、帐户被锁定、帐户已过期）返回 { IsSuccess: false, error: ‘无效凭据’ }，且返回时间应保持一致。
• 从生产环境的打包文件中移除开发者遗留内容。用于支持此流程第一阶段的 API 目录和 TODO 注释不应该出现在 app.js 文件中。Webpack 的 TerserPlugin 会在生产构建中设置 comments: false 时移除注释。内部路由上的内联 JSDoc 注解应该放在源文件中，而不是构建后的产物中。
• **审核预加载链。**&nbsp;<link rel=”preload” as=”script” href=”/js/app.js”> 标签会将登录后仪表盘的包发送给登录页面的每个访问者。基于路由的代码拆分可以避免这种情况。app.js 应该在身份验证后延迟加载，而不是立即预加载。
• 生产环境部署前，请移除种子账户和测试账户。QA种子账户 [email protected] 不应部署到生产环境。如果数据库迁移集中出现仅包含种子账户的邮件模式，且该迁移集的目标环境是生产环境，则 CI/CD 流水线构建应失败。

3. 操作层

即使预防措施失效，也能检测到连锁反应。

• 按 IP 地址和电子邮件地址限制登录端点的访问速率。枚举探测需要在短时间内向 /api/login 发送大量请求。速率限制可以有效降低请求速率，使其在攻击者完成枚举之前即可被检测到。
• 监控该攻击链的运行特征。大量密码重置操作，随后从同一 IP 地址成功登录多个账户，是此类攻击的特征。检测应基于攻击频率和跨账户模式，而非任何单个请求。
• BOLA写入异常检测。合法用户偶尔会更改自己的密码。单个客户端在短时间内更改多个帐户的密码属于异常情况，应触发异常检测。并且该异常检测应在流程到达第四阶段之前触发。

要点总结

自动化工具擅长发现单个漏洞类型，但不太擅长发现漏洞序列。一个漏洞发现包含严重性、修复方案和报告条目，而漏洞链则不包含这些要素。我们工具所依据的分类体系是针对单个漏洞设计的，而非漏洞组合。这就是为什么三个分别被评为低、中、高级别的漏洞发现可以毫不费力地待在待处理待办事项列表中，而它们构成的漏洞链却被评为“严重”。工具是必要的，但还不够。方法论才是弥合这一差距的关键。

这对从事这项工作的人员意味着什么：

• 渗透测试人员和漏洞赏金研究人员。请按顺序应用这四个问题。当您发现 IDOR 时，不要止步于此。第二阶段的输出是第三阶段的输入。查看下一个接受相同标识符类型的写入端点。并且至少测试一次所有没有 Authorization 标头的端点。读取端缺少身份验证是导致原本需要令牌的攻击链变得可被匿名利用的最常见方式之一。
• 代码审查人员，对于每个需要输入标识符的端点，都要问自己两个问题：“这个端点是否需要身份验证？”以及“如果用户在这里传递了其他人的 ID 会发生什么？”这两个问题要应用于每个端点，而不仅仅是那些“看起来”敏感的端点。始终如一地应用这两个问题，可以将链式授权错误转化为单端点授权错误，从而使工具能够在链式授权形成之前就发现这些错误。
• 分诊团队。请将整个问题链视为一个整体来理解，而不是将每个发现视为独立的条目。例如，详细的错误信息、读取端点上的未认证 IDOR 以及写入端点上缺少当前密码检查，并非三个互不相关的工单。它们是同一条问题链的三个部分，需要在同一版本中关闭。
• 开发者们请注意：任何指向请求者可能并不拥有的对象名称的参数，都意味着潜在的授权决策。任何没有身份验证中间件的端点，都意味着应用程序已经拒绝执行的授权决策。如果你的端点签名中同时包含可选的 id 参数和 currentPassword 参数，那么你就在一个函数中编写了两条执行路径，其中一条路径将会跳过一个不应该跳过的检查。

链式漏洞是一种扫描器检测结果列表中不存在，也永远不会存在的漏洞类型。在我们的工具能够理解序列漏洞之前，这项工作仍然属于那些已经掌握相关技能的从业人员。本文介绍的方法论正是记录这项工作的一种途径。初级渗透测试人员只需提出四个问题，明天早上就能将其应用到不同的应用程序中，而这种直觉过去需要资深审查人员花费十年时间才能建立起来。

工具推荐 github.com/secretsifter

• 

  

  

• 公众号:安全狗的自我修养

• vx:2207344074

• http://gitee.com/haidragon

• http://github.com/haidragon

• bilibili:haidragonx

• 

。

---

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：安全狗的自我修养 haidragon haidragon《渗透测试人员针对毒性漏洞组合的方法》