一个重要的教训：小漏洞也可能变成大问题。👀

我们采访了一位专长于漏洞利用链的网络安全研究员。 https://t.co/ykn5rJlfnc

漏洞赏金计划如何磨炼一位研究员的安全技能

来源：https://github.blog/security/how-bug-bounty-sharpens-one-researchers-security-skills/ 随着网络安全意识月继续进行，GitHub 漏洞赏金团队很高兴向大家介绍 GitHub 安全漏洞赏金计划中另一位表现出色的安全研究员：@r31n！

作为全球开发者的家园，GitHub 致力于保障数百万个项目背后代码的安全性和可靠性，而我们的漏洞赏金计划 (https://bounty.github.com/) 仍是这一承诺的基石。与外部研究员合作是提升安全性最有效的方式之一。每年，社区都会帮助我们发现并修复漏洞，让平台对每个人来说都更加安全。

安全研究领域正在迅速变化。AI 降低了入门门槛，也真正成为了提升效率的强大助力。我们在内部的各项安全计划中使用 AI，也欢迎研究员这样做 (https://github.blog/security/raising-the-bar-quality-shared-responsibility-and-the-future-of-githubs-bug-bounty-program/)。然而，优秀研究的衡量标准并没有改变：验证、可运行的概念验证，以及对实际安全影响的清晰展示。工具并不重要，工作质量才重要。本月我们重点介绍的研究员正是这一标准的典范：他们的发现经过验证、可以复现，并且证明了安全边界确实被突破，而不是仅仅推测存在这种可能。

持续达到这一水平的研究员有机会获邀加入我们的常设 VIP 计划，享受更高的赏金、更快的响应，以及抢先预览测试版产品和功能的机会。有关如何获得资格的更多信息，请访问我们的公开漏洞赏金网站 (https://bounty.github.com/)。

在网络安全意识月活动接近尾声之际，我们采访了 @r31n。这位研究员因对 GitHub Enterprise Server 的研究而闻名，曾多次发现影响重大的问题。他们提交的报告始终包含可运行的概念验证和清晰的复现步骤，帮助我们的工程团队更快地从问题分诊推进到修复。

你是如何开始从事安全研究和漏洞赏金工作的？是什么让你不断回到 GitHub 的计划中？

我开始参与漏洞赏金计划，是因为我想在日常工作环境之外，找到一种持续提升安全技能的方式。它让我接触到不同的产品、技术和架构，而这些可能是我在其他情况下不会遇到的。GitHub 是我不断回来的计划之一，因为它的攻击面实在太广了。它规模庞大、结构复杂，而且不断变化。新功能持续上线，所以它从来不会让我觉得是一个已经研究完的目标。他们也会与研究员紧密合作，赏金设置很有竞争力，周边礼品也是不错的额外福利。这就是一个让我愿意投入时间的计划。

你最喜欢研究哪类漏洞？为什么？

我其实没有特别偏爱某一类漏洞。我更感兴趣的是漏洞利用链，尤其是那些单独看起来相对无害的问题，组合起来却会造成严重得多的后果。开放重定向就是一个简单的例子。单独来看，它的影响可能有限。但如果你发现一个受域名允许列表限制、又会跟随重定向的 SSRF 漏洞，那么这个开放重定向突然就能成为一条更大利用链中的有用环节。这大概是我最享受的漏洞研究部分：找到这些联系，看着两三个彼此独立的漏洞，意识到它们可以以设计者未曾预料的方式组合起来。这需要一定的技术知识，也需要相当多的创造力。

你如何保持技能敏锐，并跟上新的漏洞趋势？

其实是多种方式的结合。安全博客、漏洞分析文章、会议演讲、概念验证、研究论文、课程。我会尝试从任何分享有价值成果的地方学习。但大多数知识，只有自己动手尝试后，才能真正掌握。我可以阅读一篇漏洞分析文章，但亲自实践一遍，会让我理解得深得多。如果我真正复现某种技术，摆弄它、尝试把它弄坏，并弄清楚它为什么会有这样的表现，这些知识才会真正留在脑海里。以后，当我在实际目标上看到类似模式时，就更容易识别出来。

哪些工具或工作流程为你的研究带来了重大改变？有没有你推荐的、鲜为人知的实用工具？

相比大型自动化工具链，我更倾向于手动调查和针对具体用途编写的小脚本。如果我发现自己在研究中反复执行同一项任务，通常就会把那个特定环节自动化。AI 对我工作方式的影响，可能超过了任何一款单独的安全工具。

即便如此，我仍然认为思维方式比工具更重要。你可能非常擅长使用某个工具，却仍然错过有意思的漏洞，因为你只是通过那个工具提供的视角来看待目标。有时，过度依赖工具反而会限制你的思路。工具会变，技术也会变。好奇心和坚持往往更经得起时间考验。因此，我并没有一款想推荐给所有人的工具。最有用的工具，通常就是能帮助我回答当前研究问题的那一个。

请介绍一下你的总体研究方法。你如何选择目标区域，又如何从“有意思的功能”走到确认发现漏洞？

我通常会先梳理应用，了解它的不同部分是如何相互配合的。我往往会把更多时间花在复杂功能、集成、信任边界，以及任何行为与其他部分略有不同的地方。经验和直觉也很重要。有些地方看起来就是更有可能暴露出有意思的安全行为。在此基础上，我通常会从数据源和汇点的角度思考，而不是从某个特定漏洞类别入手。数据源是攻击者可控数据进入应用的位置。

例如，请求参数、上传的文件、API 输入，或来自其他服务的数据。汇点则可以是使用这些数据的安全敏感操作，例如网络请求、文件访问、进程执行、数据库查询或授权决策。有意思的部分在于追踪两者之间的路径。我会查看数据如何被转换、验证，或者如何跨越信任边界传递，以及在数据到达汇点之前，这些控制措施是否充分。

我喜欢这种方法，因为它让我能够分析攻击路径，而不必把研究硬套进预先定义的漏洞类别中。有时，只有理解某个特定数据源如何影响安全敏感操作后，漏洞才会变得明显。当我理解了攻击路径、能够做出可运行的概念验证（PoC），并能解释其影响时，我才会认为这个发现得到了确认。

你会在研究中使用 AI 吗？它在哪些方面真正有帮助，又在哪些方面存在不足？

会，而且实际上用得很多，但主要是把它当作加速工具。我用它来浏览不熟悉的代码、查找调用位置、追踪数据在代码库中的流动，以及理解系统的结构和各组件之间的交互方式。在我确定漏洞后，它也能帮助我编写 PoC 脚本。

当问题足够具体时，它的表现最好。“这个应用存在漏洞吗？”通常不是一个很有用的提示。提供正确的上下文，说明你已经知道什么，再提出一个范围明确的问题，回答质量就会显著提高。这里有一点悖论：你自己越理解问题，AI 就越有用。而且，我从不把它的结论当成事实。幻觉、误报、错误假设，以及自信满满却错误的回答都很常见。所有内容仍然需要手动验证。AI 让我的工作更快。但它无法替代理解应用、培养直觉，或证明某件事确实可行。

对于在漏洞赏金研究中负责任地使用 AI，你有什么建议？

用它来提升研究质量，而不是把研究责任交给它。如果 AI 告诉你它发现了一个漏洞，并不代表你真的发现了漏洞。你仍然需要亲自复现。你应该准确理解发生了什么、哪条安全边界或哪项控制措施被突破，以及实际影响是什么。理想情况下，你应该充分理解这个问题，即使完全不用 AI，也能写出报告。构建清晰的 PoC。确保安全团队能够按步骤复现。明白每一步为什么重要。

AI 降低了开展安全研究的门槛，这在很多方面都是好事。但从各个团队如今不得不处理的大量未经验证的报告中，也能看到它的弊端。AI 应该让研究变得更好，而不只是让报告变得更多。

随着行业推出越来越多由 AI 驱动的功能，测试这些功能是否需要有别于传统 Web 漏洞的思维方式？

是的。传统漏洞仍然重要，但攻击者也可能通过这个基于概率进行决策的组件所接收的数据、指令或上下文来影响它。不过，让模型说出或做出意料之外的事情，并不一定是最值得关注的部分。更重要的问题是，这种影响能让攻击者实现什么。他们能否访问本不该访问的内容，或者让系统使用攻击者并不具备的权限执行操作？因此，我认为绝不应该把模型层面的防护机制视为唯一或主要的安全边界。你仍然需要在模型周围设置确定性的控制措施，包括正确的授权、最小权限访问、隔离和验证。周边系统与模型本身同样重要。而且，传统应用安全问题不会因为引入 AI 就消失。模型输出仍然应该被视为不可信输入。如果这些输出在缺乏适当控制的情况下进入浏览器、数据库查询、Shell 命令、Web 请求或其他下游系统，你仍然可能遇到那些非常熟悉的漏洞：XSS、SQL 注入、命令注入、SSRF 等等。我认为模型是新的，但许多危险的汇点并不是。

有什么事是你希望自己刚入门时就知道的？

学习系统，而不是检查清单。刚开始时，我很想收集大量技术、攻击载荷、工具和绕过方法的清单，然后逐一尝试。这些清单可能很有用。

我现在仍然会用它们。但理解系统如何运行，要有价值得多。它的内部逻辑。数据流。信任关系。各种假设。为什么一个组件被允许与另一个组件通信。为什么最初要设置某项限制。我还学会了，不要因为某个东西看起来安全，或者已经有很多研究员测试过，就认定它是安全的。

很多有意思的研究始于“为什么它会这样运行？”，而不是“接下来该试哪个攻击载荷？”。其中也有一些运气因素。有时，你花了好几天追查某个方向，最终却毫无收获。然后，你几乎是偶然注意到一个微小细节，它却变成了一项影响重大的发现。你无法控制运气。你能控制的是，是否持续追问足够久，从而注意到那个细节。

对于希望提交第一份有效报告的研究员，你有什么建议或推荐资源？

先扎实掌握基础，然后选择一个计划和一个目标，坚持研究一段时间。不断在不同目标之间跳来跳去，会让你很难对其中任何一个建立真正的心智模型。亲自使用应用。探索不寻常的流程。测试不同角色和权限级别。阅读文档。观察请求和响应。查看 API。实验靶场、课程、公开的漏洞分析文章、已披露的漏洞赏金报告，以及故意设置漏洞的应用，也都很有用。它们会教你漏洞通常藏在哪里，并随着时间推移，帮助你建立直觉，在其他地方识别类似情况。

我经常看到的一个错误是过早依赖工具。另一个错误是，因为显而易见的测试没有发现任何问题就放弃。工具有帮助，但它们不会替你建立心智模型。当你终于发现问题时，要多花些时间把它验证清楚。构建可运行的 PoC。让安全团队能够轻松复现。深入理解一个目标，通常比一味追求尽快找到漏洞更能让你走得远。

不做安全研究的时候，你喜欢做什么？

耐力运动，主要是公路骑行，尤其是在山里。我喜欢长距离爬坡带来的体能挑战，也喜欢在更长距离中突破自己。这也是暂时远离屏幕、到户外待一会儿的好方式。其实，爬坡在某些方面与漏洞研究很相似。你可能付出了很多努力，却看不到多少进展。有时，你完全不知道自己正在做的事是否会有结果。你只是继续坚持。而每隔一段时间，坚持就会带来回报。

有什么社交媒体主页想分享给我们的读者吗？

你可以在 HackerOne (https://hackerone.com/r31n) 上找到我。

感谢 @r31n 参与 GitHub 漏洞赏金研究员专访！向我们的漏洞赏金计划提交的每一份报告，都是一次让 GitHub、我们的产品和客户更加安全的机会。我们也始终欢迎并珍视与安全研究社区的合作。因此，如果这篇文章激发了你寻找漏洞的兴趣，欢迎通过 HackerOne (https://hackerone.com/github?type=team) 报告你的发现。

标签：

• 漏洞赏金 (https://github.blog/tag/bug-bounty/)
• 网络安全 (https://github.blog/tag/cybersecurity/)
• 网络安全意识月 (https://github.blog/tag/cybersecurity-awareness-month/)
• 安全 (https://github.blog/tag/security/)

作者

Shilpa Kumari