在这篇文章中，将回顾 Slack Bug 赏金计划的漏洞赏金计划，讨论经验教训，并为研究人员提供指导。 也希望这些信息对运行漏洞赏金计划或考虑启动漏洞赏金计划的任何其他人都有用。
计划到目前为止的情况
在 2014 年 2 月启动了漏洞赏金计划。当时 Slack 是一个小得多的产品（和团队），但致力于保护用户的安全。 漏洞赏金让各种规模的组织都能激励安全研究人员报告漏洞，而slack赏金已成为 Slack 安全流程不可或缺的一部分。 当前的漏洞赏金流程如下：
1.研究人员提交漏洞报告
2.评估报告并确定漏洞是否有效（使用第三方分类服务来评估和重现收到的报告）
3.如果漏洞有效，我们提交 跟踪和解决问题的内部票
4.解决问题
5.联系研究人员验证修复
6.奖励研究人员的发现
slack在过去三年中收集了数据，这些数据表明slack计划演变为 今天是什么。希望你发现这些测量和观察有趣且有用！与许多新的漏洞赏金计划一样，slack在发布时收到了大量报告。 事实上，仅在前四个月，就收到了近 1,000 份新报告，其中一半以上发生在第二个月。 slack为这些报告做好了准备，其响应和解决时间没有因此受到影响。
计划启动后，slack每月以比较稳定的速度收到大约 100 份入站报告。
slack感兴趣的另一个指标是响应时间，因为它提供了一种判断与研究人员沟通质量的方法。 在项目启动时，尽管slack的团队规模很小，报告数量很多，但能够非常快速地响应报告。 逐渐地，slack的平均响应时间变慢了一点，但值得注意的是这些平均值可能会受到异常值的严重影响。 中值响应时间优于平均值，因为平均响应时间因少量报告而增加，而这些报告需要很长时间才能收到响应。slack于 2015 年 4 月首次开始使用第三方分类服务，这有助于缩短并在不久之后稳定我们的平均响应时间。 slack还实施了更好的响应时间跟踪，目前的平均响应时间不到 24 小时。
来自 HackerOne 的图表显示了slack按月计算的平均响应时间
slack还没有看到每月发放的奖励价值有多少模式。Slack会在错误解决后对其进行奖励，因此错误修复的难度和优先级会影响奖励所需的时间。在程序启动后不久修复并奖励了大量错误，这与收到的报告数量大致成正比。不过，值得注意的是，一个获得巨额奖励的严重错误也可能使该指标变得不可预测。
来自 HackerOne 的图表显示了slack按月授予的总赏金
Slack学到了什么
第一次推出漏洞赏金计划时，Slack 的员工不到 20 人，而且还没有专门的安全团队（尽管确实有精通安全的工程师）。 工程和安全团队在过去三年中有了显着的发展，随着我们的成长和成熟，已经能够提供持续改进的性能。
在赏金过程中，改进了自己的流程，这反过来又提高了响应和扩展能力。 为分类流程分配了更多资源，并简化了内部漏洞赏金工作流程。
每个新错误都提供了提高效率的机会，从而加快了响应和解决时间。 三年教会了我们很多，
现在关注的一个特定领域是减少我们的平均响应时间和解决时间。
正如我们所希望的，在计划开始时收到了大量报告。 对于那些考虑启动自己的漏洞赏金计划的人来说，为这种涌入做准备是值得的，这样就不会费很大劲跟上新报告。 确保拥有处理大量有效和无效报告的资源 —— 为了程序和工程师的健康。 处理大量报告的方法有很多种 —— 使用第三方分类服务效果特别好。 我们已经将来自分类提供者的个人添加到我们在 HackerOne 上的程序中，这使他们能够访问传入的报告。 他们可以在那里评估报告并在需要更多信息时与我们联系。 他们会在错误有效时通知我们并提供问题描述，此时我们会提交内部项目。 在内部提交错误后，工程团队可以进行修复。 产品越大越受欢迎，期望收到的兴趣和报告就越多。
收到的报告中有将近一半是“不适用”，这适用于无效问题、非安全问题或超出我们计划范围的报告。“信息性”报告可能包含一些有用的信息，但不会影响客户的安全。“重复”报告包含以前报告的问题，“已解决”报告包含根据该报告修复的问题。 可以在此处找到有关不同报告状态的更多信息。
分流服务一直是我们项目成功的宝贵资产。 它使我们能够每年处理数百个报告，同时仍能及时响应、重现和修复错误。 安全团队能够专注于查看错误直至解决，而不会被提交的总量所淹没。
一个稍微不那么量化但仍然重要的考虑因素是研究人员和内部开发人员的整体幸福感。 作为一个安全团队，我们必须在不同的利益相关者之间保持平衡，以确保我们的产品安全。
为研究人员提供了一种超越金钱奖励的激励让研究人员开心，让他们告知我们可以修复的漏洞。 平均响应时间指标作为研究人员满意度的替代指标 一般来说，与研究人员保持快速沟通让他们知道安全团队关心他们的报告并认真对待安全问题。 虽然我们总是相当及时地修复问题，但当解决问题的时间比预期的要长一些时，我们发现让研究人员了解这一进展往往会增加他们的耐心。
让我们的工程师开心有助于营造良好的工作环境，让我们一起努力解决错误。 当我们收到漏洞报告时，我们会与我们的工程团队进行快速而简洁的沟通，以防止团队不知所措。 在提交内部问题时，我们将错误分为四个严重级别之一。使用离散的错误严重性可确保所有漏洞都根据其严重性及时得到解决，同时允许工程师有效地分配他们的时间。
对外部研究人员和内部员工都有同理心，对于鼓励安全团队的长期善意大有帮助，这对于成功的漏洞赏金计划至关重要。
给研究人员的提示和技巧
综上所述，我们想为希望在 Slack 中寻找漏洞的研究人员（包括新老）提供一些指导。 在我们的漏洞赏金计划范围内，这些关于搜索位置和漏洞类型的建议可能是最有趣的。 Slack包含许多部分，以复杂的方式进行交互。 下面的列表重点介绍了其中的几个，解释了它们是什么、它们使用的技术以及与它们最相关的漏洞类型。 我们希望这能让我们更深入地了解要寻找的内容，以及哪些领域最容易产生漏洞。狩猎愉快！
Slack API —api.slack.com
它的作用：Slack 应用程序（网络、桌面、移动）都与此端点通信，使用 Slack API 构建的应用程序和集成也是如此。 该 API 包含管理 Slack 团队、在该团队中进行通信等核心功能。
要查找内容：身份验证绕过、权限绕过、信息泄露
它运行在什么平台上：PHP、MySQL、Apache、HHVM、Cloudfront
Slack web app — my.slack.com
它的作用：这是在浏览器中使用 Slack 时与之交互的内容。 许多请求和功能与 API 和 WebSocket 端点交互，但也有一些独特的 Web 体验功能。
要查找的内容：Web 应用程序缺陷、XSS、CSRF、身份验证绕过
它运行在什么平台上：PHP、MySQL、Apache、HHVM、Cloudfront、HTML/jQuery/Handlebars
Slack Desktop
它的作用：这是在桌面 (Windows/Mac/Linux) 上使用 Slack 应用程序时与之交互的内容。 许多请求和功能与 API 和 WebSocket 端点交互，但也有桌面体验独有的功能。
要查找的内容：身份验证绕过、权限绕过、信息泄漏
它运行在什么平台上：Electron 前端，它与 API/Web 后端通信
Slack mobile apps
它们是做什么的：这是一套适用于 iOS、Android 和 Windows Phone 的移动应用程序。 它们运行本机移动操作系统代码并连接到 API 端点和 WebSocket 连接到 WebSocket 端点。
要查找的内容：移动应用程序问题、敏感信息的不安全存储，例如硬编码的秘密或令牌
它运行在什么平台上：每个操作系统的本机框架（Java、Objective-C、C#）
Websocket endpoints
它的作用：Slack 通过其实时消息服务器（RTM API）传递消息。 这些是通过 WebSockets 传送到我们后端的实时通信。
要查找的内容：身份验证绕过、权限绕过、信息泄漏、任意团队或用户的消息传递
它运行在什么平台上：Java、Go、WebSockets
我们关心的其他事情
在所有产品领域，我们总是对以下错误非常感兴趣：
● 绕过私人消息安全
● 绕过团队隐私
●通常绕过访问控制
