1. 项目概述与核心思路最近在和一些刚入行的朋友交流时他们总问我企业SRC安全应急响应中心的漏洞挖掘是不是特别难是不是需要掌握很多“黑科技”才能有所收获。我的回答是恰恰相反很多时候最有效的攻击路径往往是最朴素的。今天我就以一个近期在某企业SRC成功提交并获得“赏金”的真实案例为蓝本完整复盘一次从信息收集到漏洞利用的全过程。这不仅仅是一次技术复盘更是一次关于“攻击者思维”和“工程化流程”的实战演练。无论你是刚接触安全测试的新手还是有一定经验但苦于找不到突破口的从业者我相信这篇实录都能给你带来一些启发。我们的目标不是炫耀技术而是拆解一个可复现、可学习的标准作业流程。这个案例的目标是一家提供SaaS服务的互联网公司其SRC在业内以响应迅速、奖金丰厚而闻名。我不会透露任何关于该企业的具体名称、域名等敏感信息所有涉及的目标资产都将以“target.com”或“app.target.com”这样的泛化域名代替。我们关注的是方法论和通用技术点而非针对特定目标的攻击。整个挖掘过程历时大约两周最终通过一个逻辑漏洞组合一个信息泄露漏洞成功获取了核心业务数据获得了可观的赏金。下面我们就从最基础也是最重要的一步开始。2. 前期信息收集与攻击面测绘漏洞挖掘七分靠信息收集三分靠漏洞利用。漫无目的地测试就像大海捞针高效的信息收集能帮你快速定位到最脆弱的“靶子”。2.1 资产发现与子域名枚举我的习惯是拿到一个主域名比如 target.com后第一件事就是尽可能多地找出其所有的子域名、关联域名和IP资产。这里我使用了多种工具进行交叉验证以确保覆盖率。被动收集利用像Amass,Subfinder,Assetfinder这样的工具从大量的公共数据源如证书透明度日志、DNS数据集、搜索引擎等中收集子域名。我通常会并行运行它们然后将结果去重合并。# 示例命令实际中会根据目标调整参数和API密钥 subfinder -d target.com -silent | tee subfinder.txt amass enum -passive -d target.com -o amass_passive.txt assetfinder --subs-only target.com | tee assetfinder.txt sort -u *.txt all_subs.txt注意被动收集不会直接向目标发送请求隐蔽性高是首选的第一步。字典爆破被动收集总有遗漏特别是那些没有公开记录的内部、测试环境域名。我会准备一个高质量的子域名字典使用gobuster或altdns进行爆破。gobuster dns -d target.com -w /path/to/subdomains.txt -t 50 -o gobuster.txt字典的质量至关重要。我常用的字典融合了SecLists中的通用字典以及根据目标行业特性比如电商常用cart,pay,api社交常用chat,live,msg自定义添加的词汇。端口扫描与服务识别对于发现的重要子域名和IP段需要进行端口扫描。我使用masscan进行全端口快速扫描再用nmap对开放端口进行精细化的服务和版本识别。# 快速发现开放端口 masscan -p1-65535 IP_RANGE --rate1000 -oG masscan.out # 对发现的端口进行详细探测 nmap -sV -sC -p 开放端口列表 IP -oA nmap_scan这一步的目的是绘制出完整的网络拓扑图哪些IP开了Web服务80, 443, 8080等哪些是数据库3306, 6379哪些是缓存服务6379, 11211哪些是管理后台8080, 8443。2.2 指纹识别与技术栈分析知道了“门”在哪里下一步就是搞清楚每扇“门”是什么材质、什么牌子的。这决定了我们用什么“钥匙”去尝试。Web应用指纹使用Wappalyzer浏览器插件进行快速识别同时配合命令行工具如WhatWeb或webanalyze进行批量扫描。whatweb https://app.target.com --colornever重点关注前端框架React, Vue, Angular、后端语言Java Spring, Python Django, PHP Laravel、Web服务器Nginx, Apache、中间件Tomcat, JBoss以及一些特定的组件Shiro, Fastjson, ThinkPHP。API接口探测现代应用大量依赖API。我会使用gobuster或dirsearch对常见API路径进行目录爆破如/api/v1/,/graphql,/swagger/,/api-docs/。发现Swagger或GraphQL接口往往意味着发现了宝藏入口。历史漏洞关联根据识别出的技术栈和版本号立刻在漏洞库如CNVD, CNNVD, NVD或搜索引擎中搜索相关版本的公开漏洞。例如识别到目标使用Spring Boot 2.6.0就要立刻想到是否存在相关的CVE。2.3 敏感信息泄露挖掘在GitHub、GitLab、网盘、甚至是搜索引擎中搜索与目标公司相关的代码、配置文件、员工邮箱、API密钥、数据库连接字符串等往往有意外收获。我常用的方法是GitHub搜索site:github.com “target.com” password,site:github.com “target.com” api_key,site:github.com “target.com” config。搜索引擎语法site:target.com filetype:pdf,site:target.com intitle:“index of”。证书透明度日志使用crt.sh网站查询目标域名签发的所有SSL证书有时能发现未在DNS中记录的内部域名。在这个案例中通过子域名爆破我发现了一个dev-jenkins.target.com的域名但访问返回403。这本身就是一个强烈的信号。3. 漏洞挖掘实战从入口到突破信息收集阶段我们发现了数十个子域名和上百个开放服务。经过初步筛选我重点关注了几个点一个用户中心account.target.com一个核心业务APIapi.target.com以及那个神秘的Jenkins地址dev-jenkins.target.com。漏洞往往出现在新旧系统交界处、功能复杂的业务点以及被遗忘的管理后台。3.1 身份认证与会话管理测试用户中心account.target.com是典型的认证入口。我首先进行了一系列常规测试弱口令爆破针对常见的员工邮箱前缀从领英或GitHub提交记录中收集进行爆破但目标有良好的账户锁定策略尝试几次后即被锁定。验证码绕过发现登录和注册处的图形验证码可被OCR识别或直接重放使用。通过编写简单的Python脚本利用pytesseract库识别验证码实现了自动化爆破测试但并未发现有效账户。密码重置漏洞这是重点。测试密码重置功能时我发现了第一个关键点。重置密码的流程是输入邮箱 - 发送6位数字验证码到邮箱 - 输入验证码和新密码。我抓包分析请求发现验证码校验的API接口为POST /api/v1/verify-reset-code其请求体为{“email”:”usertarget.com”, “code”:”123456”}。我尝试将邮箱参数改为另一个我已控制的测试邮箱attackermail.com而code参数仍使用发送给usertarget.com的验证码。请求竟然返回了成功这是一个典型的“验证码绑定到会话而非用户”的逻辑漏洞。我可以在不知道受害者验证码的情况下为我自己的账户设置任意密码通过后续的set-password接口但这还不够直接。进一步测试我发现verify-reset-code接口在校验成功后会在响应中返回一个reset_token用于后续的POST /api/v1/set-password。关键在于这个reset_token似乎只与邮箱和验证码的校验状态绑定而不是与一个特定的“重置会话”绑定。我能否重复使用这个token或者用它来重置其他用户的密码3.2 不安全的直接对象引用与权限绕过带着上面的疑问我转向了核心业务APIapi.target.com。在对其API文档幸运地在api-docs.target.com找到进行阅读时我注意到一个用户信息查询接口GET /api/v1/users/{userId}/profile。这里的userId是数字递增ID。一个经典的IDOR测试我注册了两个测试账号A和B。登录账号A后我的 userId 是10001。我调用 GET /api/v1/users/10001/profile成功返回我的信息。然后我将 userId 改为10000推测是更早的注册用户再次请求。**服务器返回了用户10000的详细资料包括邮箱、手机号后四位、注册时间等。** 这是一个不安全的直接对象引用漏洞。服务器没有校验当前请求者是否有权查看目标用户的信息。 但这还不是高危漏洞因为获取的是其他普通用户的信息。我继续尝试更大的ID范围并观察响应。当尝试一个非常小的ID如 userId5 时返回的数据结构发生了变化包含了 isAdmin: true 字段以及更多的系统内部字段。**我竟然能读取到系统管理员的资料** 虽然无法修改因为是GET请求但管理员邮箱、内部备注等信息已经泄露。这为后续的社工或精准攻击提供了可能。3.3 逻辑漏洞组合利用实现账户接管现在我有两个独立的发现密码重置流程的验证码校验逻辑缺陷account.target.com。用户信息查询的IDOR漏洞可泄露高权限用户ID和邮箱api.target.com。一个大胆的想法出现了能否将两者组合用IDOR漏洞获取一个高权限用户比如userId5的管理员的邮箱然后利用密码重置逻辑漏洞将这个管理员的密码重置绑定到我自己控制的账户上实操步骤如下信息获取通过IDOR漏洞请求GET /api/v1/users/5/profile确认管理员邮箱为admintarget.com。触发重置在account.target.com的密码重置页面输入admintarget.com点击发送验证码。此时验证码会发送到真实的admintarget.com邮箱我无法看到。漏洞利用同时我用自己的测试邮箱attackermail.com也触发一次密码重置获得一个发送到我邮箱的验证码假设为654321。关键请求我拦截attackermail.com的验证码校验请求将请求体修改为{ “email”: “admintarget.com”, “code”: “654321” // 这是我收到的属于attacker邮箱的验证码 }向POST /api/v1/verify-reset-code发送这个请求。根据之前的测试由于验证码校验逻辑缺陷这个请求很可能成功因为系统只检查code是否有效并未严格绑定code与email的对应关系或者绑定在了服务端会话中而会话未与邮箱强关联。获取Token如上一步推测成功响应会返回一个reset_token。这个token在系统逻辑里现在关联的“待重置账户”是admintarget.com因为请求中的email字段是它。完成接管使用这个reset_token调用POST /api/v1/set-password接口设置新的密码。请求体为{ “token”: “上一步获取的reset_token”, “new_password”: “Hacked123456” }服务器根据token找到其关联的邮箱admintarget.com更新了该邮箱账户的密码。结果验证我尝试使用admintarget.com和新密码Hacked123456在用户中心登录。登录成功我进入了管理员后台。至此通过一个逻辑漏洞验证码绑定缺陷和一个信息泄露漏洞IDOR的组合成功实现了对高权限账户的完全接管。这个漏洞的危害等级是“严重”。实操心得在测试逻辑漏洞时特别是状态流转相关的如订单、支付、认证一定要画流程图。理清客户端、服务端各自维护了哪些状态会话、token、临时code这些状态之间如何绑定和校验。漏洞往往出现在状态绑定错误或校验缺失的环节。4. 漏洞报告撰写与提交技巧挖到漏洞只是成功了一半清晰、专业地报告漏洞才能确保它被快速确认和修复从而顺利拿到赏金。4.1 报告内容结构一份优秀的漏洞报告应包括以下几个部分漏洞标题简明扼要如“密码重置逻辑缺陷导致任意账户接管”。风险等级根据CVSS标准或SRC自定标准评估如高危、中危。影响范围所有使用该密码重置功能的用户账户。漏洞细节漏洞位置account.target.com的密码重置功能 (/api/v1/verify-reset-code)。根本原因验证码校验接口未正确验证验证码与请求邮箱的归属关系导致攻击者可使用任意有效验证码为任意邮箱账户完成校验步骤。复现步骤这是核心。必须提供清晰、完整、可复现的步骤。就像我上面写的那样分步骤、配图关键请求和响应截图。使用Markdown列表或编号。请求/响应数据提供原始的HTTP请求和响应包可脱敏关键数据方便工程师直接定位问题。漏洞证明提供成功登录被接管账户的截图或视频。修复建议给出具体的修复方案。例如“在verify-reset-code接口的服务端逻辑中增加强校验确保提交的验证码必须与当前会话中请求发送验证码的邮箱地址完全匹配。建议使用服务器端存储的键值对session_id, email, code, timestamp进行校验。”时间线注明漏洞发现时间、报告时间。4.2 提交与沟通注意事项遵守规则严格遵循该SRC的提交格式、范围、测试方法限制如禁止DoS测试、禁止社工等。一洞一报每个独立的漏洞单独提交一份报告不要混在一起。证据充分截图、视频要清晰关键参数要突出显示。视频最好有屏幕操作和网络抓包同屏显示。描述客观使用技术性语言避免夸张或带有攻击性的词汇。保持耐心提交后安全团队可能需要时间复现和评估。在对方联系你时积极、友好地配合沟通解答他们的疑问。在这个案例中我按照上述结构提交了报告。约24小时后SRC团队确认了漏洞并给出了高危评级。一周后漏洞被修复我也收到了相应的赏金。5. 深度防御视角与安全建议作为攻击方我们思考如何突破但更有价值的是站在防御方思考如何构建更坚固的体系。从这个案例出发我们可以总结出几点关键的安全建议5.1 认证与会话安全加固状态全链路绑定对于密码重置、邮箱绑定、支付确认等关键链式操作必须在服务器端维护一个完整的、不可预测的状态令牌如state将流程中的所有元素用户标识、操作类型、随机参数、时间戳进行加密或哈希绑定。客户端仅持有该令牌的引用任何步骤的请求都必须携带并验证此令牌的完整性和关联性。验证码安全设计绑定唯一标识验证码必须与发起请求的用户标识用户ID、会话ID、邮箱/手机号在服务端存储中进行强绑定。一次性与时效性验证码使用后立即失效且设置合理的短有效期如5分钟。防爆破对同一接收方的验证码请求频率进行限制并实施图形验证码或行为验证码如滑块作为前置。权限校验中间件化对于所有API接口尤其是涉及对象IDuserId,orderId,fileId的必须在统一的权限校验中间件中进行访问控制列表检查。原则是“默认拒绝”即除非显式允许否则禁止访问。校验应基于当前认证用户的身份和权限而非客户端传递的参数。5.2 资产与信息安全管理最小化攻击面定期进行资产梳理下线或严格隔离测试环境、陈旧系统、不再使用的子域名。像案例中的dev-jenkins.target.com这类资产不应被外部网络直接访问应通过VPN或堡垒机进行访问控制。敏感信息扫描常态化将GitHub等代码仓库的敏感信息扫描纳入日常安全运维流程。可以使用TruffleHog,GitGuardian等工具进行自动化扫描防止员工误将密钥、配置上传至公开仓库。依赖组件安全管理建立软件物料清单持续监控应用所使用的第三方库、框架的漏洞信息并及时升级或打补丁。5.3 安全开发生命周期融入威胁建模在功能设计阶段就对关键业务流如登录、支付、密码重置进行威胁建模识别潜在的攻击路径如本案例中的状态篡改、IDOR。代码审计与自动化扫描将静态应用安全测试和动态应用安全测试工具集成到CI/CD流水线中对逻辑漏洞、常见的OWASP Top 10漏洞进行自动化检测。安全培训对开发人员进行持续的安全编码培训让他们理解常见漏洞的原理和危害从源头减少漏洞引入。漏洞挖掘是一场攻防双方在认知层面的较量。攻击者不断寻找系统逻辑和实现上的“断层”而防御者则需要构建纵深、立体的防御体系将安全思维渗透到每一个功能和每一行代码中。这次“赏金”之旅与其说是一次技术胜利不如说是一次对现代Web应用安全薄弱环节的典型透视。希望这份实录不仅能帮助你找到漏洞更能启发你建立起更系统、更深入的安全思考方式。