你需要足够谦虚，认识到你可能会失去一切，但也要足够自信，相信你可以收回一切。
| 编号 | 描述 |
| 1 | 新目标至少探测30分钟； |
| 2 | 寻找逻辑漏洞； |
| 3 | XSS测试用斜体标签代替Payload； |
| 4 | 重点关注多租户SaaS应用； |
| 5 | 购置Burp Pro； |
| 6 | 直奔用户管理模块； |
| 7 | 检查邀请用户加入组织是否会暴露他们的姓名 - 测试邀请用户功能是否存在信息泄露； |
| 8 | 检查邀请用户是否会将他们从自己的组织中移除 - 测试邀请用户功能是否存在越权操作； |
| 9 |
范围有通配符，用Subfinder找子域名； |
| 10 | 用HTTPX筛选活跃子域名； |
| 11 | 不熟悉的应用，请先像普通用户一样使用； |
| 12 | 文档说不允许的操作却可以执行，就是漏洞； |
| 13 | 使用匹配和替换规则来查找新的接口 - 基于规则的接口发现； |
| 14 | 每周安排专门的渗透测试时间； |
| 15 | 设定挖洞时间上限（例如4小时）； |
| 16 | 回顾之前的重复漏洞，尝试复现； |
| 17 | 在你的日志中查找“+2”以查找现在应该存在的重复项 - 利用日志识别重复漏洞； |
| 18 | 向其他白帽子求助； |
| 19 | 让你的报告成为一次对话，而不是 sales pitch -- |
| 20 |
接受重复漏洞的现实； |
| 21 |
提交后就放下（File & Forget）； |
| 22 | 接口有"api/v2/"，尝试"api/v1/"； |
| 23 | 接口有"api/v2"，尝试移除"v2"； |
| 24 | 5个中等漏洞比1个严重漏洞收益更高，别忽略小漏洞； |
| 25 |
低危漏洞也应提交； |
| 26 | 对漏洞审核人员客气友善！ |
| 27 | 收到赏金后表示感谢！ |
| 28 | 应用程序使用UUID，仍然可以查找IDOR，设置"AC:H" (Auto-Complete: History)； |
| 29 | 存在UUID IDOR，寻找暴露UUID的接口； |
| 30 | 成功与否取决于是否遵循计划，而非是否找到漏洞； |
| 31 |
一个有很多黑客参与的项目并不意味着没有容易发现的漏洞 --勿以参与人数判断漏洞难度 |
| 32 |
坚持深入挖掘，终将会有回报； |
| 33 |
与新白帽子合作会有好处； |
| 34 | 不要嫉妒； |
| 35 |
赏金收入不稳定，接受波动； |
| 36 | 漏洞超出范围，问问厂商是否在意； |
| 37 | 没有终点，享受过程； |
| 38 |
有个和安全无关的爱好； |
| 39 | 结交不做安全的朋友； |
| 40 |
找到自己效率最高的挖洞时间段； |
| 41 | 多花点时间润色报告； |
| 42 |
“订阅”高赏金、范围广的项目； |
| 43 | 别在微信上抱怨单个报告，或者任何其他方式的抱怨； |
| 44 |
优先关注 IDOR 和权限提升漏洞； |
| 45 |
不切实际的期望导致失望； |
| 46 |
教别人渗透测试； |
| 47 | 阅读学习的时间是值得的； |
| 48 |
专注于测试你熟悉的应用程序！ |
| 49 | 与项目方建立关系； |
| 50 | 询问项目方希望发现哪些类型的漏洞； |
| 51 |
查看排行榜，寻找合作对象； |
| 52 |
合作时，平均分配赏金避免纠纷； |
| 53 |
感到疲倦就休息； |
| 54 | 在(Live Hacking Event)黑客或安全专家进行的实时演示之前，就开始测试...提前准确 |
| 55 | 选择响应积极的项目； |
| 56 | 关注奖励较少的项目； |
| 57 | 寻找允许合作的项目； |
| 58 | 选择未公开已知问题的项目； |
| 59 | 关注范围更新的项目； |
| 60 | 长期未发现漏洞，改变策略； |
| 61 |
顺风顺水时，保持现有策略； |
| 62 | 但别让成功阻碍你进步； |
| 63 |
将自己与去年的自己比较； |
| 64 |
保持网络活跃度，寻找新机会； |
| 65 |
感谢失败！ |
| 66 | 阅读已公开的漏洞报告； |
| 67 | 一次专注一个项目，感到无聊就轮换； |
| 68 | 不要到处乱扔XSS Payload； |
| 69 | 如果可能，在有漏洞赏金项目的公司工作； |
| 70 | 将赏金用于购买能带来更多赏金的工具； |
| 71 | 预留一部分赏金用于娱乐，并坚持执行； |
| 72 | 测试商店App时，小额购物会有帮助，不要吝啬小额开支； |
| 73 |
关注JS文件变化，发现新功能； |
| 74 |
在公司Github仓库中寻找子域名； |
| 75 | 在员工Github仓库中寻找子域名； |
| 76 | 测试第三方组件集成； |
| 77 |
深度挖掘IDOR漏洞；（二级IDOR越权）； |
| 78 |
应用发起外部请求时可能存在SSRF，关注这些请求； |
| 79 |
寻找关键功能API接口； |
| 80 |
寻找 hacking 方式与你不同的白帽子； |
| 81 | 尝试在不同的房间进行 hacking； |
| 82 | 尝试在完全不同的地点进行 hacking； |
| 83 | 在不同接口发现相同漏洞，分别提交； |
| 84 | 保持有一定数量的未处理漏洞； |
| 85 | 将年度赏金目标分解为月度目标； |
| 86 | 知道什么时候赏金不值得争取 -- |
| 87 | 委婉地对漏洞降级提出异议； |
| 88 | 将排行榜作为激励，而非比较； |
| 89 | 充分利用现有工具提高效率，不建议去搞其他工具； |
| 90 | 没有合适的工具时，不要害怕创造工具 |
| 91 | 尝试通过视频聊天实时沟通协作； |
| 92 | 总是问为什么事情会这样发生； |
| 93 |
合作时，不要害怕成为贡献较少的一方； |
| 94 |
合作时，不要因为贡献较多而感到不满； |
| 95 |
可以进行仲裁，但谨慎使用； |
| 96 | 慷慨地分享你的收入； |
| 97 | 为了乐趣而 hack，而不是为了薪水； |
| 98 | “(LHE）黑客或安全专家进行的实时演示”是一种特权，而不是期望！--请正确看待这种限时演示活动！ |
| 99 | 项目方是你的朋友，而不是敌人，与他们合作； |
| 100 |
平台是你的朋友，而不是敌人，与他们合作； |
如果您觉得文章对您有所帮助，还请您关注我！
原文始发于微信公众号（再说安全）：2024 漏洞赏金猎人手记：100条建议
免责声明:文章中涉及的程序(方法)可能带有攻击性，仅供安全研究与教学之用，读者将其信息做其他用途，由读者承担全部法律及连带责任，本站不承担任何法律及连带责任；如有问题可邮件联系(建议使用企业邮箱或有效邮箱,避免邮件被拦截，联系方式见首页)，望知悉。
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论