1. 项目概述从“挖洞”到“挖金”的实战之路SRC也就是安全应急响应中心对于很多刚入行的安全爱好者或者想转行渗透测试的朋友来说常常被蒙上一层神秘的面纱。网上教程千千万但真到了自己上手去一个真实的SRC平台提交漏洞时却发现要么是找不到入口要么是挖到的漏洞别人早就提交过了忙活半天颗粒无收。这感觉就像你知道河里可能有金子但别人告诉你具体哪个位置有等你扛着锄头过去早就被挖得一干二净了。我干了十多年网络安全从早期的论坛“黑页”玩起到后来专职做渗透测试和漏洞挖掘SRC平台是我个人能力提升和额外收入的一个重要来源。今天我不讲那些空泛的理论也不罗列扫描器怎么用。我们就从一个实战者的角度聊聊怎么把一个“SRC漏洞挖掘”当成一个正经的“项目”来运作。这里的“项目”意味着它有明确的目标挖掘有效漏洞并提交、有系统的思路信息收集、测试、验证、有风险控制避免违法和测试过度最终还有交付物漏洞报告。很多人把挖洞想得太简单以为就是拿个工具扫一扫其实它更像是一个系统的工程需要耐心、细心和一套可复用的方法论。这篇文章我会把我这些年踩过的坑、总结出来的有效打法以及那些在正式漏洞报告里不会写的“野路子”和判断逻辑毫无保留地分享出来。无论你是想通过SRC入门安全行业的学生还是想拓展实战经验的工程师抑或是寻找副业途径的技术人这些经验都能帮你少走弯路更快地看到成果。我们不说虚的直接上干货。2. 核心思路与项目化拆解你不是在碰运气你是在做工程很多人挖洞失败首要原因就是思路错了。他们把SRC挖掘等同于“用扫描器扫一遍”然后坐等结果。这在今天的环境下成功率极低。我们必须转变思维你不是一个碰运气的淘金者而是一个有方法的勘探工程师。2.1 目标选定如何挑一个“好挖”的SRC不是所有SRC都适合新手也不是所有时候都适合去挖。目标选对了事半功倍。关注新上线或改版业务这是漏洞的富矿。一个全新的APP、一个刚刚重构的官网、一个新推出的H5活动页面它们的代码可能未经受充分的安全测试。怎么发现关注目标企业的官方微博、公众号、应用商店更新日志。一个新功能上线后的头两周是测试的黄金窗口期。选择有“诚意”的平台看看SRC的漏洞评级标准、奖励范围和历史公示漏洞。有的平台规则清晰奖励及时对漏洞描述要求严格但反馈也专业这能让你在提交过程中学到很多东西。避免选择那些规则模糊、审核周期极长比如超过3个月无反馈、或者历史上很少公示中低危漏洞的平台这很可能意味着它们只关注高危漏洞或者内部流程有问题。专注垂直领域不要今天挖电商明天挖金融后天挖社交。每个行业的业务逻辑、技术架构、安全重点都不一样。初期可以专注1-2个你熟悉的领域。比如如果你懂金融业务就知道“支付”、“转账”、“积分兑换”是关键流程如果你熟悉社交那么“私信”、“动态发布”、“头像上传”就是重点。深耕一个领域你能更快地理解业务发现逻辑漏洞这是扫描器做不到的。避开“神仙打架”的红海一些头部互联网巨头的核心主站每天被无数安全专家和自动化脚本扫描你想找到一个别人没发现的、有价值的漏洞难度极高。可以尝试关注这些巨头的子域名、新收购的业务线、边缘业务系统如内部办公系统外泄、合作伙伴接口等或者一些正在快速发展的中型企业SRC。注意绝对不要触碰任何非授权的系统。只测试SRC公告中明确授权的域名和范围。在测试前务必再次阅读该SRC的最新测试规则范围可能随时调整。2.2 信息收集你的“侦察兵”工作做到位了吗信息收集的深度和广度直接决定了你攻击面的宽度。这里不能只依赖一两个工具。子域名挖掘这是基础中的基础。除了常用的subfinder、amass更要关注证书透明度日志利用crt.sh等网站通过证书查找子域名常能发现一些被遗忘的测试、预发布环境。DNS历史记录查看域名的DNS解析历史可能会找到已经下线但还未清理解析记录的老系统这些系统可能漏洞百出。泛解析识别如果发现大量随机字符串的子域名都解析到同一IP可能就是泛解析。可以尝试结合字典爆破出一些有意义的子域名。端口与服务探测对发现的IP资产进行端口扫描。不要只扫80443。重点关注非常见Web端口8080 8081 8443 7001 9000等。管理后台端口21FTP 22SSH 3389RDP 3306MySQL 6379Redis等。如果这些端口对外开放且存在弱口令可能就是重大安全隐患。工具nmap配合-sV参数进行版本探测至关重要。知道服务版本才能查找对应的已知漏洞。Web应用指纹识别识别出CMS、框架、中间件、前端库的版本。主动识别通过特定的HTTP请求头、默认文件、错误信息来判断。被动识别使用Wappalyzer浏览器插件或whatweb命令行工具。关键点识别出来后立刻去搜索该版本是否存在公开的漏洞CVE。很多SRC漏洞其实就是已知CVE的利用关键在于别人还没修补而你发现了。目录与文件扫描使用dirsearch、ffuf等工具但切忌无脑狂扫。使用定制化字典根据识别出的指纹如ThinkPHP SpringBoot使用对应的字典效率更高。关注备份文件、配置文件如.git目录、.svn目录、WEB-INF/web.xml、phpinfo.php、backup.zip、www.rar等。这些文件泄露源码、配置信息是通往RCE远程代码执行的捷径。控制扫描速率设置合理的延迟-delay避免把对方服务器扫崩或被封IP。2.3 漏洞探测思维从“有什么洞”到“哪里可能有洞”有了资产清单接下来不是盲目测试而是要进行威胁建模思考哪些地方最容易出问题。入口点梳理用户输入的一切都是不可信的表单、URL参数、Cookie、HTTP头、文件上传。功能点分析登录、注册、密码找回、个人信息修改、支付、订单查询、数据导出、消息发送、文件上传/下载。这些都是高风险功能点。漏洞类型关联有输入框且输出在页面上- 联想XSS跨站脚本、SQL注入如果输入用于数据库查询。有文件上传功能- 联想任意文件上传 尝试绕过后缀、内容类型检查上传Webshell。有查看他人信息的功能- 联想越权访问 尝试修改ID参数查看其他用户数据。有密码找回功能- 联想逻辑漏洞 分析验证码是否可爆破、是否可绕过、是否可回显到客户端。URL中包含参数- 联想SSRF服务端请求伪造、重定向漏洞。使用了JSON Web Token- 联想JWT伪造 检查密钥是否弱、算法是否可被修改为none。“莫名其妙”的漏洞案例拆解 就像网络资料里提到的“找回密码功能异常”、“URL编码越权”、“简单密保重置admin密码”这些都属于业务逻辑漏洞。它们没有通用的扫描器能直接发现全靠测试者对业务的理解和“刁钻”的思维。案例一找回密码绕过。流程通常是输入手机号-获取短信验证码-输入验证码-重置密码。漏洞点可能在于1验证码未与手机号绑定输入A手机号用B手机号收到的验证码也能通过2验证码在客户端校验修改返回包即可绕过3重置密码的最后一步仅验证了登录态未验证是否是“找回密码流程”中的用户。案例二URL编码越权。/user/info?id123 你把123改成124 系统提示无权限。但如果你把124进行URL编码变成%31%32%34 服务器解码后可能因为权限校验逻辑的缺陷错误地返回了124号用户的信息。这种漏洞需要你对各种编码、解析差异有敏感度。案例三弱密保问题。密保问题如“你的生日是哪天”、“你最喜欢的城市”答案可能非常容易被猜中或通过社工获取。如果这个密保问题用于重置高权限账户如admin就是严重漏洞。测试时要思考密保问题的答案是否足够复杂是否在用户的其他公开信息如社交资料中能找到3. 核心漏洞类型实战手法详解理论说再多不如手过一遍。下面我针对几种最常见的漏洞类型拆解我的实战测试流程和思考过程。3.1 业务逻辑漏洞最体现“智商”的漏洞这是SRC中价值较高且机器难以替代的漏洞类型。核心思想是理解正常流程寻找逻辑断点。实战案例优惠券无限领取漏洞目标一个电商平台的促销活动分享链接可领取限量优惠券。正常流程用户A打开分享链接-点击领取-系统检查用户是否已领取过-否则发放优惠券并标记该用户为“已领取”。测试过程抓包使用Burp Suite拦截“领取优惠券”的HTTP请求。观察参数请求中可能包含coupon_id,user_token,activity_id。尝试重放直接重放这个请求包发现返回“优惠券已领取”。说明服务端有状态校验。寻找标识点思考服务器靠什么判断“已领取”很可能是user_tokenactivity_id的组合。那么如果我改变user_token呢修改参数我没有另一个账号。但我注意到user_token看起来像是一个Base64编码的字符串。我解码后发现里面包含了用户ID和时间戳。我尝试修改其中的用户ID部分重新编码后替换原user_token。关键绕过发送修改后的请求。服务器竟然没有校验这个token的签名有效性它只是解码取出用户ID然后就判断这个“新”用户是否领取过。由于这个ID是我伪造的、不存在的用户系统自然判断为“未领取”成功发放优惠券。通过脚本批量生成伪造token即可实现无限领取。漏洞根源服务端完全信任了客户端传来的、未经验签的user_token且校验逻辑不完整。提交报告要点清晰描述正常流程、测试步骤、修改的参数、服务器响应对比用Burp的对比功能截图以及最终造成的危害资产损失平台营销资金被刷。3.2 越权访问漏洞你的就是我的我的还是我的越权分垂直越权低权限用户操作高权限功能和水平越权同权限用户操作他人数据。水平越权更常见。实战案例订单信息水平越权查看目标一个在线教育平台用户可查看自己的订单详情。正常访问GET /api/order/detail?order_id10001 返回用户自己的订单10001的详情。测试过程将order_id参数改为10002 尝试查看别人的订单。返回“无权限访问”。这是好的说明有基础校验。尝试其他ID格式数字不行试试UUID格式、短ID格式。发现订单ID是纯数字递增可能直接对应数据库主键。尝试批量探测写一个简单的Python脚本用我的认证Cookie遍历order_id从10000到10010。发现1000310005两个订单可以成功访问返回了其他用户的姓名、课程、价格等敏感信息。分析原因进一步分析可访问的订单特征发现它们都是“待支付”状态的订单。而我自己已支付的订单如10001和别人的已支付订单如10002则无法访问。推断后端逻辑可能是校验订单所属用户时只校验了“已支付”订单。对于“待支付”订单可能出于“方便用户继续支付”的考虑校验逻辑有遗漏。漏洞根源权限校验逻辑存在状态依赖缺陷未对所有状态的订单进行严格的属主校验。实操心得测试越权不要只改一个ID就放弃。要系统性地测试1不同数据类型的ID数字、字符串、UUID2不同状态的数据待支付、已完成、已取消3不同功能点的同类参数查看、修改、删除接口是否都存在漏洞。3.3 前端安全漏洞XSS与CSRF虽然现在前端框架和浏览器安全机制日益完善但配置不当或开发疏忽依然会导致问题。XSS实战要点寻找输出点所有用户可控输入并最终在页面显示的地方。包括搜索框、评论框、个人信息昵称、签名、URL参数回显在页面标题或内容中、甚至HTTP头如Referer有时会被显示。测试Payload不要只用scriptalert(1)/script。要多样化HTML标签img src1 onerroralert(1),svg onloadalert(1),body onloadalert(1)事件属性onmouseover,onfocus,onblur等。JavaScript伪协议a hrefjavascript:alert(1)click/a绕过技巧如果过滤了script 试试大小写、双写、插入换行符、使用Unicode编码、利用HTML实体解码特性。区分存储型与反射型提交Payload后刷新页面或在新会话中访问漏洞是否还在在则多为存储型危害更大。利用证明对于SRC你需要证明危害。弹窗alert(document.domain)比alert(1)更好因为它证明了漏洞发生在目标域名下。更进一步可以构造Payload窃取当前用户的Cookie需注意平台规则有些SRC禁止窃取真实Cookie可用alert(document.cookie)证明可能性。CSRF实战要点寻找关键操作修改密码、修改邮箱、转账、发表内容等执行“写”操作的接口。检查防护查看请求中是否有CSRF Token、是否有自定义Header如X-Requested-With、是否校验Referer。测试绕过Token问题Token是否可预测是否与用户会话无关如全局固定是否放在URL中导致可被Referer泄露Referer校验检查是否校验Referer的完整性。尝试在自家域名下构造一个页面发起请求或者利用一些开放重定向漏洞将Referer“洗”成白名单域名。自定义Header有些前端框架会自动添加X-Requested-With: XMLHttpRequest。如果后端仅校验此Header存在那么攻击者同样可以在伪造的请求中加上它。关键是这个Header是否是可预测的、是否与会话绑定。构造PoC创建一个HTML文件里面包含一个自动提交的表单form或一个图片标签img src修改密码的URL模拟用户点击或加载时触发请求。证明在用户已登录的情况下访问你的恶意页面即可完成敏感操作。4. 工具链与自动化让你的挖掘效率翻倍手工测试是灵魂但自动化是翅膀。合理的工具链能把你从重复劳动中解放出来专注于思考。4.1 我的核心工具栈工具类别工具名称主要用途使用心得代理与抓包Burp Suite ProfessionalHTTP/HTTPS流量拦截、修改、重放、扫描。社区版也足够用。重点掌握Proxy、Repeater、Intruder、Scanner模块。配置好CA证书抓取HTTPS流量。信息收集Amass, Subfinder, Assetfinder子域名枚举。组合使用结果去重。可以将它们集成到自己的脚本中定期自动运行。altdns通过置换、拼接生成子域名字典。对于发现那些不常见的、拼接而成的子域名特别有效。httpx/httprobe验证子域名存活并获取标题、状态码。必用。快速从海量子域名中筛选出Web服务。目录扫描ffuf高速的Web模糊测试工具。比传统的dirb、dirsearch更快更灵活。学会使用-w指定字典-fc过滤状态码-fs过滤返回大小。漏洞扫描Nuclei基于YAML模板的漏洞扫描器。神器。社区有成千上万的模板覆盖各种CVE、配置错误、默认凭据。关键不要无脑全量扫描根据指纹信息加载相关模板并务必调整速率。Xray被动式漏洞扫描器。配合Burp Suite作为被动扫描插件非常好用能发现一些常规主动扫描器容易遗漏的漏洞如SSRF的部分情况。综合平台AWVS, AppScan商业级Web漏洞扫描器。扫描深度和准确性较高但速度慢噪音大。适合对重点目标进行深度扫描作为手工测试的补充。注意授权只扫描你被授权的资产。辅助开发Python3 Requests库编写自定义的探测、爆破、验证脚本。必备技能。很多独特的漏洞需要自己写脚本来批量测试或验证。4.2 搭建一个简单的自动化侦察系统你可以用简单的Shell脚本或Python脚本将以上工具串联起来实现半自动化。#!/bin/bash # 一个简单的子域名收集与初筛脚本示例 DOMAIN$1 echo [*] 开始收集子域名: $DOMAIN # 使用多种工具收集 subfinder -d $DOMAIN -silent -o subfinder.txt amass enum -passive -d $DOMAIN -o amass.txt # ... 可以加入其他来源 # 合并去重 cat subfinder.txt amass.txt | sort -u all_subs.txt echo [] 子域名收集完成共 $(wc -l all_subs.txt) 条记录 # 探测存活和Web服务 echo [*] 开始HTTP探测... httpx -l all_subs.txt -title -status-code -tech-detect -o httpx_results.txt # 从结果中提取出存活的域名 grep -v \[FAILED\] httpx_results.txt | awk {print $1} alive_subs.txt echo [] 存活域名筛选完成共 $(wc -l alive_subs.txt) 条记录 echo [*] 对存活域名进行快速指纹识别... while read -r url; do whatweb $url --colornever whatweb_results.txt 2/dev/null done alive_subs.txt echo [!] 初步侦察结束。请查看 alive_subs.txt 和 whatweb_results.txt 文件。这个脚本只是一个起点。你可以在此基础上增加端口扫描、目录扫描、Nuclei模板扫描等模块。核心原则是自动化处理重复、耗时的信息收集和初步筛查工作把宝贵的时间留给手工深度测试和逻辑分析。5. 漏洞报告撰写与提交临门一脚的艺术挖到漏洞只是成功了一半一份清晰、专业、令人信服的漏洞报告是你能拿到奖励和认可的关键。5.1 报告必备要素漏洞标题简明扼要。格式通常为【漏洞类型】【影响功能点】。例如“【水平越权】订单查询接口可查看他人订单信息”、“【存储型XSS】个人简介处未过滤导致任意JavaScript执行”。漏洞等级参考目标SRC的定级标准。如果不确定可先标为“中危”由平台审核调整。不要夸大危害。漏洞发现时间精确到日即可。影响范围说明漏洞影响哪些用户、哪些数据、哪些业务功能。例如“影响所有平台注册用户”、“泄露其他用户的姓名、手机号、订单详情等敏感信息”。详细复现步骤这是报告的核心必须做到傻瓜式教学。步骤编号1 2 3...前置条件需要什么样的账号普通用户、VIP用户操作过程在哪个页面附URL点击什么输入什么数据。关键输入要用加粗或代码块标出。每一步的服务器请求和响应必须附上Burp Suite或浏览器开发者工具的截图/原始数据。截图要包含完整的HTTP请求和响应特别是修改的参数和异常的返回结果。可以使用Burp的Copy as curl command功能提供可复现的命令。证明漏洞存在的关键结果例如越权看到他人数据的页面截图需高亮敏感信息、XSS弹窗截图显示document.domain、CSRF成功执行后的页面提示等。漏洞原理分析简要说明你认为漏洞产生的原因。例如“服务端在处理订单查询请求时仅校验了用户会话未校验订单ID与用户的归属关系导致水平越权。”修复建议给出建设性的修复方案。体现你的专业性。例如“建议在查询订单信息前增加订单所属用户ID与当前登录用户ID的强校验。”、“建议对用户输入的简介内容进行严格的HTML实体编码过滤或使用安全的富文本编辑器白名单方案。”其他信息测试使用的浏览器版本、工具等。5.2 提交与沟通技巧遵守规则再次确认测试范围、测试方法是否允许自动化扫描、压力测试、漏洞提交格式。一洞一报一个报告只描述一个独立的漏洞。不要把多个不同位置的XSS或越权塞到一个报告里。跟进与回应提交后关注平台状态。如果审核人员有疑问及时、礼貌地补充信息。沟通时对事不对人用技术证据说话。接受结果如果漏洞被判定为重复、无效或低风险保持平常心。分析原因是信息收集不够导致别人先发现了还是漏洞危害评估有误从中学习改进自己的方法。6. 常见问题与排查实录这条路我踩过很多坑下面是一些典型问题和我的解决思路。Q1为什么我按照教程测试总是找不到漏洞A1首先公开教程里的漏洞点往往在文章发布后不久就被修复了。其次你可能停留在“照搬”层面。关键在于理解漏洞原理而不是记住Payload。比如SQL注入你要理解它是由于用户输入被“拼接”到SQL语句中且未过滤。那么你的任务就是找到所有可能进行数据库查询的输入点然后测试它们是否可以被拼接并执行。从“用Payload去碰”转变为“用原理去找”。Q2我的扫描器报了很多“疑似漏洞”怎么判断真假A2扫描器尤其是主动扫描器误报率很高。任何扫描器报告都必须经过手工验证。步骤1在Burp Repeater中重现扫描器发送的Payload和请求。2仔细分析服务器返回的响应与正常请求的响应做对比用Burp的对比功能。3判断差异是否真的由你的Payload导致并且是否构成安全威胁。例如一个“疑似SQL注入”的报错可能只是触发了应用层的参数错误提示并没有数据库报错信息。Q3测试时不小心把网站搞慢了或者触发了告警怎么办A3立即停止测试这是红线。在测试前就应该控制好自动化工具的并发线程、请求延迟。对于手工测试也要避免对同一个功能点进行高频、重复的异常操作。如果不小心触发可以尝试通过SRC平台的联系方式如果有进行简要说明表明是安全测试行为并已停止。良好的测试习惯是职业素养的体现。Q4挖到的漏洞总是“低危”或“无影响”怎么提升漏洞等级A4尝试将漏洞进行“组合利用”或深入挖掘其“最大危害”。组合利用一个存储型XSS可能只是低危。但如果这个XSS点存在于管理员后台可以盗取管理员Cookie高危。或者一个普通的越权查看是低危但如果能越权修改或删除就是高危。一个信息泄露漏洞如源码泄露本身可能是中低危但泄露的源码里包含数据库密码、API密钥就可能升级为高危。深入危害不仅仅证明“可以弹窗”要证明“可以做什么”。对于XSS证明可以窃取用户Cookie、发起恶意请求如转发微博、篡改页面内容如钓鱼。对于越权证明可以操作的数据量有多大是所有用户吗、数据的敏感程度如何是手机号、地址还是身份证号。Q5如何保持挖掘效率和动力A5把挖洞项目化、周期化。设定小目标比如“这周我要专注研究A公司的子域名资产”或者“今天我要把B应用的密码找回流程彻底测一遍”。建立知识库用笔记软件记录每个目标的资产信息、测试过的功能点、发现的疑点即使当时没成功。定期回顾可能会有新思路。加入社区在合规的前提下和其他安全研究者交流思路不交流具体漏洞细节学习新的工具和方法。接受空窗期挖洞就像钓鱼不可能每次都满载而归。空手而归是常态但这个过程本身就在锻炼你的侦察、分析和思考能力。这条路没有捷径它考验的是你的耐心、细致和持续学习的能力。每一次测试无论成功与否都是对你技术视野的一次拓宽。从最开始的手足无措到后来能系统性地发现并证明一个中高危漏洞这种成就感是实实在在的。希望我的这些实战经验能为你点亮一盏灯让你在SRC漏洞挖掘的项目实战中走得更稳、更远。最后记住技术是用来建设和保护的永远在法律和道德的框架内行事这是所有安全从业者不可逾越的底线。
SRC漏洞挖掘实战：从信息收集到逻辑漏洞的工程化方法论
发布时间：2026/7/8 17:12:08
1. 项目概述从“挖洞”到“挖金”的实战之路SRC也就是安全应急响应中心对于很多刚入行的安全爱好者或者想转行渗透测试的朋友来说常常被蒙上一层神秘的面纱。网上教程千千万但真到了自己上手去一个真实的SRC平台提交漏洞时却发现要么是找不到入口要么是挖到的漏洞别人早就提交过了忙活半天颗粒无收。这感觉就像你知道河里可能有金子但别人告诉你具体哪个位置有等你扛着锄头过去早就被挖得一干二净了。我干了十多年网络安全从早期的论坛“黑页”玩起到后来专职做渗透测试和漏洞挖掘SRC平台是我个人能力提升和额外收入的一个重要来源。今天我不讲那些空泛的理论也不罗列扫描器怎么用。我们就从一个实战者的角度聊聊怎么把一个“SRC漏洞挖掘”当成一个正经的“项目”来运作。这里的“项目”意味着它有明确的目标挖掘有效漏洞并提交、有系统的思路信息收集、测试、验证、有风险控制避免违法和测试过度最终还有交付物漏洞报告。很多人把挖洞想得太简单以为就是拿个工具扫一扫其实它更像是一个系统的工程需要耐心、细心和一套可复用的方法论。这篇文章我会把我这些年踩过的坑、总结出来的有效打法以及那些在正式漏洞报告里不会写的“野路子”和判断逻辑毫无保留地分享出来。无论你是想通过SRC入门安全行业的学生还是想拓展实战经验的工程师抑或是寻找副业途径的技术人这些经验都能帮你少走弯路更快地看到成果。我们不说虚的直接上干货。2. 核心思路与项目化拆解你不是在碰运气你是在做工程很多人挖洞失败首要原因就是思路错了。他们把SRC挖掘等同于“用扫描器扫一遍”然后坐等结果。这在今天的环境下成功率极低。我们必须转变思维你不是一个碰运气的淘金者而是一个有方法的勘探工程师。2.1 目标选定如何挑一个“好挖”的SRC不是所有SRC都适合新手也不是所有时候都适合去挖。目标选对了事半功倍。关注新上线或改版业务这是漏洞的富矿。一个全新的APP、一个刚刚重构的官网、一个新推出的H5活动页面它们的代码可能未经受充分的安全测试。怎么发现关注目标企业的官方微博、公众号、应用商店更新日志。一个新功能上线后的头两周是测试的黄金窗口期。选择有“诚意”的平台看看SRC的漏洞评级标准、奖励范围和历史公示漏洞。有的平台规则清晰奖励及时对漏洞描述要求严格但反馈也专业这能让你在提交过程中学到很多东西。避免选择那些规则模糊、审核周期极长比如超过3个月无反馈、或者历史上很少公示中低危漏洞的平台这很可能意味着它们只关注高危漏洞或者内部流程有问题。专注垂直领域不要今天挖电商明天挖金融后天挖社交。每个行业的业务逻辑、技术架构、安全重点都不一样。初期可以专注1-2个你熟悉的领域。比如如果你懂金融业务就知道“支付”、“转账”、“积分兑换”是关键流程如果你熟悉社交那么“私信”、“动态发布”、“头像上传”就是重点。深耕一个领域你能更快地理解业务发现逻辑漏洞这是扫描器做不到的。避开“神仙打架”的红海一些头部互联网巨头的核心主站每天被无数安全专家和自动化脚本扫描你想找到一个别人没发现的、有价值的漏洞难度极高。可以尝试关注这些巨头的子域名、新收购的业务线、边缘业务系统如内部办公系统外泄、合作伙伴接口等或者一些正在快速发展的中型企业SRC。注意绝对不要触碰任何非授权的系统。只测试SRC公告中明确授权的域名和范围。在测试前务必再次阅读该SRC的最新测试规则范围可能随时调整。2.2 信息收集你的“侦察兵”工作做到位了吗信息收集的深度和广度直接决定了你攻击面的宽度。这里不能只依赖一两个工具。子域名挖掘这是基础中的基础。除了常用的subfinder、amass更要关注证书透明度日志利用crt.sh等网站通过证书查找子域名常能发现一些被遗忘的测试、预发布环境。DNS历史记录查看域名的DNS解析历史可能会找到已经下线但还未清理解析记录的老系统这些系统可能漏洞百出。泛解析识别如果发现大量随机字符串的子域名都解析到同一IP可能就是泛解析。可以尝试结合字典爆破出一些有意义的子域名。端口与服务探测对发现的IP资产进行端口扫描。不要只扫80443。重点关注非常见Web端口8080 8081 8443 7001 9000等。管理后台端口21FTP 22SSH 3389RDP 3306MySQL 6379Redis等。如果这些端口对外开放且存在弱口令可能就是重大安全隐患。工具nmap配合-sV参数进行版本探测至关重要。知道服务版本才能查找对应的已知漏洞。Web应用指纹识别识别出CMS、框架、中间件、前端库的版本。主动识别通过特定的HTTP请求头、默认文件、错误信息来判断。被动识别使用Wappalyzer浏览器插件或whatweb命令行工具。关键点识别出来后立刻去搜索该版本是否存在公开的漏洞CVE。很多SRC漏洞其实就是已知CVE的利用关键在于别人还没修补而你发现了。目录与文件扫描使用dirsearch、ffuf等工具但切忌无脑狂扫。使用定制化字典根据识别出的指纹如ThinkPHP SpringBoot使用对应的字典效率更高。关注备份文件、配置文件如.git目录、.svn目录、WEB-INF/web.xml、phpinfo.php、backup.zip、www.rar等。这些文件泄露源码、配置信息是通往RCE远程代码执行的捷径。控制扫描速率设置合理的延迟-delay避免把对方服务器扫崩或被封IP。2.3 漏洞探测思维从“有什么洞”到“哪里可能有洞”有了资产清单接下来不是盲目测试而是要进行威胁建模思考哪些地方最容易出问题。入口点梳理用户输入的一切都是不可信的表单、URL参数、Cookie、HTTP头、文件上传。功能点分析登录、注册、密码找回、个人信息修改、支付、订单查询、数据导出、消息发送、文件上传/下载。这些都是高风险功能点。漏洞类型关联有输入框且输出在页面上- 联想XSS跨站脚本、SQL注入如果输入用于数据库查询。有文件上传功能- 联想任意文件上传 尝试绕过后缀、内容类型检查上传Webshell。有查看他人信息的功能- 联想越权访问 尝试修改ID参数查看其他用户数据。有密码找回功能- 联想逻辑漏洞 分析验证码是否可爆破、是否可绕过、是否可回显到客户端。URL中包含参数- 联想SSRF服务端请求伪造、重定向漏洞。使用了JSON Web Token- 联想JWT伪造 检查密钥是否弱、算法是否可被修改为none。“莫名其妙”的漏洞案例拆解 就像网络资料里提到的“找回密码功能异常”、“URL编码越权”、“简单密保重置admin密码”这些都属于业务逻辑漏洞。它们没有通用的扫描器能直接发现全靠测试者对业务的理解和“刁钻”的思维。案例一找回密码绕过。流程通常是输入手机号-获取短信验证码-输入验证码-重置密码。漏洞点可能在于1验证码未与手机号绑定输入A手机号用B手机号收到的验证码也能通过2验证码在客户端校验修改返回包即可绕过3重置密码的最后一步仅验证了登录态未验证是否是“找回密码流程”中的用户。案例二URL编码越权。/user/info?id123 你把123改成124 系统提示无权限。但如果你把124进行URL编码变成%31%32%34 服务器解码后可能因为权限校验逻辑的缺陷错误地返回了124号用户的信息。这种漏洞需要你对各种编码、解析差异有敏感度。案例三弱密保问题。密保问题如“你的生日是哪天”、“你最喜欢的城市”答案可能非常容易被猜中或通过社工获取。如果这个密保问题用于重置高权限账户如admin就是严重漏洞。测试时要思考密保问题的答案是否足够复杂是否在用户的其他公开信息如社交资料中能找到3. 核心漏洞类型实战手法详解理论说再多不如手过一遍。下面我针对几种最常见的漏洞类型拆解我的实战测试流程和思考过程。3.1 业务逻辑漏洞最体现“智商”的漏洞这是SRC中价值较高且机器难以替代的漏洞类型。核心思想是理解正常流程寻找逻辑断点。实战案例优惠券无限领取漏洞目标一个电商平台的促销活动分享链接可领取限量优惠券。正常流程用户A打开分享链接-点击领取-系统检查用户是否已领取过-否则发放优惠券并标记该用户为“已领取”。测试过程抓包使用Burp Suite拦截“领取优惠券”的HTTP请求。观察参数请求中可能包含coupon_id,user_token,activity_id。尝试重放直接重放这个请求包发现返回“优惠券已领取”。说明服务端有状态校验。寻找标识点思考服务器靠什么判断“已领取”很可能是user_tokenactivity_id的组合。那么如果我改变user_token呢修改参数我没有另一个账号。但我注意到user_token看起来像是一个Base64编码的字符串。我解码后发现里面包含了用户ID和时间戳。我尝试修改其中的用户ID部分重新编码后替换原user_token。关键绕过发送修改后的请求。服务器竟然没有校验这个token的签名有效性它只是解码取出用户ID然后就判断这个“新”用户是否领取过。由于这个ID是我伪造的、不存在的用户系统自然判断为“未领取”成功发放优惠券。通过脚本批量生成伪造token即可实现无限领取。漏洞根源服务端完全信任了客户端传来的、未经验签的user_token且校验逻辑不完整。提交报告要点清晰描述正常流程、测试步骤、修改的参数、服务器响应对比用Burp的对比功能截图以及最终造成的危害资产损失平台营销资金被刷。3.2 越权访问漏洞你的就是我的我的还是我的越权分垂直越权低权限用户操作高权限功能和水平越权同权限用户操作他人数据。水平越权更常见。实战案例订单信息水平越权查看目标一个在线教育平台用户可查看自己的订单详情。正常访问GET /api/order/detail?order_id10001 返回用户自己的订单10001的详情。测试过程将order_id参数改为10002 尝试查看别人的订单。返回“无权限访问”。这是好的说明有基础校验。尝试其他ID格式数字不行试试UUID格式、短ID格式。发现订单ID是纯数字递增可能直接对应数据库主键。尝试批量探测写一个简单的Python脚本用我的认证Cookie遍历order_id从10000到10010。发现1000310005两个订单可以成功访问返回了其他用户的姓名、课程、价格等敏感信息。分析原因进一步分析可访问的订单特征发现它们都是“待支付”状态的订单。而我自己已支付的订单如10001和别人的已支付订单如10002则无法访问。推断后端逻辑可能是校验订单所属用户时只校验了“已支付”订单。对于“待支付”订单可能出于“方便用户继续支付”的考虑校验逻辑有遗漏。漏洞根源权限校验逻辑存在状态依赖缺陷未对所有状态的订单进行严格的属主校验。实操心得测试越权不要只改一个ID就放弃。要系统性地测试1不同数据类型的ID数字、字符串、UUID2不同状态的数据待支付、已完成、已取消3不同功能点的同类参数查看、修改、删除接口是否都存在漏洞。3.3 前端安全漏洞XSS与CSRF虽然现在前端框架和浏览器安全机制日益完善但配置不当或开发疏忽依然会导致问题。XSS实战要点寻找输出点所有用户可控输入并最终在页面显示的地方。包括搜索框、评论框、个人信息昵称、签名、URL参数回显在页面标题或内容中、甚至HTTP头如Referer有时会被显示。测试Payload不要只用scriptalert(1)/script。要多样化HTML标签img src1 onerroralert(1),svg onloadalert(1),body onloadalert(1)事件属性onmouseover,onfocus,onblur等。JavaScript伪协议a hrefjavascript:alert(1)click/a绕过技巧如果过滤了script 试试大小写、双写、插入换行符、使用Unicode编码、利用HTML实体解码特性。区分存储型与反射型提交Payload后刷新页面或在新会话中访问漏洞是否还在在则多为存储型危害更大。利用证明对于SRC你需要证明危害。弹窗alert(document.domain)比alert(1)更好因为它证明了漏洞发生在目标域名下。更进一步可以构造Payload窃取当前用户的Cookie需注意平台规则有些SRC禁止窃取真实Cookie可用alert(document.cookie)证明可能性。CSRF实战要点寻找关键操作修改密码、修改邮箱、转账、发表内容等执行“写”操作的接口。检查防护查看请求中是否有CSRF Token、是否有自定义Header如X-Requested-With、是否校验Referer。测试绕过Token问题Token是否可预测是否与用户会话无关如全局固定是否放在URL中导致可被Referer泄露Referer校验检查是否校验Referer的完整性。尝试在自家域名下构造一个页面发起请求或者利用一些开放重定向漏洞将Referer“洗”成白名单域名。自定义Header有些前端框架会自动添加X-Requested-With: XMLHttpRequest。如果后端仅校验此Header存在那么攻击者同样可以在伪造的请求中加上它。关键是这个Header是否是可预测的、是否与会话绑定。构造PoC创建一个HTML文件里面包含一个自动提交的表单form或一个图片标签img src修改密码的URL模拟用户点击或加载时触发请求。证明在用户已登录的情况下访问你的恶意页面即可完成敏感操作。4. 工具链与自动化让你的挖掘效率翻倍手工测试是灵魂但自动化是翅膀。合理的工具链能把你从重复劳动中解放出来专注于思考。4.1 我的核心工具栈工具类别工具名称主要用途使用心得代理与抓包Burp Suite ProfessionalHTTP/HTTPS流量拦截、修改、重放、扫描。社区版也足够用。重点掌握Proxy、Repeater、Intruder、Scanner模块。配置好CA证书抓取HTTPS流量。信息收集Amass, Subfinder, Assetfinder子域名枚举。组合使用结果去重。可以将它们集成到自己的脚本中定期自动运行。altdns通过置换、拼接生成子域名字典。对于发现那些不常见的、拼接而成的子域名特别有效。httpx/httprobe验证子域名存活并获取标题、状态码。必用。快速从海量子域名中筛选出Web服务。目录扫描ffuf高速的Web模糊测试工具。比传统的dirb、dirsearch更快更灵活。学会使用-w指定字典-fc过滤状态码-fs过滤返回大小。漏洞扫描Nuclei基于YAML模板的漏洞扫描器。神器。社区有成千上万的模板覆盖各种CVE、配置错误、默认凭据。关键不要无脑全量扫描根据指纹信息加载相关模板并务必调整速率。Xray被动式漏洞扫描器。配合Burp Suite作为被动扫描插件非常好用能发现一些常规主动扫描器容易遗漏的漏洞如SSRF的部分情况。综合平台AWVS, AppScan商业级Web漏洞扫描器。扫描深度和准确性较高但速度慢噪音大。适合对重点目标进行深度扫描作为手工测试的补充。注意授权只扫描你被授权的资产。辅助开发Python3 Requests库编写自定义的探测、爆破、验证脚本。必备技能。很多独特的漏洞需要自己写脚本来批量测试或验证。4.2 搭建一个简单的自动化侦察系统你可以用简单的Shell脚本或Python脚本将以上工具串联起来实现半自动化。#!/bin/bash # 一个简单的子域名收集与初筛脚本示例 DOMAIN$1 echo [*] 开始收集子域名: $DOMAIN # 使用多种工具收集 subfinder -d $DOMAIN -silent -o subfinder.txt amass enum -passive -d $DOMAIN -o amass.txt # ... 可以加入其他来源 # 合并去重 cat subfinder.txt amass.txt | sort -u all_subs.txt echo [] 子域名收集完成共 $(wc -l all_subs.txt) 条记录 # 探测存活和Web服务 echo [*] 开始HTTP探测... httpx -l all_subs.txt -title -status-code -tech-detect -o httpx_results.txt # 从结果中提取出存活的域名 grep -v \[FAILED\] httpx_results.txt | awk {print $1} alive_subs.txt echo [] 存活域名筛选完成共 $(wc -l alive_subs.txt) 条记录 echo [*] 对存活域名进行快速指纹识别... while read -r url; do whatweb $url --colornever whatweb_results.txt 2/dev/null done alive_subs.txt echo [!] 初步侦察结束。请查看 alive_subs.txt 和 whatweb_results.txt 文件。这个脚本只是一个起点。你可以在此基础上增加端口扫描、目录扫描、Nuclei模板扫描等模块。核心原则是自动化处理重复、耗时的信息收集和初步筛查工作把宝贵的时间留给手工深度测试和逻辑分析。5. 漏洞报告撰写与提交临门一脚的艺术挖到漏洞只是成功了一半一份清晰、专业、令人信服的漏洞报告是你能拿到奖励和认可的关键。5.1 报告必备要素漏洞标题简明扼要。格式通常为【漏洞类型】【影响功能点】。例如“【水平越权】订单查询接口可查看他人订单信息”、“【存储型XSS】个人简介处未过滤导致任意JavaScript执行”。漏洞等级参考目标SRC的定级标准。如果不确定可先标为“中危”由平台审核调整。不要夸大危害。漏洞发现时间精确到日即可。影响范围说明漏洞影响哪些用户、哪些数据、哪些业务功能。例如“影响所有平台注册用户”、“泄露其他用户的姓名、手机号、订单详情等敏感信息”。详细复现步骤这是报告的核心必须做到傻瓜式教学。步骤编号1 2 3...前置条件需要什么样的账号普通用户、VIP用户操作过程在哪个页面附URL点击什么输入什么数据。关键输入要用加粗或代码块标出。每一步的服务器请求和响应必须附上Burp Suite或浏览器开发者工具的截图/原始数据。截图要包含完整的HTTP请求和响应特别是修改的参数和异常的返回结果。可以使用Burp的Copy as curl command功能提供可复现的命令。证明漏洞存在的关键结果例如越权看到他人数据的页面截图需高亮敏感信息、XSS弹窗截图显示document.domain、CSRF成功执行后的页面提示等。漏洞原理分析简要说明你认为漏洞产生的原因。例如“服务端在处理订单查询请求时仅校验了用户会话未校验订单ID与用户的归属关系导致水平越权。”修复建议给出建设性的修复方案。体现你的专业性。例如“建议在查询订单信息前增加订单所属用户ID与当前登录用户ID的强校验。”、“建议对用户输入的简介内容进行严格的HTML实体编码过滤或使用安全的富文本编辑器白名单方案。”其他信息测试使用的浏览器版本、工具等。5.2 提交与沟通技巧遵守规则再次确认测试范围、测试方法是否允许自动化扫描、压力测试、漏洞提交格式。一洞一报一个报告只描述一个独立的漏洞。不要把多个不同位置的XSS或越权塞到一个报告里。跟进与回应提交后关注平台状态。如果审核人员有疑问及时、礼貌地补充信息。沟通时对事不对人用技术证据说话。接受结果如果漏洞被判定为重复、无效或低风险保持平常心。分析原因是信息收集不够导致别人先发现了还是漏洞危害评估有误从中学习改进自己的方法。6. 常见问题与排查实录这条路我踩过很多坑下面是一些典型问题和我的解决思路。Q1为什么我按照教程测试总是找不到漏洞A1首先公开教程里的漏洞点往往在文章发布后不久就被修复了。其次你可能停留在“照搬”层面。关键在于理解漏洞原理而不是记住Payload。比如SQL注入你要理解它是由于用户输入被“拼接”到SQL语句中且未过滤。那么你的任务就是找到所有可能进行数据库查询的输入点然后测试它们是否可以被拼接并执行。从“用Payload去碰”转变为“用原理去找”。Q2我的扫描器报了很多“疑似漏洞”怎么判断真假A2扫描器尤其是主动扫描器误报率很高。任何扫描器报告都必须经过手工验证。步骤1在Burp Repeater中重现扫描器发送的Payload和请求。2仔细分析服务器返回的响应与正常请求的响应做对比用Burp的对比功能。3判断差异是否真的由你的Payload导致并且是否构成安全威胁。例如一个“疑似SQL注入”的报错可能只是触发了应用层的参数错误提示并没有数据库报错信息。Q3测试时不小心把网站搞慢了或者触发了告警怎么办A3立即停止测试这是红线。在测试前就应该控制好自动化工具的并发线程、请求延迟。对于手工测试也要避免对同一个功能点进行高频、重复的异常操作。如果不小心触发可以尝试通过SRC平台的联系方式如果有进行简要说明表明是安全测试行为并已停止。良好的测试习惯是职业素养的体现。Q4挖到的漏洞总是“低危”或“无影响”怎么提升漏洞等级A4尝试将漏洞进行“组合利用”或深入挖掘其“最大危害”。组合利用一个存储型XSS可能只是低危。但如果这个XSS点存在于管理员后台可以盗取管理员Cookie高危。或者一个普通的越权查看是低危但如果能越权修改或删除就是高危。一个信息泄露漏洞如源码泄露本身可能是中低危但泄露的源码里包含数据库密码、API密钥就可能升级为高危。深入危害不仅仅证明“可以弹窗”要证明“可以做什么”。对于XSS证明可以窃取用户Cookie、发起恶意请求如转发微博、篡改页面内容如钓鱼。对于越权证明可以操作的数据量有多大是所有用户吗、数据的敏感程度如何是手机号、地址还是身份证号。Q5如何保持挖掘效率和动力A5把挖洞项目化、周期化。设定小目标比如“这周我要专注研究A公司的子域名资产”或者“今天我要把B应用的密码找回流程彻底测一遍”。建立知识库用笔记软件记录每个目标的资产信息、测试过的功能点、发现的疑点即使当时没成功。定期回顾可能会有新思路。加入社区在合规的前提下和其他安全研究者交流思路不交流具体漏洞细节学习新的工具和方法。接受空窗期挖洞就像钓鱼不可能每次都满载而归。空手而归是常态但这个过程本身就在锻炼你的侦察、分析和思考能力。这条路没有捷径它考验的是你的耐心、细致和持续学习的能力。每一次测试无论成功与否都是对你技术视野的一次拓宽。从最开始的手足无措到后来能系统性地发现并证明一个中高危漏洞这种成就感是实实在在的。希望我的这些实战经验能为你点亮一盏灯让你在SRC漏洞挖掘的项目实战中走得更稳、更远。最后记住技术是用来建设和保护的永远在法律和道德的框架内行事这是所有安全从业者不可逾越的底线。
