BUG-狩猎渗透测试实用指南-二-

BUG 狩猎渗透测试实用指南（二）

原文：annas-archive.org/md5/f7f6775644a2e8d2d0d52a4afb4d407d

译者：飞龙

协议：CC BY-NC-SA 4.0

第九章：框架和应用程序特定的漏洞

识别框架或应用程序特定的漏洞，包括已知组件漏洞（通过 CVE 标识符来识别，我们稍后会讨论）是非常棘手的。

这也是所有漏洞悬赏计划的普遍规定，即公司不会对相同的漏洞进行两次奖励——第一个披露漏洞的研究员才会获得奖励。这与公司通常不会奖励在原始零日漏洞发现后两周内已经公开披露的漏洞是密切相关的（就像所有公司一样，他们需要时间来部署补丁），而且他们对第三方库中的供应商级漏洞不感兴趣。这看起来可能是浪费时间，除非我们考虑到两个重要的因素。

采用的成本很低。由于已知的组件漏洞是显而易见的，因此构建一个工具来可靠地发现这些漏洞要比处理架构或应用程序逻辑中的不太明确的弱点更容易，后者需要手动通过用户界面逐步检查。正如我们在第三章《准备参与》中举的例子一样，我们为检测和报告客户端漏洞（如不安全的 jQuery 库）编写了一些简单的脚本，这是一项轻量级的工作，可以融入到任何有权限访问客户端源代码的环境中。

了解安全态势非常重要。安全态势这个术语是应用程序或网络防止、检测和响应攻击的总体能力的简称。如果你打开诊断工具，立刻发现框架、语言版本或供应商服务中存在多个关键报告漏洞，那就能告诉你很多关于该公司安全实践的信息。如果有这么多容易解决的问题，那么他们的漏洞悬赏计划还年轻吗？他们是否有成熟的安全生命周期管理政策？如果从已发现的漏洞中能找到攻击场景的路径——太好了！——即使不是这种情况，这些信息也是有价值的，因为它们可能暗示着潜在的威胁。

关键在于攻击场景。这是最本质的一点：面对有效的攻击场景时，大多数 KCV 指南都要被抛到一边。公司不愿仅仅为了改善 jQuery 攻击面而贡献一个补丁——那会花费大量时间来验证、沟通和修复最终属于其他组织的漏洞。但是，如果你能说服他们这个漏洞影响到他们的业务，就可能引发改变（贡献补丁、更新组件、切换到另一种解决方案）并触发奖励。

本章将解释如何：

• 将已知组件漏洞扫描集成到你的基于 Burp 的工作流中

• 使用工具查找像 WordPress、Django 和 Ruby on Rails 这样的软件中的应用程序特定问题

• 从发现、验证到提交一个组件特定的漏洞

技术要求

在这一节中，我们将与 Burp 及其一些扩展合作，自动设置 KCV 检测。我们还将依赖我们常用的浏览器设置作为 Burp 代理。我们还将使用 WPScan，既作为 CLI 工具，也作为 Burp 扩展。

WPScan CLI 提供了多种安装选项。我们将再次使用容器软件 Docker，从自定义执行上下文中下载并运行wpscan CLI，这个上下文打包了所需的一切。Docker 使我们可以将此工作流移植到任何可以安装 Docker 的地方，这意味着我们不需要担心操作系统特定的行为。而且，因为 Docker 会缓存 WPScan CLI 镜像，所以我们可以使用它，性能损失仅比本地安装略大。

假设已经安装了 Docker，若要拉取最新的 WPScan CLI 镜像，只需运行以下简单命令：

docker pull wpscanteam/wpscan

然后，你拥有所有必要的依赖项，可以使用docker run命令启动wpscan CLI。这里有一个直接来自 Docker Hub 镜像文档的示例单行命令：

docker run -it --rm wpscanteam/wpscan -u https://yourblog.com [options]

为了测试目的，WPScan 背后的同一个团队还提供了一个故意包含漏洞的 WordPress 安装，它同样运行在 Docker 容器中。要在本地构建该镜像，首先克隆 GitHub 仓库（github.com/wpscanteam/VulnerableWordPress），然后进入其根目录。接着，运行以下命令：

docker build --rm -t wpscan/vulnerablewordpress .
docker run --name vulnerablewordpress -d -p 80:80 -p 3306:3306 wpscan/vulnerablewordpress

现在，你应该有一个准备好在localhost:80进行设置的 WordPress 安装：

已知组件漏洞和 CVE - 简要回顾

公共漏洞和暴露（CVE）系统自我描述为一本字典，提供已公开披露的漏洞和披露的定义。它的目标是让跨团体和技术共享网络安全相关数据变得更加容易，理解开放协调的好处大于公开广告有效攻击的风险。值得记住的是，CVE 是一种将漏洞数据库连接起来的方法，而不是一个漏洞数据库本身。也就是说，你通常会发现 CVE ID 与集成到检测已知漏洞的工具中的 CVE 信息页面有链接。CVE 条目甚至已集成到美国国家漏洞数据库中。

CVE ID 的结构直接明了：该标识符由年份加上四位数（或更多）整数组成。直到 2015 年初，CVE 标识符只能有最多四位数的唯一整数，但由于这限制了每年可分配的 ID 总数为 9,999 个，因此必须扩展，现在可以是任意长度。

除了其 ID 外，每个 CVE 通常还附带某些信息：

• 指示 CVE 是否具有条目或候选状态

• 漏洞或曝光的简要描述

• 任何适当的参考资料（例如，来自 OVAL-ID 的漏洞报告、警报）

OVAL-ID 是区分 OVAL 定义的唯一标识符。来自 OVAL 网站：

OVAL 定义是用开放性漏洞和评估语言（OVAL®）编写的标准化、机器可读的测试，用于检查计算机系统中软件漏洞、配置问题、程序和补丁的存在。

OVAL 定义测试，如 CVE，旨在协调一个开放、透明的系统，用于标准化渗透测试词汇，并允许更多的共享，以及道德黑客和他们的工具之间的更多共享。

这个快速介绍/复习应该在下次使用任何利用 CVE 作为主要安全参考的工具时派上用场。

WordPress – 使用 WPScan

根据 WordPress 的说法，他们的框架支持所有网站的 31%。这个面向一切的开源 CMS 是一个巨头，为业余爱好者和商业网站提供基本引擎，从你叔叔的博客到白宫的登陆页面。因此，它是一个极具吸引力的目标，供渗透测试人员和黑客随处可见。WordPress，带有其众多插件和配置选项，提供了一个庞大的攻击面，通常由技术经验有限的管理员管理，可能难以保护。每个编写不良的插件、WP 核心的猴子补丁或古老的安装都可能成为攻击者入侵或破坏 WP 站点所需的立足点。

WPScan 功能打包在几种不同的工具中。对于我们的目的，最重要的是容器化的 Docker 命令行界面和 Burp 扩展。

将 WPScan 作为 Docker 化的 CLI

将 WPScan 作为 Docker 化的 CLI 使用的优势在于，我们仍然可以充分利用 CLI——允许我们将脚本嵌入到更大的自动化设置中——而不必担心依赖管理问题，比如保持我们的 Ruby 版本最新。我们甚至可以编写一个简单的包装器，围绕docker run命令，这样每次使用脚本时就不需要输入太多样板内容。

例如，如果我们创建一个名为wpscan.sh的 shell 脚本，并调用我们的 Docker 命令，传递"$@"字符，以便将所有标志和命令行参数通过 shell 脚本传递给docker命令，我们得到的结果如下：

#!/bin/sh

docker run -it --rm wpscanteam/wpscan "$@"

然后，我们可以使用chmod使我们的包装器脚本可执行，并将其symlink到我们的/usr/local/bin，这样我们就可以在我们的$PATH中访问它：

chmod u+x /Full/path/to/wpscan.sh
sudo ln -s /Full/path/to/wpscan.sh /usr/local/bin/wpscan

完成。现在，我们可以通过我们的wpscan包装器调用 CLI 脚本，使用与安装 WPScan 作为 gem 时相同的语法，但不需要跟踪安装 gem 的 Ruby 版本，也不需要确保安装了ffi或其他依赖库：

wpscan --help

通过传递--help标志来检查我们的选项，以下是我们看到的内容：

现在，为了测试这个功能，让我们启动我们的脆弱 WordPress 实例。如果你按照了我们技术要求部分的说明，你应该已经有一个准备好在localhost:80上设置的 WP 实例了。选择你希望使用的语言后，你应该会看到一个用于填写基本站点信息的表单（站点标题、管理员超级用户名、通知邮件等）：

填写完毕后，你将被重定向到一个成功页面：

第一次登录后，导航到普通的localhost:80，查看你 WP 站点的实际主页：

请记住，你不能从wpscan中 ping localhost:80，因为它是从 Docker 容器内执行的。为了将我们的 Docker 化 WordPress 实例提供给 Docker 化的 WPScanning 服务，我们需要使用运行 WordPress 的 Docker 容器的 URL。

我们可以通过使用docker ps来查找运行 WordPress 的 Docker 进程的容器 ID，然后运行docker inspect <CONTAINER_ID>返回包含 IP 地址的 JSON 信息。对于我们来说，这个 IP 地址是172.17.0.2。接着，我们运行此命令扫描我们脆弱的 WordPress 站点。如果我们针对的是一个公共互联网站点，我们可以跳过这一步：

wpscan --url 172.17.0.2:80

运行上述命令后，这就是我们扫描的输出结果：

你可以立刻看到一些值得跟进的发现——robots.txt 中的有趣条目：http://172.17.0.2/super-secret-admin-page/看起来特别有意思，考虑到那个诱人的 URI。但如果我们继续查看漏洞列表，我们将能看到几个配置文件。我们寻找认证凭据、隐藏的目录和其他有用的东西，导航到一个暴露的配置文件，wp-config.txt：

我们找到了我们想要的东西！通过站点级别的管理员密钥和所有的盐哈希，我们已经发现了进入王国的加密密钥。

Burp 和 WPScan

使用 Burp 扩展方法应用 WPScan 的一个优势是，它使得将扫描器集成到更大的 Burp 工具集中的过程更加简便。例如，如果你依赖于手动标记页面为有效范围，那么你可以让 WPScan 利用这些信息，确保你在整个渗透测试过程中始终聚焦目标。

设置 WPScan 与 Burp 集成非常简单。你首先需要做的就是前往 BApp Store 下载扩展：

你也可以通过手动安装弹窗选择扩展文件（可以是 Java、Python 或 Ruby 语言）来手动加载扩展：

你可能发现需要为扩展安装相应的环境。设置每种语言都很简单：以 Python 为例，我们访问 Jython（一个在 Java 中实现的 Python 解释器）的主页并按照安装说明进行操作。然后，在扩展选项卡中的“选项”部分，我们可以添加 Jython jar 文件的路径：

现在，我们可以从 BApp Store 下载 WPScanner 扩展。只需点击安装按钮就能轻松完成：

安装完成后，我们应该能看到一个 WordPress 扫描器标签。如果点击它，我们将能够看到设置和输出面板，准备好进行分析：

WPScanner 扩展依赖于 Burp 在你使用代理浏览器浏览网站时进行的被动分析。在点击几个页面、查看我们的示例文章并打开我们脆弱的 WP 实例的评论提交字段后，我们可以看到问题列表已经被多个漏洞填充：

浏览问题列表时，我们可以看到每个类别的简短描述，并且有多个指向博客、GitHub 拉取请求和安全参考的链接，提供更多信息。我们还会看到漏洞路径、严重性以及对发现结果的信心等级。

浏览这个列表时，我们可以看到几种不同的 XSS 类型。进一步调查后，让我们尝试在评论提交字段中测试与 svg 标签相关的漏洞，探查网站内容清洗功能的另一部分——我们当然知道 WP 实例是脆弱的，但我们仍在进一步确认漏洞的定位和性质。以下是我们的代码片段：

<svg/onload=alert(document.location.origin)>

提交后，我们看到页面暂停了一会儿，然后最终加载完成。

我们的测试取得了成果。尽管在这种情况下我们知道只要深入挖掘一定能找到问题，但像 WPScan 这样的工具可以提供有价值的、特定于应用程序的背景信息和后续调查线索，而无需添加一个繁重的新工具或难以集成的测试系统。

Ruby on Rails – Rubysec 工具和技巧

有几种分析 Ruby 和 Ruby-on-Rails 应用程序的方法，其中一些是特定于 Rails 的，另一些可以更广泛地应用于类似的应用程序（例如，也符合 RESTful、MVC、CRUD 导向、主要在服务器端运行的应用程序等）。

利用 RESTful MVC 路由模式

由于 Rails 强烈倾向于将 RESTful MVC 模式应用于 CRUD 应用程序，URL 路由结构通常很容易直观地理解。理解 /resource/action 和 /resource/{identifier}/action 模式使攻击者能够通过简单的观察推断出像 /users/{identifier}/update 这样的潜在危险路径。

检查特定弱点的版本

作为一个应用框架，Rails 和所有流行软件一样，经过了多次安全更新，解决了诸如在 Active Record 中处理 SQL 注入，或者扩展 CSRF 保护方案以涵盖更多基本请求类型等关键问题。但由于构建 Rails 应用程序的门槛很低，而且语言和框架都非常适合提高生产力，Rails 应用程序往往能够快速搭建。而且由于 Rails 是一种常见的小型企业/原型开发解决方案，尽管经常被用于成熟的生产服务中，仍然存在大量的遗留 Rails 代码。这种快速搭建的架构与对长期使用的期望相结合，再加上 Rails 脚手架的即插即用特性（仅通过几个约定命令就可以创建完整的 CRUD 应用程序），意味着 Rails 特别容易受到由于配置错误或不安全默认设置所导致的漏洞的影响。

测试 Cookie 数据和身份验证

Rails 使得存储潜在的安全信息为 Cookie 变得非常简单，因此更容易通过编码但未加密的 Cookie 泄露潜在信息。

Django – Python 应用的策略

Django 作为一个常用的框架，用于快速构建 CRUD 风格的应用程序，并且已经在一种为开发者生产力设计的动态类型语言中成功实现，自然会遭遇与 Rails 相同的许多陷阱，并且存在许多相同的弱点。Django 对 RESTful、以 MVC 为中心的 URL 路由有很强的偏好，因此允许进行前面一节中讨论的相同的 URL 攻击。尽管如此，Django 默认提供了很多出色的全局保护，能够有效防御诸如 CSRF、XSS 和注入攻击等常见漏洞。

检查 DEBUG = True

这是一个常见的错误，尽管看起来是个“拍脑袋”的失误——在生产环境中留下 Django 开发者级别的日志记录。以启用 DEBUG 设置发布应用会导致一些问题，包括暴露敏感页面或数据的全面错误追踪信息。如果您怀疑目标 Django 应用已启用 DEBUG，可以尝试生成错误以触发有害的追踪信息显示。启用 DEBUG 设置是非常常见的，甚至在今年早些时候，一名研究人员进行调查，仅用一周时间就发现了 28,165 个启用了该设置的 Django 应用（www.bleepingcomputer.com/news/security/misconfigured-django-apps-are-exposing-secret-api-keys-database-passwords/）。如果看起来通过调试信息访问造成的危害似乎很有限，考虑到 2018 年，一名研究人员能够利用来自 Facebook 的不安全 Sentry 服务器的调试信息获得远程代码执行（RCE）。该漏洞的奖励是 5,000 美元——这是较低的金额，因为服务器是沙箱化的，无法访问用户数据（blog.scrt.ch/2018/08/24/remote-code-execution-on-a-facebook-server/）。

探测管理页面

Django 自带一个默认的管理页面，通常会被第三方插件或其他与管理员相关的扩展所取代。如果默认的管理页面被忽视，或者管理员集成不完整，它可能会提供一个有价值的攻击面供测试和探索。

总结

本章介绍了 CVE 漏洞识别系统的基础知识，如何围绕发现 WordPress、Ruby on Rails 或 Django 相关的漏洞构建工作流程，以及为何尽管存在各种警告，已知漏洞检测仍然值得纳入您的安全实践。通过本章，您应能更好地理解特定应用漏洞在安全生态系统中的作用，并有信心在适当的情况下将特定应用的测试流程集成到基于 Burp、脚本或其他任何工作流程策略中。

在下一章中，我们将介绍每个报告中应包含的关键信息、可选信息、包含详细重现步骤的重要性以及如何编写一个好的攻击场景。

问题

1. CVE 代表什么？它是什么？

2. 什么使得 WordPress 成为黑客的一个有吸引力的目标？

3. 使用 CLI 而不是 Burp 扩展来实现 WPScan 功能有哪些优势？反过来又如何？

4. 找到 Ruby on Rails 特定漏洞的好方法有哪些？

5. 使用 Docker 作为渗透测试工具有哪些优势？

6. OVAL 代表什么？什么是 OVAL 定义？

7. 测试 Django 应用程序时，您应该留意哪些问题？

进一步阅读

您可以在以下链接中了解我们在本章中讨论的部分主题：

• WordPress 官方网站: wordpress.org/

• CVE 常见问题: cve.mitre.org/about/faqs.html.

• OVAL 主页: oval.mitre.org/repository/about/overview.html.

• WPScan 主页: wpscan.org/.

• OWASP Ruby on Rails 备忘单: www.owasp.org/index.php/Ruby_on_Rails_Cheatsheet.

• 官方 Rails 安全指南: guides.rubyonrails.org/security.html.

第十章：格式化你的报告

在本书中，我们根据每个漏洞深入探讨的内容格式化了样本报告。理想情况下，你应该已经从那些频繁出现在报告中的数据点中获得了哪些信息是重要的感觉，但在本章中，我们将更详细地讨论最重要的提交组成部分。我们将讨论什么可以增加获得奖励的机会，什么可以提升奖励的严重性（以及其支付金额），哪些信息是可选但有用的，哪些只是噪音。我们还将讨论你可以用来编写报告的原则，这些报告清晰、易于重现漏洞，并且包含详细、引人入胜的攻击场景，这些将使内部安全团队迫切要求修补漏洞（从而触发你的奖励）。

对一个优秀报告示例中个别内容、场景和格式有深入了解，可以帮助你塑造你的渗透测试实践。随着你不断学习、提高技能，成为更好的研究人员，你可以采用与最终目标一致的新工具、策略和方法，创造出那种完美的报告，那个会立即在最高适当严重性级别获得奖励的报告。

本章将涵盖以下主题：

• 重现漏洞——如何审核你的提交

• 关键的资料——你的报告需要什么

• 最大化你的奖励——那些能带来回报的特性

• 示例提交报告——在哪里查找

技术要求

本节将提供文本中的所有必要报告示例。除非你想阅读进一步阅读部分的部分材料，否则甚至不需要浏览器。

重现漏洞——如何审核你的提交

如果内部安全团队无法通过重现你的 PoC 来验证你的发现，就很难获得奖励。你可能伪造或模拟了发现，或是在某个已修补的边缘条件下创建了它，这些情况并不代表重大威胁。

确保你的漏洞是可重现的最简单方法是，从一开始就自己亲自练习重现它。如果是手动发现的漏洞或像 Burp Intruder 这样的半自动化工具，你能可靠地重现它吗（如果存在竞争条件，可能需要尝试几次才能获得正确的样本大小）；如果是通过扫描器严格控制的漏洞应用，你能手动重现它吗？仅仅再次运行扫描并看到相同的结果是不够的，如果你不能手动重现自动化漏洞，它会被视为无效提交。

编写一系列可重现的操作步骤很容易，只要你强调正确的内容。你应该注意：

• 使用清晰的编号步骤。

• 为每个步骤添加简洁的描述和应用程序状态截图。

• 注意应用内的副作用，即使它们是功能性问题而非直接可利用的（例如，用户信息弹窗立即打开并关闭），因为它们可能会提示回应开发者你没有察觉到的问题，并告知他们自己走在正确的轨道上。

• 包括细微的区分（点击提交按钮与高亮提交按钮并按回车键）以尽可能提供有用的上下文，而不至于过度。一个好的问题是：你是否在将模糊的描述改写为尽可能具体的内容（好），还是在打字时胡乱堆砌术语和信息，试图把每个信息点都扔到墙上，看哪些能粘住（不好）？

• 除了可重复性操作流程本身的描述质量外，提供关于你的环境的（有用的）上下文也非常重要，这些上下文可能比方法论部分更深入。例如，在方法论部分，你可能会说我导航到X页面并将Y输入框填入Z值，然后使用某某工具。一些额外的、有用的上下文信息可能包括你的浏览器类型、版本，以及任何适用的扩展或配置，这些可能使其与其他环境有所区别。不必要的上下文可能是，你的系统上还安装了一个与任何测试结果完全无关的游戏。

• 了解你的受众。这个建议与我们讨论的正确区分和添加适当技术细节的内容重叠并有所延伸。当你联系一个内部安全团队时，回应者将取决于组织的规模。在一个小型创业公司，你可能会得到一个开发者（甚至是技术创始人）来回应你的报告。在一个更大、更多企业化的公司中，会有专门的安全工程师，甚至可能有一个正式的网络运维中心（NOC），它本质上是任何网络/数据中心的神经中枢。这意味着，虽然你不能依赖于你的报告被安全专家阅读，但最终你的报告会被传递给负责编写补丁的人，而且它应该包含他们开始调试所需的技术细节。这意味着，如果有一个描述性的错误堆栈追踪，例如——尽管它不会给你带来奖励——你仍然可以通过将其包括在内，帮助贡献的开发者更轻松地解决问题。

这些建议虽然简单，但如果付诸实践，将会提高你提交报告的质量。

让我们看一个示例报告，假设在本节的上下文中，我们正在编写一个我们在一个流行的链接聚合论坛（比如 Reddit 或 Hacker News）评论区发现的持久性 XSS 漏洞。假设我们已经填写了漏洞的基本统计信息（将在我们的关键信息部分中介绍），并添加了任何适当的上下文信息（在这种情况下，XSS Payload 将会有用），现在我们准备编写重现该问题的步骤。我在斜体中添加了一些简短的注释，以便您区分我的评论和示例报告文本：

1. 导航到某个帖子页面（www.somesite.com/the/location/of/the/vulnerable/thread.html）并点击“添加评论”按钮。包括一个特定的 URL 位置是关键——即使您已经在报告的其他部分添加了该数据。具体描述您在 UI 中执行的操作（点击“添加评论”按钮）虽然看起来比提交表单这样的描述显得冗长，但仍然非常有用。

2. 在弹出的textarea输入框模态中，输入以下恶意 XSS 代码片段。然后，点击提交按钮：

<svg/onload=alert(document.location.origin)>

确保在每次更改应用程序状态时都描述用户体验。引用您正在测试的攻击面中直接涉及的前端组件，将帮助开发人员/工程师重现整个输入链，从前端提交到（在这种情况下，失败的）后端验证。

1. 当代码成功提交后，您应该会被重定向回您添加评论的帖子页面。您应该能看到脚本已执行，alert() 弹出漏洞的 URL 位置。

使用document.location.origin可以向接收我们提交的团队证明 XSS 脚本正在一个活跃的、非沙箱化的生产实例上执行，且可能会影响实时用户数据。我们还附上了一张显示漏洞实际执行的截图。如果您想为每个单独的步骤附上截图，那也很好，这可以揭示出可能对应用开发者有兴趣的标记文档痕迹，但最关键的状态是捕获漏洞的 PoC 执行。

关键信息 – 您的报告需要哪些内容

尽管报告信息会根据漏洞的类型有所不同（您可能会遇到已编码但可解码的敏感信息，这意味着您无法提交任何 Payload 信息），但总有一组通用的字段是您需要填写的：

• 漏洞的位置（URL）

• 漏洞类型

• 何时发现该漏洞

• 如何发现该漏洞（自动化/手动，工具）

• 如何重现该漏洞

• 如何利用这个漏洞

本书中我们已经展示了各个领域的例子，但其中有两个特别值得一提。位置 URL 很明确，类型、时间、方法以及所有直接信息也都很清晰，但确保报告中的漏洞可以重现，并且有一个令人信服的攻击场景，详细描述它造成的可怕后果，且漏洞未被修复，将是确保你的漏洞获得奖励并获取最高可能奖金的关键。

除了必要的信息、完整的重现路径和有说服力的攻击场景外，你还可以包括一些额外的数据，其中有些是特定于漏洞的，有些则是可选的但能提供启发性的信息。

如果你报告的漏洞包含有效载荷，那是很重要的。包括指向 OWASP、NIST 和其他受尊敬的安全组织参考页面的链接，也是清晰传达漏洞性质和类型的有效方式 —— 例如，直接引用 OWASP 页面来描述某种 XSS 类型（www.owasp.org/index.php/Testing_for_Reflected_Cross_site_scripting_(OTG-INPVAL-001))，立刻显示你对漏洞的性质非常熟悉，理解其基本原理。如果你写的是由已知组件漏洞导致的攻击场景，确保你包含其 CVE ID 以及漏洞页面的链接。

你的攻击可能会使某些平面文件变得可访问，或者它们可能作为漏洞的证据被包含在内（例如，也许你在服务器上发现了一个包含真实凭证值的旧配置文件，并希望将其作为提交的一部分）。尽管你可以将文件作为证据发送，但请考虑你应该仅发送相对安全的文件，如 .txt、.json、.xml 或其他常见的数据类型。没有哪个安全团队愿意冒着意外执行 .exe 或其他潜在恶意软件的风险。如果可能，尽量只包含文件中相关的部分。

最大化你的奖励 —— 那些能带来报酬的特点

如果你想了解某个漏洞可能带来的奖励，查看你参与的赏金页面以及 Bugcrowd 创建的漏洞评级系统 漏洞评级分类法（VRT）是很有帮助的。VRT (bugcrowd.com/vulnerability-rating-taxonomy) 试图以一种系统化的方式评估漏洞的严重性，从而为研究人员、开发者和管理者提供一个共同的参考框架。VRT 还与另一个共同威胁度量系统兼容，即 通用漏洞评分系统（CVSS）——VRT 可用于计算 CVSS。理解 VRT 有助于你将精力集中在那些能为你带来最大价值的漏洞上。

撰写一个能为漏洞严重性提供适当补偿的赏金报告，要求你能让审查你提交的安全团队重现你的攻击，同时——同样重要的是——你需要写一个有说服力的攻击场景。要写出一个有说服力的攻击场景，你需要具备以下几点：

• 具体性：你的攻击场景应该考虑到具体种类的漏洞和利用方式，并且如果可能的话，提到一个具体的部分，而不是泛指类型（例如用户名，而不是 auth 数据——除非这是你收集的多个信息的最佳描述）。始终标明应用程序的版本，包含你能够访问的任何元数据等。

• 现实的严重性：你的漏洞可能不会导致每个托管区域崩溃，或者使公司的基础设施瘫痪，但它会给员工、客户、投资者以及任何被波及的人员带来严重风险。你应该能够定义一个现实的攻击场景（它不能耗费过多资源或无限时间），但应该会导致不可接受的数据丢失、数据窃取、性能下降或基本功能丧失，因为这些都属于明显的危机。

• 正确术语：使用正确的术语（技术词汇、缩写、适用的比喻）可以确保审查你提交的安全团队相信你的攻击场景是可信的，因为你本身是可信的。你不希望因为以笨拙、混乱或误导的方式描述可能是合法发现的内容，而错失奖励机会。能够利用诸如 远程代码执行（RCE）和 PoC 等常见术语至关重要。

• 文档：这是报告！（对吧？）其他部分是相关的考虑因素，但你能附上更多关于场景本身的信息会更好。这可能意味着截图、文件或在发现过程中副作用生成的产物，甚至是某些数据——虽然还没有达到主动利用的路径，但能证明，例如，你可以打印出敏感的 cookie 信息，而不实际泄露或滥用这些信息。

牢记这些原则，让我们来看一个写得不太好的报告示例，并将其与一个更强的尝试进行对比，假设我们正在提交关于之前讨论的相同漏洞——持久性 XSS（跨站脚本攻击）——的报告，该漏洞在一个热门在线论坛的评论区被发现。

• 弱点：利用这个漏洞，某人可以通过在一个热门讨论串中插入恶意脚本来攻击网站的用户社区。

• 更强的：攻击者可以通过在一个热门讨论串的评论中插入恶意 JavaScript 代码片段来利用持久性 XSS 漏洞，这段代码可能通过将管理员账户的 cookies 发送到监听服务器来窃取这些 cookies。

注意，第二个、更强的攻击场景仍然简洁——保持场景详细但简洁是很重要的。它使用了具体的术语而不是笼统的词汇（JavaScript，而不是脚本；评论中的热门讨论串，而不是热门讨论串中的评论；管理员账户 cookies，而不是其他不具体的说法），并列出了一个可能的风险（窃取管理员账户 cookies），这个风险远比简单的关于恶意脚本的模糊描述要具体，代表了一个具体且有害的场景。这个场景也符合漏洞的严重性：XSS 不会像某些科幻超级蠕虫那样摧毁全球金融系统，但它可以对个体用户造成很大伤害。

示例提交报告——查看地点

我们为每个讨论过的漏洞写了一个示例报告，并在本章中使用了一些例子来说明某些要点。希望这为你提供了关于报告所需内容和写作方法的坚实基础。

学习做任何事情的最佳方法之一是将你的实践建立在其他成功研究人员的经验上，并看到他们的专业技能在实际中的运用，而不是单纯地接受它作为传承下来的智慧。阅读足够多的成功报告（那些已经获得奖励的报告），你会开始看到其中的共同主题，以及支撑这些研究者成功职业生涯的实践方法。以下是一些资源，展示了这些经过实战检验的报告，它们为作者赢得了声誉和奖项。

Hackerone Hacktivity

Hackerone 的 Hacktivity 部分(hackerone.com/hacktivity)是一个漏洞报告提交的档案库，采用类似 Reddit 的投票系统，社区可以对特别有趣的报告进行点赞，从而将其展示在该部分的首页：

由于报告只有在赏金计划经理同意后才会公开，你可以看到许多报告是灰色显示的。但那些可见的报告不仅展示了参与公司在安全文化方面的情况，还提供了成功研究人员日常渗透测试的过程。

漏洞实验室档案

我们首先讨论了漏洞实验室，类似于 Hackerone，在优秀漏洞悬赏研究员社区中的作用。除了是发现新漏洞悬赏计划的绝佳来源外，漏洞实验室还维护着一个档案（www.vulnerability-lab.com/），其中包含了所有在其平台上提交的漏洞报告（这些计划的所有者也同意公开披露这些漏洞）：

漏洞实验室档案的一个最有价值的元素是，每份报告按类型组织——无论是 Web 应用、移动应用还是一般的供应商漏洞——使你能够轻松地深入了解与你的实践最相关的报告。

GitHub

GitHub 的漏洞悬赏页面（bounty.github.com/）不仅展示了所有参与其计划的安全研究人员的排行榜，显示了贡献者的用户名、个人资料图片和 Twitter 用户名，还提供了一些关于他们发现的漏洞的基本信息——漏洞的类别、子类别，以及一个简要的解释段落，说明漏洞是在哪里发现的以及其影响的服务：

尽管这些报告很有价值，但它们没有提供前两组漏洞报告通常会展示的技术细节（如代码片段、截图和相关文件附件）。

摘要

本章讨论了编写漏洞报告提交的细节，我们可能在攻击章节中略过了这些内容，解释了每份报告应包含的关键信息、可选信息、包含详细重现步骤的重要性、如何编写好的攻击场景（包括示例）、哪里可以找到实际的生产漏洞报告提交等内容。基于我们在漏洞演练章节中创建的示例提交报告，并结合更多关于什么样的报告值得获得奖励的高层讨论，本章将为你提供前进所需的一切，帮助你编写高质量的报告，从而为你发现的漏洞赢得最大奖励。

在下一章中，我们将讨论一些超出我们直接使用的工具和方法。

问题

1. RCE 代表什么？

2. 在报告中，关于你的发现，什么样的背景信息是有用的？

3. 每份报告中应该包含哪些数据的几个例子？

4. 什么是漏洞评级分类法（VRT）？CVSS 又是什么？

5. 为什么确保漏洞是可重现的很重要？

6. 什么区分了一篇写得好的攻击场景与一篇平淡无奇的攻击场景？

7. 有哪些好的资源可以用来查找实际漏洞报告提交的例子？

8. 在你的漏洞报告中，哪些类型的文件附件值得包括？

深入阅读

你可以在以下链接中找到更多我们在本章讨论的主题：

• GitHub 漏洞赏金常见问题: bounty.github.com/index.html#faqs.

• 漏洞提交方法: www.bugcrowd.com/writing-successful-bug-submissions-bug-bounty-hunter-methodology/

第十一章：其他工具

本书中，我们介绍的工具和工作流程都是根据效率、成本、专业意见和个人偏好综合选择的。但在我们讨论的简短列表之外，仍然有许多安全工具可以利用。

本章将讲解如何评估是否采用新工具，同时提供其他有用的 Curate 软件、网站、社区和教育资源的简单概述。我们将涵盖从程序（如扫描仪和 Burp 扩展）到众包攻击代码片段数据库（如 SecLists）的各类内容。

本章将涉及以下主题：

• 评估新工具

• 付费版与免费版

• Nikto、Kali、Burp 扩展等工具的简要概述

技术要求

本章包含了一些技术依赖，具体取决于你希望将哪些工具融入到工作流程中。我们大多数的命令行程序可以通过homebrew包管理器轻松安装；Burp Suite 仍然需要安装 Java 8；当然，Kali Linux 发行版在栈的不同层次上运行，因为操作系统需要一个硬盘分区来进行安装。像往常一样，我们将使用 Chrome（66.0.3359.139）。

评估新工具 – 该关注哪些方面

在你审视一款新的渗透测试软件时，分析它为你的工作流程带来的价值是至关重要的。同样重要的是，问自己一些和使用开源、SaaS 或其他付费应用时类似的问题。这些问题应包括以下内容：

• 这款工具为我的工作流程增添了哪些我原本不具备的功能？

• 这些新功能有多重要？我预计它们的影响如何？

• 它是否将我锁定在某些计划、服务或特定设计中？

• 它有成熟的命令行界面（CLI）吗？

• 在已知的正向案例中，它的表现如何（对于扫描器和其他检测软件而言）？

• 如果是开源工具，项目已有多久？最后一次提交是什么时候，提交的频率如何？是否存在很多未解决的问题？问题是否得到了处理？

• 对于免费工具，是否为免费/社区用户提供了足够的功能？还是大部分所需的功能都被锁定在付费许可或订阅背后？

• 在付费工具的情况下，它是否与外部工作流程集成（例如，传入和传出的 webhooks、几种语言的客户端库或 RESTful 接口）？还是将你锁定在它的系统内？

这些问题中有些没有明确的答案，但思考它们会帮助你了解你正在考虑采用的任何软件的价值主张。

付费版与免费版 – 什么让一款工具值得使用？

是否开始为某款安全工具付费，仅仅是决定是否采用它过程的延伸，区别在于更多地关注其相对影响。

Burp Suite Pro 无疑是社区版的有用扩展。你可以使用扫描器，它与 Burp 的范围和攻击面映射功能紧密集成，还有一些高级手动工具，例如能够从拦截的 HTTP 请求中生成 CSRF（我们将在本章后面讨论），以及其他一些额外功能。

但是，正如我们在 CSRF 章节中展示的，生成 CSRF PoC 其实很容易自己自动化，且这样做能更好地与 Burp 以外的工具集成。如果你不需要其他高级手动工具，那么基本上就只剩下扫描器这一点了。即使你已经在工作流程中使用了扫描器，实际上不同的扫描器在扫描不同的漏洞时效果更好——你会通过对一个网站使用多个扫描器来得到最全面的安全评估（不过，考虑到扫描器的费用，实施起来并不像说得那么容易）。

Burp 的价值组件还增加了一层额外的内容。虽然你不应该仅仅因为某个工具性价比高就购买它，但这是一个重要的考虑因素。

扫描器很贵。顶级应用扫描产品的最便宜许可证，通常会达到几千美元，即使是一个小团队也难以承受（例如 Netsparker 这家安全公司最便宜的产品，每年不到$5,000，适用于一个桌面应用，允许扫描五个网站）。

这显然是他们试图吸引企业安全团队的举措，目标是那些需要可复现、自动化漏洞检测方案作为其整体应用管道/栈一部分的团队。但这种现象在许多渗透测试工具链中都很常见，因为拥有专业技术的公司希望针对 B2B 企业机会，这里有更多的盈利空间。而黑客则没有部门预算可以随便花。

在这种背景下，Burp Pro 许可证是一个极具性价比的选择，以低于其他流行产品一个月许可证订阅费用的价格，解锁了不仅仅是扫描功能。如果你跟着本教程走，或者通常把 Burp 作为你的安全工作流程中的关键工具，你应该考虑购买。如果你经常使用 Burp，那是值得的。

让我们考虑另一款工具，SecApps。SecApps 是由 Websecurify 创建的基于浏览器的渗透测试客户端，允许完全基于云的工作流，不需要桌面应用程序、本地文件或浏览器之外的依赖。这是一个非常适合放入 Chromebook 类型设备中的解决方案，其硬件需求最低。SecApps 有很多值得推荐的地方：尽管他们提供一些基础免费的服务（如 HTTP 代理），但大部分功能都在他们的付费版本中（需要注意的是，除了浏览器客户端外，他们还提供 CI/CD 测试的解决方案），其价格依然相对便宜，月费为 29 美元。但即便是这个低廉的使用成本，我们仍然需要考虑在考虑任何新工作流时要面对的相同问题：

这是否将我锁定在某些计划、服务或特定设计中？

是的。转向全云工作流会剥夺你对环境的控制权。因为你的数据全部存储在云端（从技术角度看），你无法控制它。此外，考虑到所有的集成、工具间的相互作用等，都发生在你无法依赖访问的堆栈不透明层次上，因此没有任何工作流可以迁移到其他系统。

在付费工具的情况下，它是否与外部工作流集成（例如传入和传出的 webhooks，或者多种语言的客户端库或 RESTful 接口）？还是将你锁定在其系统中？

这是与关于供应商锁定的普遍问题相关的类似问题。前一个问题更多地涉及你整体设计的兼容性，以及该通用工作流（和架构）是否可移植。这个问题更多的是关于边缘集成。你现有工作流的部分内容是否可以被整合进来？如果新工具对所有内容都很合适，但X无法使用，你是否仍然可以以某种方式将其纳入？通过一种通用数据格式（如 JSON、YAML 或 XML）或程序化 API 接口，你是否能够扩展该服务的功能？

对于 SecApps 的答案似乎是某种程度上的肯定。对于更多 CI/CD 解决方案，提供了一些基本的 CLI 选项，例如他们的 Cohesion 应用程序，基本上是一个源代码分析工具，DevOps 工程师可以将其嵌入到构建链中。但没有关于使用 API 与浏览器工具连接的相同后端服务进行交互的文档。

有一个名为 pown apps 的本地应用包装器，由 Pown.js 创建，但文档非常简略，CLI 选项也有限（见“它是否有成熟的 CLI？”），当我们浏览到 Pown.js 的代码库时，并没有看到能激发信心的内容。许多代码库是新的，且没有大规模的贡献图表，问题/社区支持似乎零散（还可以参考“如果它是开源的，项目有多老？最后一次提交是什么时候，提交的频率如何？是否有很多未解决的问题？问题得到解决了吗？”）。

这对我们来说不适用。尽管该服务的承诺很吸引人，但它对我们的渗透测试流程有过于明确的要求。与 Unix 的哲学相反，Unix 强调小而专注的单一功能组件，并共享 Unicode 作为通用语言，而 SecApps 让我们安装并使用大型复杂的应用程序（通过网页或通过 pown apps 桥接本地使用），这些我们无法查看，也无法控制。

其他拥有不同渗透测试流程的用户自然会对这些工具以及其他工具有不同的看法，但希望通过我们在本书中的工具分析，能够展示出关键决策点和一般流程。

其他选项的快速概览——Nikto、Kali、Burp 扩展等

安全领域有如此多的工具，可能很难知道哪些工具值得为你的工作流进行测试。本节包含了不同类型工具的简短描述，按它们在渗透测试中的作用进行分类。

扫描器

有许多专门用于收集或测试各种漏洞相关信息的扫描器选择。我们在本书中使用的几个仅代表市场的一个小部分。以下是一些选项；有的仅支持命令行，而有的则同时提供 CLI 和 GUI，尽管所有工具至少都提供某种程度的 CLI 控制，并且都是免费的。

Nikto

Nikto 是一款知名的扫描器，以其服务器指纹识别能力著称。除此之外，它通常是扫描 OWASP Top 10 漏洞的一个不错选择。

Zed Attack Proxy

Zed Attack Proxy (ZAP) 是一个由 OWASP（一个专注于 Web 应用漏洞研究的非盈利组织）创建的代理和扫描工具。ZAP 经常被视为 Burp Suite Pro 版本中包含的扫描器的免费替代品。

w3af

w3af 是一款开源、基于 Python 的扫描器，既有交互式 CLI shell 也有图形界面（GUI）仪表板。w3af 最初由 Andres Riancho 于 2006 年构思，随后几年吸引了来自全球的成千上万的公众贡献者。

nmap 和 python-nmap

本书的大部分内容都围绕着在其基于浏览器的攻击面——如表单字段、未加固的端点以及通常可以在浏览器或浏览器扩展中看到的内容——进行 Web 应用测试。

如果你希望进行更多的网络分析——检查开放端口、探测防火墙，并寻找超出标准 HTTP/TCP 连接的内容——nmap 是一个流行的选择，也是行业标准工具。

python-nmap 就是它的名字所示——一个基于 Python 的软件移植。如果你想要在 nmap 上进行黑客攻击，它非常有用。无论你是为现有的 nmap 端口发现功能添加检查，还是在其上加入自定义警报逻辑，python-nmap 包都是一个很好的起点，它能让你免于重新实现 nmap 标准功能的基础特性。

Aircrack-ng

Aircrack-ng 是另一个网络扫描工具，几乎已经成为 Wi-Fi 破解和数据包捕获的标准。尽管如此，尽管我们在本书中并未过多涵盖一般的网络分析，但对于任何希望入门的人来说，有一套很棒的工具。

更重要的是，不像社会工程那样，它是渗透测试的一个元素，我们专门没有涵盖这一部分，因为它对于大多数程序来说常常是越界的，公司会奖励研究人员指出其网络中的漏洞。

Wireshark

继续讨论网络扫描工具，Wireshark 是另一个经过战斗测试的网络分析程序，具有深度数据包检查和其他低级数据捕获功能，对于理解应用程序的加密安全态势至关重要。如果你更重视网络层级的安全问题，Wireshark 应该在你的雷达上，甚至成为你工具集的一部分。

SpiderFoot

SpiderFoot (www.spiderfoot.net/) 是一个专门从事 开源情报 (OSINT) 的扫描器，它通过社交媒体网络、DNS 记录和其他公开信息来汇总目标应用程序的攻击面和可能的漏洞。

尽管不可否认地有用，但在本书中，我选择更多地关注与应用程序特性直接交互的扫描器。SpiderFoot 是进行深入研究的好工具，适用于准备社会工程攻击时的工作，比如获取电子邮件和职位头衔，了解公司关键人物之间的关系。它对于寻找相关的、依赖的系统也是很有用的，这些系统可能会被入侵，进而渗透组织。

幸运的是（或者不幸的是），这些类型的攻击对于大多数渗透测试任务来说并不在范围之内。社会工程攻击和攻击供应商/第三方几乎总是在测试指南的行为规则中被列为禁止行为。这是一个很酷的扫描器和有用的工具，只是它不适用于我们的目的。

资源

这些是一般的教育内容来源；聚合的教程、代码片段和操作指南，富含洞察。

FuzzDB

FuzzDB (github.com/fuzzdb-project/fuzzdb) 是一个由开源安全社区贡献的攻击模式字典。与经过精心整理的集合，如 SecLists 一起，它是获取 XSS 输入等内容的一个重要资源。

渗透测试备忘单

JDow.io（jdow.io）提供了一个方便的资源，名为 Web 应用渗透测试备忘单，它详细介绍了渗透测试过程中许多步骤，包含代码片段和每个步骤的实现说明。

Exploit DB

Exploit DB（www.exploit-db.com/）自称为漏洞、shellcode 和安全论文的终极档案库（他们强调）。它由 Offensive Security 组织运营，该组织还负责其中一个更为著名的安全认证——Offensive Security Certified Professional（OSCP）认证。Exploit DB 还包含一个方便的 Google Dorks 数据库，我们将在后续关于 SQL 注入的章节中进一步探讨。

Awesome Web Security

awesomelists.top 品牌发布了针对各种技术领域的精心策划内容（他们自然也有自己的 AWS 系列）。他们的安全列表，awesome web security（github.com/qazbnm456/awesome-web-security），是一个很好的资源，甚至链接到其他相关的精心策划仓库，例如该组织自己的 awesome-bug-bounty 漏洞悬赏资源集。它还包含许多关于浏览器扩展数据泄漏、物联网漏洞扫描以及数据科学和机器学习如何与安全交叉等主题的精彩文章和教程。

Kali Linux

Kali（前身为 BackTrack）是一个专注于安全的 Linux 发行版，预装了我们在本书中使用过的许多工具，例如 Burp Suite，还包括其他工具，如 Maltego、Metasploit 和 Wireshark。

由于你可以从 live CD 启动并运行 Kali，它可能非常轻量。无需在硬件上进行持久安装，也无需将数据写入磁盘。Kali 的这两个特性（便携性和预装资产）使它成为渗透测试人员的理想选择，特别是对于那些可能无法经常访问自己机器的人。

源代码分析（白盒）工具

源代码分析通常不在公开漏洞悬赏计划的范围内（这也是为什么这本书中没有更多涉及它的原因）。如果开源不是公司业务模式的一部分，企业自然会对将其代码开放给一群安全研究人员感到犹豫。

但是，如果你身处一个私人合同中，进行白盒测试并访问源代码，或者通过 GitHub 或 Bitbucket 访问代码，那么你可以使用几种工具来帮助识别问题区域。

Pytaint

Pytaint 是一款工具，允许你对 Python 代码进行污点分析。这意味着追踪数据在应用程序中的流动，从输入字段、API 端点和其他入口管道的入口点开始，寻找数据被错误处理或未适当清理的区域。

Bandit

Bandit 是另一个优秀的源代码分析工具，使用一系列可定制的插件分析 Python，插件可以帮助工具聚焦于特定的漏洞集。与 pytaint 不同，Bandit 不遵循像污点分析这样的特定方法论；相反，应用的逻辑取决于你的插件集成。

Brakeman

Brakeman（brakemanscanner.org/）被认为是 Rails 应用程序最顶级的安全静态分析工具之一，被 GitHub 等行业领袖用来保护他们内部的 RoR 栈。如果你能够访问源代码，Brakeman 是发现 Rails 问题的极好工具。

Burp

我们在本书中介绍的 Burp Suite 工作流有许多扩展的方法。一些额外的解决方案将是付费功能，展示考虑订阅的吸引力，而其他一些则仅仅是我们没有时间在工作过程中利用的其他扩展或功能。

Burp 扩展

有许多很棒的 Burp 扩展可以帮助你构建基于 Burp 的工作流，并更好地利用 Burp 的原生功能。

JSON 美化工具

一个简单的插件，JSON 美化工具可以将你在 Burp Suite 中处理的任何 JSON 格式化得更加美观。它虽然简单，但在你的工作流程中，如果有很多手动交互的部分，格式化可能会显著提升生产力。对于其他语言，也有类似的美化工具/格式化工具，包括 YML、JS、SAML 等常见的数据类型。

Retire.js

记得我们在第三章《准备参与》中，围绕 Retire.js 构建了一小组脚本来检查客户端 JavaScript 中的漏洞，准备参与。实际上也有一个 Burp 扩展可以让你在 Burp 测试会话中直接执行相同的操作。如果 Burp 是你工作流中的一个重要部分，值得考虑这个扩展。

Python Scripter

Python 脚本扩展在每个 Burp HTTP 请求上执行 Python 代码。这使得添加额外功能比直接尝试添加 Java 代码或自己编写扩展更为简单。

Burp Notes

考虑到文档在撰写优秀提交报告中的重要性，像 Burp Notes 这样的工具可以配置为保存 HTTP 请求和来自不同 Burp 工具的其他数据，从而优化你的工作流，消除手动复制和粘贴的操作。

Burp REST API

Burp REST API 插件（github.com/vmware/burp-rest-api）允许你在一个包装器内运行 Burp 实例，使其主要功能通过 RESTful API 可用。如果你想将 Burp 与现有的自动化流程集成，这无疑是一个极好的补充。

SaaS 专用扩展

前述的扩展大多只是现有 Burp 工作流的独立补充。但是，Burp 还支持作为桥梁连接其他安全工具集的扩展。Faraday（www.faradaysec.com/）自我描述为一个多用户协作渗透测试环境，安全团队可以在其中共享范围、目标数据、发现和其他参与信息。还有一些工具特定的桥接扩展，如 SQLiPy，它是一个用于从 Burp 内部启动 sqlmap 扫描的扩展。

使用 Burp Pro 生成 CSRF PoC

测试 CSRF 并生成 CSRF 漏洞的代码 PoC 的一个好方法是使用一些内置的工具。不幸的是，生成 CSRF PoC 的功能仅对 Burp Suite Pro 用户可用。

在我们的测试中，我们将重新访问在第四章中检查过的 webscantest.com 页面，未清洗的数据—一个 XSS 案例研究，该页面也容易受到 CSRF 攻击。

在导航到表单之后，让我们填写不同的字段值：

在提交表单之前，我们会开启 Burp 代理的拦截功能，以便捕获我们的请求：

在提交表单后，我们可以看到请求已被 Burp Proxy 成功拦截：

现在，如果你右键点击 Burp Proxy 中拦截的请求，你会看到下拉菜单中有一个“参与工具”子菜单。如果你是免费/社区用户，这些选项将被禁用，但如果你是付费/Pro 用户，你可以选择生成 CSRF PoC。

你可以使用这个 CSRF PoC，它实际上只是一个短小的 HTML 代码片段，反映了你正在测试的表单和提交结构，用于触发应用程序状态的变化，从而证明存在 CSRF 漏洞（也就是一个 PoC）。如果你可以使用这个功能，它可以是一个快速且简单的方法，但如果不能，也很容易替代（我们在第六章中以编程方式生成了一个 CSRF PoC，CSRF 和不安全的会话认证）。

Metasploit 和漏洞利用框架

Metasploit 是由 Rapid7 提供的流行漏洞利用框架，尽管它包含了一些常见的扫描和代理功能，但它的亮点在于漏洞发现后、编写漏洞利用代码的阶段，当漏洞被发现并且你尝试将其用作更大规模攻击的跳板时。

这就是我们没有深入介绍 Metasploit 工具的原因。因为 Metasploit 的真正价值在于将（例如）SQL 注入漏洞转化为一个攻击，利用这个漏洞暴露用户数据、改变攻击者的权限，或实现其他恶意目的，它并不属于我们的漏洞奖励工作流程，后者更关注的是漏洞本身。事实上，大多数漏洞赏金计划明确不鼓励采取下一步行动。这正是白帽研究员与黑帽黑客的区别所在。

然而，Metasploit 可以是一个非常好的工具，用于头脑风暴出一些现实的、令人不寒而栗的攻击场景，这些场景可以说服安全团队你提交的漏洞确实是一个真正的威胁。清晰且有说服力地阐明你的发现影响是通向更大回报和更高提交成功率的最直接途径。

总结

在这一章中，我们已经介绍了超出我们在操作过程中直接使用的工具和方法论。我们还讨论了评估新工具的过程，并通过一个示例将该分析应用于 Burp Suite Pro 和 SecApps，结合我们在本书中探讨的渗透测试案例。到目前为止，你已经看到不同类型扫描器（应用程序、网络和 OSINT）、攻击模式的社区数据库、源代码分析工具、新的 Burp 扩展和工作流程、利用框架的价值等内容的扩展概述。这将帮助你在本书之外拓宽视野，并为你作为安全研究人员的持续发展奠定基础。

问题

1. 你应该如何评估新工具？

2. 有哪些有用的 Burp 扩展？

3. 哪些是进行端口扫描的好选项？

4. 升级到 Burp Pro 后，你可以期待哪些新功能？

5. 使用 Kali Linux 有哪些好处？

6. 什么是 OSINT？

7. 什么是 Metasploit，它有什么用途？

进一步阅读

你可以通过以下链接了解我们在本章讨论的一些话题：

• SecApps: secapps.com

• Pown apps: blog.websecurify.com/2018/01/pown-apps.html

第十二章：其他（超出范围）漏洞

我们已经讲解了很多关于你应该关注的内容——漏洞的结构，以及如何通过编程和手动的方式进行测试。

看似不重要的部分是你不应该关注的内容——如果你不在意它，你就会忽略它，对吧？但实际上，有几个常见的发现和误报是你会看到扫描工具、被动分析工具、扩展程序和命令行日志反复输出的。了解哪些漏洞是公司不感兴趣的，这非常有用，这样你既可以避免浪费时间提交注定失败的漏洞报告，也能在一开始就配置你的工具，减少不必要的噪音。

我们在这里讨论的大多数漏洞的共同主题是，它们没有明确的利用路径。它们要么只影响攻击者，要么需要其他（更严重的）漏洞的存在才能被利用，或者在泄露信息的情况下，攻击者没有任何可操作的信息。

本章将介绍公司通常从漏洞奖励计划中排除的漏洞，包括它们如何工作以及为什么通常不被覆盖，还有一些关于哪些漏洞不符合奖励考虑的常见主题。

技术要求

由于我们主要讨论并举例说明需要从工作流中排除的漏洞，我们只需要使用浏览器（Chrome 版本66.0.3359.139）就能完成。

DoS/DDoS – 拒绝服务问题

拒绝服务（DoS）和分布式拒绝服务（DDoS）是任何关注安全新闻的人都熟悉的网络攻击类型。通过将目标淹没在与合法访问量无差别的流量中，仍然是一种流行的方式，用于攻击或瘫痪网站，尤其是当与放大攻击结合时，攻击者通过劫持其他服务器、伪造连接服务或利用内部性能缺陷或瓶颈来实现。

2018 年，GitHub 遭遇了当时有记录以来最大的 DDoS 攻击（五天后该记录被打破），该攻击的流量饱和率达到了大约 1.3 TBps。攻击者能够实现如此高的吞吐量的一个原因是，他们依赖于控制不安全的 Memcached 数据库服务器（Memcache 是一种通用的分布式内存缓存系统），在这些服务器上，他们能够伪造一个查询包，看起来像是目标服务器请求从 memcache 服务器获取数据。然后，memcache 服务器会向目标服务器发送的数据量是伪造请求的 50,000 倍。GitHub 特别频繁成为攻击目标，这一事件只是该网站长期攻击活动中的最新一次。

如果你查看 GitHub 的漏洞奖励计划，你会注意到他们特别指出 DDoS 攻击——他们不允许这种攻击：

不要进行任何可能危害我们服务或数据可靠性/完整性的攻击。禁止进行 DDoS/垃圾邮件攻击。（这是他们特别强调的）

DoS/DDoS 攻击通常并不是受害者做了什么导致的——他们并没有错误地编码应用程序，也没有留下某些关键的网络漏洞。防御 DDoS 攻击需要一个完整的主动安全架构，将负载分配到不同的网络，并对恶意流量源进行限流/隔离。

例外情况是，当 DoS/DDoS 攻击因能够利用受害者网络上的安全漏洞而更有效时。如果作为安全研究人员，你发现例如一个不安全的 NTP 服务器可能被劫持来放大 DDoS 攻击，你应该报告这个漏洞，它可能被用来威胁你或其他旁观者的网络安全。

你不应该通过利用这些漏洞来增加机器人的流量，即使你认为它低于可能损害目标基础设施的门槛。DDoS 禁令如此普遍，表明漏洞奖励计划运营商对此的重视程度。

沙盒和自我 XSS——低威胁 XSS 变种

自我 XSS 是一种高度依赖社会工程学的 XSS 变种，这也是它被大多数漏洞奖励计划排除的主要原因。沙盒 XSS，一个相关变种的术语，通常用于描述发生在与敏感用户数据或操作隔离的机器上的 XSS 漏洞。由于自我 XSS 指的是在浏览器环境中执行代码使自己容易受到 XSS 攻击的现象，因此也意味着你的 XSS 漏洞在能够访问的信息方面是被隔离的。

为了使自我 XSS 攻击发生，攻击者必须让受害者在浏览器上下文中执行代码。正是这种执行使受害者容易受到攻击者的进一步利用。

一个简单的自我 XSS 实例是这样的：

1. 攻击者宣传一个黑客工具包——H4x0rs l18e 1337！或者现在孩子们说的其他话。你只需复制这段代码并将其粘贴到浏览器的开发者控制台中。

2. 你，美丽的天真，愉快地复制代码并将其粘贴到你的控制台中，幻想着你数字怒火的恐怖。

3. 你粘贴到控制台中的代码并没有攻击别人，而是暴露了你自己给黑客。你浏览器中任何可用的敏感会话 Cookie 或信息现在都成了一个神秘网络极客组织的财产。

关于这个实际例子的说明，请查看“进一步阅读”部分中的链接，其中包含了一个类似的诈骗案例，该案件几年前在 Facebook 上传播：这篇文章（也）鼓励你按照指示来破解任何 Facebook 账户，（也）要求你复制并执行开发者控制台中的代码，（也）在你实际遵从后进行攻击。

因为这个特定的漏洞，像许多这些不能奖励的、几乎是漏洞的情况一样，需要应用外的行动（例如电话支持工作人员在社交工程影响下发起更改）或其他应用程序级的漏洞存在并准备好被利用，所以它超出了大多数计划的范围，不符合获得奖励的条件。

即使公司写了避免这些类型诈骗的指南，它们在预防措施方面也有局限性：如果房主决心要把钥匙交出去，房子也只有有限的安全措施可以采取。

非关键数据泄漏——公司不在乎的内容

在第八章《访问控制与通过模糊性保障安全》中，作为我们关于访问控制、安全性模糊性和数据泄漏讨论的一部分，我们简要介绍了公司不愿意为其奖励的不同类型数据：用户名、描述性但不敏感的错误信息、不同类型的错误代码等等。

这里有一些其他具体的例子，关于安全研究人员常常报告的信息，但公司很少为其支付奖励。

电子邮件

电子邮件是许多人尝试阻止爬虫和自动化代理访问的一项信息。一种典型的策略是将电子邮件链接编码为 HTML 实体，以使其更难被收集。这意味着你可以将一个电子邮件地址，比如nessus@generalproducts.biz，隐藏为以下实体代码：

nessus@generalproducts.biz

除非爬虫程序预期在抓取过程中检测并解码实体，否则这个小小的混淆技巧可能出奇有效。

但是，如果电子邮件暴露在公司网站上，通常是为了作为公共的联系方式。如果你提交关于support@company.com的漏洞报告，甚至因为你推测出了员工邮件命名规范是类似于lastname.firstname@company.com，这都不符合获得奖励的标准。

在披露变成漏洞之前，除了简单列举公司邮件用户名注册表外，还有太多额外的步骤。

HTTP 请求横幅

HTTP 横幅是协议的一个重要部分，它将整个网络连接在一起。在常见服务中，可能涉及许多不同类型的设备。它们可以包括编码数据、设备信息、HTTP 请求的基本信息以及其他数据。

这一切都是服务的一部分，并不构成敏感系统信息的泄露。这包括当前横幅中包含的信息以及“缺失”的安全横幅。

已知的公共文件

这很简单：有些文件就是设计为可访问的！报告 robots.txt、wp-uploads 或 sitemap.xml 的配置或可用性并不会获得奖励——甚至可能不会得到任何回应。

缺失的 HttpOnly Cookie 标志

HttpOnly Cookie 标志是防止 XSS 攻击的工具。如果服务器端进程将 cookie 标记为 HttpOnly，它就不能在客户端访问（当浏览器尝试读取该 cookie 时，它将返回空字符串）。所有主流浏览器都支持 HttpOnly cookies。无论其值如何，它们都是一种保护措施，其缺失并不直接意味着存在漏洞。如果没有额外的 XSS 攻击，便不会产生问题。

其他常见的无奖励漏洞

除了我们已经讨论过的通常不符合支付条件的更大类别的漏洞，并且请记住，这些漏洞是附加在先前提交的漏洞上，这些漏洞在任何地方都不符合支付条件之外，还有很多一类的单独漏洞和杂项潜在漏洞，你应该避免提交。

弱或易被绕过的验证码

CAPTCHA（及其继任者 reCAPTCHA）是由 Google 管理的图灵测试，旨在通过要求机器人执行一些普通机器人无法完成的任务（例如复杂的自然语言检测、图像模式识别、在动态挑战中执行任务等）来阻止机器人的表单提交垃圾邮件。由于它们代表一个第三方服务，其安全性由外部公司管理，因此大多数托管 CAPTCHA 的公司不会奖励任何与 CAPTCHA 相关的漏洞或安全问题。

启用了 HTTP OPTIONS 方法

HTTP 支持多种请求方式，除了标准的 GET、PUT/PATCH、POST 和 DELETE 请求。OPTIONS 是一种诊断方法，能够启用调试和堆栈跟踪数据，这可能对攻击者有用。虽然它增加了你的攻击面，并且作为应用程序开发者应该避免启用，但启用 OPTIONS 本身并不是一个漏洞。像我们之前讨论过的其他潜在漏洞一样，它需要额外的步骤来证明有效的攻击场景。

BEAST（CVE-2011-3389）和其他基于 SSL 的攻击

浏览器对 SSL/TLS 的攻击（BEAST）假设攻击者具有相当程度的客户端控制，能够通过执行中间人攻击（MiTM）向浏览器的 TLS 流中注入数据包，从而使攻击者能够猜测初始化向量并解密其他信息。

正如安全产品公司 Acunetix 在其关于该攻击的博客文章中提到的：

值得注意的是，要让 BEAST 攻击成功，攻击者必须对受害者的浏览器有合理的控制权，在这种情况下，选择一个更简单的攻击途径的可能性更大。

这例证了我们常见的没有奖励的潜在漏洞主题：相关漏洞影响的是实际的 TLS/SSL 连接，这意味着它是底层技术的责任，而不仅仅是该技术的特定实现；它也是一个需要多个其他漏洞才能被利用的漏洞，这意味着如果它存在，它并不是我们最应该关注的问题。这两种动态作用于使其以及其他基于 SSL 的攻击无效，无法作为可报告的提交。

暴力破解认证系统

如果一个认证系统（GUI 表单、API 请求或任何其他实现或层）在多次登录失败后没有锁定用户，这使得系统容易受到暴力破解攻击，攻击者会尝试每一种可能的凭证组合，直到成功为止。在失败登录尝试超过一定次数后锁定用户是常见的安全最佳实践，但缺少这一功能并不意味着应用程序立即不安全。暴力破解所涉及的资源量及其产生的高噪音意味着，单靠暴力破解能力本身并不足以构成严重的攻击场景。此外，测试暴力破解攻击的有效性意味着 进行 暴力破解攻击，这可能对目标公司的基础设施和计算资源造成严重损害。

CSRF 注销

传统上被认为是一个安全非问题（而且许多漏洞赏金计划至今仍未给予奖励），跨站请求强制注销用户的能力正在被像 Detectify Labs 这样的组织重新评估为潜在的安全威胁，这些组织发布了几种不同的攻击场景，概述了何时注销功能容易受到 CSRF 攻击时会成为问题（请查看 进一步阅读 部分中的链接）。尽管这个漏洞不断被重新评估，但它通常仍然需要几个额外的步骤才能成为一个真正的漏洞，并且具备可信的攻击场景，因此并不是漏洞赏金计划的优先事项。

匿名表单 CSRF

另一个常见的与 CSRF 相关的漏洞是匿名表单（例如，联系我们表单），它容易受到 CSRF 攻击。如果一个匿名表单容易受到 CSRF 攻击，意味着攻击者可以欺骗受害者提交带有不同或修改字段的表单。

以联系表单为例，这个漏洞不值得支付奖励，因为我们无法从中推导出任何相关的攻击场景。即使我们使用不同的电子邮件地址或信息提交表单，也不清楚会造成什么损害。对于更为关键的表单（例如填写支付信息、修改账户设置或身份验证方式），我们可以想出一些令人毛骨悚然的场景，但如果一个表单是匿名的，通常意味着它预期会接收到大量垃圾邮件，因此与重要功能隔离开来。

这个例子强调了我们在本书中反复提到的一个普遍观点：模拟关键攻击场景对于确保你的提交能获得奖励至关重要。

点击劫持和点击劫持启用攻击

Clickjacking（点击劫持）是指攻击者将恶意链接隐藏在一个透明或被遮掩的链接下，使得用户被诱导点击这个黑帽网址。

点击劫持被排除在奖励计划之外，因为它要求公司自身使用黑暗模式（恶意的用户体验/用户界面技巧），诱使用户在他们控制的平台上点击有害链接。既然任何公司实际上在做这件事时肯定不会宣传它，那么奖励计划也不会支付那种只能通过用户在自己机器上修改代码才可能存在的漏洞。这就是为什么点击劫持（以及只能通过点击劫持发生的漏洞）不会获得奖励的原因。

物理测试发现

有时，寻求严格安全审计的公司会走得更远，不仅仅是雇佣一个团队来测试网站或探测网络——他们还会为研究人员支付费用，测试控制其数据中心访问的物理安全外围。这种类型的测试在那些有强大访问控制合规政策的行业中最为常见——例如，PCI 合规性要求你采取一定的物理安全措施（例如，访问场所需要身份证，限制对实际服务器机箱的访问等），以保护你的基础设施。

任何接近物理测试的内容都超出了本书关注的工作范围。如果你发现了一个漏洞，要求你偷偷溜进公司休息室，弄乱某人的解锁笔记本电脑，那并不是一个漏洞。这样的活动完全超出了范围，且可能触及法律责任。

过时的浏览器

当你发现一个依赖过时浏览器作为攻击载体的漏洞，尤其是对于一个相当古老的安装（例如早于 IE 8 的版本），让公司通过支付奖励来补偿这个漏洞是不合理的——毕竟，过时的浏览器没有接收安全更新（以及公司可能想要应用的任何修复）。即使这个问题可以通过服务器端修补，也没有必要为适用的生命周期结束政策开辟例外。

服务器信息

尽管它是任何合作中的发现阶段中有价值的一部分，但发现服务器类型或托管服务并不是一个漏洞。混淆技术虽然不错，但多余，而且基本的公共服务器数据本身并不能说明一个有足够价值的攻击链值得奖励。

限速

限速可能会让你感到意外，它必须明确排除在程序的范围外漏洞中，但显然限速（通过选择性地限制请求来保护你的服务器免受攻击）是一项特性，而非漏洞。

总结

本章已经涵盖了不同类型的安全漏洞，这些漏洞通常不足以构成有利可图的漏洞，包括 DoS/DDoS 攻击、自我 XSS（Self-XSS）以及其他类型的攻击，还有一些常见的被扫描器和渗透测试工具报告的内容，但这些内容不一定引起漏洞悬赏计划运营者的兴趣。除了各种杂项的范围外漏洞和分析这些漏洞共同特征的内容（它们需要其他漏洞的配合，它们的影响范围有限，它们需要社会工程学或对第三方服务的攻击，等等），你应该已经理解了不仅是哪些漏洞不会得到奖励，为什么它们没有价值。接下来，你可以调整自己的工作流程，减少报告中的噪声，并建立一个能减少浪费时间的死胡同，专注于真正有价值漏洞的渗透测试方法。

问题

1. 为什么 DoS/DDoS 攻击通常超出范围？在什么情况下，DoS/DDoS 相关的漏洞会得到奖励？

2. 什么是 Self-XSS？为什么它通常不值得奖励？

3. 启用 HTTP 的OPTIONS方法会带来什么潜在危害？

4. 为什么 BEAST 和其他 SSL 漏洞通常不符合漏洞悬赏计划的条件？

5. 什么是点击劫持（clickjacking）？

6. 什么是物理测试？

7. 什么情况会使 CSRF 漏洞超出范围？

8. 什么是黑暗模式（dark patterns）？

9. 为什么与暴力破解相关的漏洞不会得到奖励？

进一步阅读

你可以在以下链接了解更多关于本章讨论的一些话题：

• Facebook Self-XSS 骗局：www.tomsguide.com/us/facebook-self-xss,news-19224.html

• GitHub DDoS 攻击：www.theregister.co.uk/2018/03/05/worlds_biggest_ddos_attack_record_broken_after_just_five_days/

• TLS/SSL 漏洞攻击：www.acunetix.com/blog/articles/tls-vulnerabilities-attacks-final-part/

• Detectify 实验室关于 CSRF 登出：labs.detectify.com/2017/03/15/loginlogout-csrf-time-to-reconsider/

• 黑暗模式：darkpatterns.org/

第十三章：进一步探索

希望您发现本书中包含的资源有用。当您希望扩展您对信息安全、漏洞和公共赏金计划的兴趣时，有很多优秀的资源可以帮助您前进。

在本章中，我试图收集一些最好的社区网站、策划的博客、教育资源、漏洞报告档案，最后，一些由本书和其他书籍使用的一些重要（和晦涩）安全术语的词汇表。这一章应该是一个不错的参考，作为您深入独立、自由安全研究领域的跳板。

博客

博客，无论是公司撰写的还是个人的，都是了解来自一个知情来源的新资源和方法的好方法，你信任他们筛选你关心的新闻。我们在这里包括的博客更专注于渗透测试和赏金计划参与，而不是信息安全或网络安全。虽然有很多行业专家撰写的优秀博客，比如 Bruce Schneier 的Schneier on Security或 Brian Krebs 的Krebs on Security，可以依赖于对流行安全主题进行严格、技术信息丰富的文章，提供这类通用信息安全出口的全面账目超出了我们的范围。

SANS 研究所

自 1989 年以来提供围绕网络安全的培训和教育，SANS研究所（代表SysAdmin, Audit, Network, and Security）运营一个博客（pen-testing.sans.org/blog/），这可以是一个很好的资源，提供简短的教学文章和简单的参考资料。他们的一系列包含选定工具基本命令简要摘要的备忘单是你探索采用新东西时的第一个资源。

Bugcrowd

我们已经讨论过 Bugcrowd 作为安全研究人员的一个伟大社区和平台，但他们的博客也是其中的一部分价值。除了作为一个有用的联系点，了解有关 Bugcrowd 平台的新赏金计划、政策变更和产品提供之外，该公司还为安全社区做出贡献，组织倡议，例如漏洞评级分类法，以更好地标准化严重性分类，并委托编写白皮书、教程和其他数字资源。

暗网

Darknet（www.darknet.org.uk/）从 1999 年的 IRC 频道发展成今天一个成功的渗透测试博客，定期更新有关新漏洞、策略和软件的信息。Darknet 特别有用，因为它的文章经常包含您可以修改用于自己目的的代码片段和脚本。

HighOn.Coffee

HighOn.Coffee 博客（highon.coffee/）是渗透测试人员@Arr0way的个人项目。他的备忘单是一些最常见的 shell 命令、脚本和方法的绝佳参考，涵盖各种渗透测试和安全相关主题。与 Darknet 博客一样，HighOn.Coffee 包含可用于自己的渗透测试工作流程的代码，使其成为一个值得关注的资源。

零日博客

零日博客（www.zdnet.com/blog/security/）并不像我们的其他资源那样充满了详细步骤和技术分析，但它是一个更具话题性的安全新闻来源。

SANS 应用安全博客

另一个 SANS 旗下的 AppSec 博客与 Frank Kim（software-security.sans.org/blog）是另一个为专注的渗透测试人员提供实用建议的源泉。Kim 每年进行一系列有趣的调查和其他年度项目，这些项目是分析过去几年安全领域突出主题演变的有趣比较点。

课程

与常见的在线学习目的地（如 Udemy）和著名的安全认证（如攻击性安全的攻击性安全认证专业人员（OSCP））相关联的几门优秀课程。它们在多个方面有所不同，包括所需背景、长度、范围和价格。综合起来，它们代表了一系列安全培训选择和理念的万花筒。

使用 Kali Linux 的渗透测试

OSCP 使用 Kali Linux 进行渗透测试课程（www.offensive-security.com/information-security-training/penetration-testing-training-kali-linux/）是 OSCP 认证的必修课程，并附带 30 天的认证考试 VPN 访问权限。OSCP 备受尊重，因为它强调实践实验室，在那里，考生不是回答多项选择题，而是必须登录到 OSCP 网络，并在规定的 24 小时测试期内发现几个漏洞。虽然你可能想逐步提升到 OSCP 考试（而且可能会很昂贵），但如果你有兴趣从事安全领域的职业，这是一个很好的目标。

信息安全研究所的课程

信息安全研究所（www.infosecinstitute.com/）提供多门在线课程和集训营，旨在为学生准备诸如认证的道德黑客（CEH）和认证的渗透测试员（CPT）等认证考试。他们的为期 10 天的集训营非常密集，但也有点昂贵。

Udemy 渗透测试课程

Udemy (www.udemy.com/topic/penetration-testing/) 是我们为个人独立研究人员推荐的最具性价比的选项。通过针对特定编程语言（在 Python 中创建自己的黑客工具）或工具（从零开始学习使用 Android 进行黑客攻击）的课程，您可以根据自己的技能提升方向选择不同的课程选项。

术语

安全领域充斥着大量术语。独立研究员、黑帽黑客、公司红队和军事机构都有自己的文化、行话和首选技术术语。我们将尽可能定义尽可能多的基础术语，以便您在遇到不熟悉的术语或用法时可以作为清晰的参考。请记住，本词典仅针对与安全相关的术语，而不包括一般的 Web 或软件开发行话，除非它们与安全问题直接相关。

攻击场景

攻击场景是一个详细的、技术上有效的假设情境，描述了如果一个漏洞未被修补并被恶意代理利用，可能造成的损害。编写有说服力的攻击场景是确保您因漏洞获得奖励的关键部分。

攻击面

应用程序的攻击面是指所有数据被输入或输出到应用程序的所有点的总和。攻击面中的每一部分都是黑客攻破应用程序的一次机会。应用程序的攻击面越大，您需要做的安全工作就越多，而且难度也越大。保持攻击面仅限于必要的最小范围，是加强安全态势的一个有效方法。

黑盒测试

在黑盒测试场景中，审计研究员无法访问基础源代码、架构文档、内部维基或任何其他内部开发团队可以访问的信息。本书中的所有场景和建议都假设是基于黑盒框架的。

漏洞

“漏洞”一词与“bug”同义。需要特别注意的是，这里的“bug”并不包括功能性用户体验/界面上的错误（例如，一个模态窗口在你填完表单之前就自动打开和关闭，一个 CSS 伪影让你无法查看解释工具提示，文本颜色过浅无法读取，等等）。我们这里只是指安全/渗透测试社区中所称的“bug”。

漏洞赏金计划

本书聚焦于那些通过奖励研究人员为公司或参与该计划的公司提供有效漏洞发现的公开或近公开程序。有时候，奖励的形式包括游戏化的积分系统（如 Bugcrowd 的 kudos）、赠品、认可（通常是在荣誉墙上展示）或金钱，或者这些奖励的组合。近公开的概念指的是那些私有奖励计划，邀请研究人员测试应用程序是基于其过去的表现、发现的漏洞的平均严重性以及其他职业统计数据。此定义的漏洞奖励计划不包括那些个体或团队渗透测试人员签署独家合同提供服务的情况。在这种情况下，我们讨论的许多技术仍然适用，但报告的格式和性质会有所不同。

CORS

跨源资源共享（CORS）是一种方法，它允许具有不同来源（IP 地址、端口等）的服务之间共享资源。CORS 在我们讨论 第四章《未清理数据——XSS 案例研究》时会出现，在这部分内容中我们讨论了单一来源策略。

数据外泄

数据外泄是指未经授权地将数据从应用程序或网络转移或复制。它可以是任何形式的数据，从支付信息到敏感的知识产权，简洁地描述了一种特定类型的信息盗窃。

数据清理

数据清理涉及去除数据中可能导致用户输入作为代码意外执行的特殊字符或保留字。这一做法是防止注入类攻击（包括 XSS、SQLi、NoSQLi 及其他各种注入攻击）的核心组成部分。

数据泄漏

数据泄漏与数据外泄不同，数据泄漏意味着不当配置的服务或其他系统意外暴露了敏感数据。这个含义更多来自于术语的含糊，而非任何正式定义，但它在描述像是公开的日志服务器这种情况时非常有用，日志中可能会意外显示认证凭证。在这种情况下，应用程序并未遭到黑客入侵，也未破解网络或数据库，但有人犯了一个错误，留下了这个资源开放，而这些数据可能为其他一轮攻击提供基础。

漏洞奖励计划

漏洞利用（Exploit）是用于攻击应用程序或其用户的恶意代码，它利用漏洞所暴露的缺陷，通过弱/损坏的认证、权限管理不当、不充分的数据控制或其他漏洞来进行恶意操作。像 Metasploit 这样的软件框架（我们在第十一章，其他工具 中讨论过）旨在帮助编写恶意利用代码。由于本书的重点是发现漏洞而非利用漏洞，漏洞利用主要出现在编写一个可信且普遍令人恐惧的攻击场景时，作为提交报告的一部分。

指纹识别

指纹识别是收集系统信息的过程，通过这些信息可以识别目标应用程序环境的操作系统和硬件规格等数据，这些数据有助于优化你的攻击策略。检测托管服务、服务器操作系统类型（如果是后端）、版本、应用程序语言与框架、任何包含的第三方库以及公开可见的 API 集成，都是发现过程中的重要组成部分。

Fuzzing

Fuzzing 是通过高速、重复的试错过程，向应用程序投递不同的信息组合，以尝试揭示其弱点。Fuzzing 工具通常会接收一个模式或字典类型的 fuzzing 输入，从而构建一系列将提交给目标应用程序的攻击字符串。

Google Dorks

Google Dorks 是可以用来返回可能存在某些漏洞的站点的搜索查询（具体取决于查询的内容）。我们在讨论 SQL 注入的章节中，会更详细地介绍 Google Dorks。

已知组件漏洞

已知组件漏洞是指已被发现并报告的漏洞，通常会带有一个 CVE ID，可以将其纳入扫描数据库和工具中，用于以一致且可重现的方式发现该漏洞的实例。我们在第九章，框架和应用程序特定的漏洞 中讨论了组件漏洞。

OSINT

开源情报（OSINT）是指从公共记录中收集目标信息的实践（如域名注册记录、官方文件、社交网络个人资料、参与公共论坛或其他数字空间的活动等），这些信息可用于辅助其他情报收集活动，如破解密码或进行有针对性的社会工程攻击（如鱼叉式钓鱼、鲸鱼攻击等）。

被动扫描与主动扫描

被动扫描分析 Web 应用程序内的数据流。它们要少得多嘈杂，对提供应用程序维护者信息的日志和相关指标几乎没有影响。相比之下，主动扫描涉及将数据发送到应用程序，然后分析响应。通常禁止主动扫描，因为它可能对网络造成损害，并可能降低应用程序性能。

负载

在一般软件开发中，负载本质上是一个动作的消息——动作包含的语义内容，超出了其元数据、标头和其他系统信息。在网络安全上下文中，负载类似于被武器化的恶意代码片段值，它逃避了清洗措施并实际执行攻击。

概念验证（PoC）

漏洞的 PoC 是一个代码片段或一系列指令，用于证明所讨论的安全问题存在。PoC 应尽可能简单，以展示触发利用所需的最低条件。我们在第六章中讨论了 CSRF 的 PoC，CSRF 和不安全的会话认证。

规则（RoE）

漏洞赏金计划的规则（也称为披露指南或行为准则）描述了公司希望测试的最有价值的漏洞、允许/禁止的测试方法和工具、研究范围以及超出范围的漏洞。规则是您开始任何渗透测试项目的最重要参考文档，因为它塑造了您后续调查的方向。

红队

公司的红队是负责模仿外部攻击者的攻击和行为、探查公司网络防御并通过反复的攻击分析和尝试入侵暴露弱点的内部安全团队。

远程代码执行（RCE）

RCE 是一个让任何人都感到恐惧的三个字母缩写。远程代码执行就是字面意思。它通过网络（例如互联网）触发在远程计算机上执行任意代码片段。允许 RCE 的漏洞是一个非常关键的问题，将确保您获得丰厚的报酬。拥有这种对服务的访问权限所带来的可能性是巨大的：将计算机添加到僵尸网络、外泄数据、通过加密货币挖矿耗尽受害者的资源。考虑到图灵完备语言的无限可能性，一个富有想象力的攻击者可以造成令人印象深刻的破坏。

安全港

一些漏洞赏金计划还会宣传安全港条款。这本质上是公司向您保证作为研究人员的承诺，并保证您遵循他们在规则中制定的测试准则而免受法律诉讼。

范围

参与范围指的是目标应用程序中可以进行分析的区域（由 IP 地址、主机名和功能定义），以及不允许的测试行为类型（例如，不允许主动扫描、不干扰或修改其他用户的数据等）。遵守范围至关重要，既是对项目操作人员的尊重，也能最小化你可能因触及超出范围的系统而承担的责任。

安全态势

一个组织安全态势的标准定义来自美国国家标准与技术研究院：企业网络、信息和系统的安全状态，基于信息安全资源（例如人员、硬件、软件、政策）以及用于管理企业防御和应对局势变化的能力。

单一来源策略

单一来源策略是浏览器采用的 CORS 系统的一部分，规定并限制来自不同来源（主机名、端口等）的脚本访问彼此数据的能力。单一来源/CORS 机制旨在阻止一个应用程序暴露敏感信息或对另一个站点执行状态更改操作。

提交报告

你的提交报告涉及到你认为自己发现的漏洞相关文档。

漏洞

漏洞是应用程序中的缺陷，允许攻击者妥协应用程序、其用户群或其网络。漏洞（这个术语通常与 bug 同义使用）本身不是攻击，而是防护漏洞，攻击代码（即实际的恶意代码部分）通过它进入。

白盒测试

白盒测试是指在有访问应用程序源代码的参与中，审计应用程序的安全漏洞。虽然我们在各个部分讨论了探索应用程序公开可用的客户端代码，在我们的第十一章《其他工具》中，我们讨论了白盒工具，如 Pytaint，帮助你了解安全态势，但绝大多数漏洞赏金猎人的工作将是黑盒测试。

工作流

工作流是本书中用来指代进行全面安全审计过程中既包括正式流程也包括非正式流程的一个统称。正式流程的例子可能是你想确保在任何应用程序中检查的不同类型漏洞的列表，或只是一个关于你参与各阶段的概述，从发现到结束和报告。非正式流程的例子则可能是你用来决定是否在特定情况下应用某个工具的内部启发式方法。

零日

在安全领域中，一个常见且重要的术语是零日漏洞，它指的是一个之前未被发现的漏洞。

总结

希望本章内容能在第十一章、其他工具及本书其余部分的基础上，帮助你不仅理解可以探索并融入工作流的技术，还能获得学习资源、社区和其他重要安全内容的中心，这些都有助于你作为安全研究员和程序员的成长。

问题

1. 有哪些好的渗透测试和安全相关的博客？

2. 公共漏洞悬赏计划使用什么类型的测试方法：黑盒测试还是白盒测试？

3. 一个允许远程代码执行（RCE）的漏洞代表了什么危害？

4. 什么是安全港？

5. CORS 代表什么？它的目的是什么？

6. 安全态势（security posture）是什么意思？

7. 对应用进行指纹识别的实践有什么作用？

8. OSCP 代表什么？

进一步阅读

你可以在以下链接中了解更多我们在本章中讨论的一些主题：

• Schneier on Security: www.schneier.com/

• Krebs on Security: krebsonsecurity.com/

第十四章：评估

第一章

1. 越来越多的公司通过众包方式进行安全审计——既能降低内部成本，又能从更多样化的研究人员、策略和技术中受益。

2. 参与漏洞奖励计划为你提供了与真实生产目标对抗的宝贵实践安全经验，也能为你带来金钱回报。

3. 你需要一些基本的网页技术技能，但同样也需要一种好奇心和调查欲望，去打破现有的规则。

4. 一些工具，例如 Burp Suite，是集成多种功能（代理、扫描、映射）的“工作马”，以实现最大效果，而一些工具则针对更具体的目标（例如sqpmap用于 SQL 注入发现，wfuzz用于暴力破解文件发现等），以及我们为添加额外功能或整合工作流而编写的单一用途、一次性脚本。

5. 添加document.location.origin可以确保我们针对的是一个范围内的域名。这个信息也为我们提供了有价值的见解，帮助开发人员修复漏洞。

6. 考虑漏洞的影响对于编写引人注目的攻击场景至关重要。编写代码以实际危害应用程序、用户或第三方服务是绝对不允许的，即使是为了证明漏洞的存在。

7. 《电脑欺诈与滥用法案》作为早期计算机欺诈法案的延伸，规范了国内的网络安全法律。这项法案的通过，部分得益于 1983 年由马修·布罗德里克主演的电影《战争游戏》的警示效果，众议院委员会关于这部法律的报告将其描述为“对个人计算机的自动拨号和访问功能的现实表现。”

第二章

1. 像 Bugcrowd 和 HackerOne 这样的公司将为其项目的参与者提供标准化的提交模板、披露指南和支付系统，而单个公司的程序则必须逐个评估并遵守。

2. 是的！除了提供宝贵的经验外，它还可以为你打开通向私人计划的大门，提供更好的测试机会。

3. 我们使用这个术语来指代像 Bugcrowd 这样的平台上的私人漏洞奖励计划，这些计划仅向符合特定标准的预选筛选研究人员发出邀请。

4. 你可以在其他工具和进一步深入部分找到更多资源。

5. 一个老旧的网站，提供更多用户输入的机会，使用的软件没有定期更新，且由一个小型组织维护，往往比一个拥有更小攻击面和内部安全团队的大公司更难确保其攻击面安全。

6. 协调漏洞披露是通过第三方向公司披露漏洞的一个过程和一套标准。

7. 紧密遵循互动规则是至关重要的！使用工具来确保你的自动化部分保持在范围内。

第三章

1. wfuzz配合全面的字典列表，是一个强大的暴力破解映射工具——它非常有效，但应该仅在暴力破解合适的情况下使用。

2. 网站地图是一个简单、免费的基本侦查快捷方式。如果没有网站地图，可以使用 Burp Spider 来映射目标应用。

3. 如果你正在寻找一个低影响的替代方法来映射攻击面，你可以通过连接到 Burp Proxy 的浏览器导航目标应用，Burp 会自动构建一个网站地图。

4. Scrapy 是一个很棒的、可扩展的站点抓取解决方案。

5. 编写简短、单一功能的脚本可以让你混合和匹配不同的功能，而文本的共同基础确保了互操作性。

6. SecLists 是一个出色的精心整理的恶意输入资源。

7. Striker 是一个 Python 扫描器，特别有用的是它具备 DNS 收集能力。

第四章

1. 存储型/持久型 XSS、反射型 XSS 和 DOM 型 XSS 是三种常见的 XSS 类型。

2. 持久型 XSS 特别危险，因为存储在服务器中的恶意代码可以被推送给大量用户。

3. 在 XSS 发现中存在很多误报，XSS 验证器帮助在噪音中提升信号。

4. XSS 验证器phantomjs服务器监听可能的漏洞并对其进行验证检查。

5. 在 Burp Intruder 的 Payloads 选项卡中使用有效负载位置功能。

6. 所有通常的上下文数据都很重要（如 URL 位置、输入等），但有效负载是最为关键的。

7. XSS 漏洞可能允许攻击者窃取管理员账户凭证，并对特定服务和组织执行超级用户权限的操作。

8. 包括攻击场景可以说服接收报告的团队，认为他们应投入必要的资源来修复漏洞（并触发你的奖励）。

第五章

1. Blind SQLi 是 SQL 注入的一种，其中结果不可见；基于错误的 SQLi 通过精心设计的 SQL 错误暴露敏感信息，而基于时间的 SQLi 则通过响应延迟来揭示信息。

2. 激进的 SQLi 注入可能会破坏数据库或应用程序。

3. Google Dorks 是旨在揭示潜在易受攻击站点的搜索查询。这个词来源于那个不小心让敏感文档被公共搜索引擎索引的倒霉员工。

4. --timeout、checks、--scope-include-subdomains、--http-request-concurrency MAX_CONCURRENCY 和 --plugin 'PLUGIN:OPTION=VALUE,OPTION2=VALUE2' 都是arachni命令行接口（CLI）的有用配置标志。

5. 你可以使用arachni_reporter CLI 从.afr文件生成报告：

 arachni_reporter some_report.afr --reporter=html:outfile=my_report.html.zip

1. MongoDB 中的$where子句特别容易受到注入攻击。

2. 如果你能在 Web 应用程序中诱发某种明显的行为（例如长时间延迟），你可以将其与比较逻辑结合起来，枚举敏感信息。

第六章

1. CSRF 代表跨站请求伪造，是指攻击者利用已登录用户的认证状态来执行恶意应用请求，并以有害方式更改用户的应用。

2. 拥有 CSRF 漏洞的攻击者可以诱使用户在不情愿的情况下更改应用状态，或者以他们未打算的方式更改（例如，将资金转到另一个银行账户）。

3. CSRF 漏洞证明（PoC）仅包含重现表单 HTTP 请求所需的基本标记。

4. 如果你能在浏览器中打开一个 CSRF PoC 并成功提交，那就验证了这个漏洞。

5. 使用 BeautifulSoup 生成 HTML 可以让你避免繁琐的字符串操作（例如，拆分和插入嵌套标签）。

6. 我们在 E2E 示例中使用了基于 CSRF POST 的攻击。

7. 一个恶意攻击者会使用更多隐藏字段，并允许其受害者控制更少的数据发送到服务器。

第七章

1. 一个容易受到 XXE 攻击的 PHP XML 解析器配置错误的示例是没有将 libxml_disable_entity_loader 变量设置为 true 以防止实体扩展。

2. 使用 Burp Proxy 的拦截功能是提交 XML 注入代码片段的关键。

3. XXE 漏洞可能允许攻击者暴露服务器上的敏感文件、使应用程序发生拒绝服务（DoS）攻击，或者有时获得远程代码执行（RCE）。

4. /dev/random 是一个特殊的系统位置，用作伪随机数生成器。

5. 使用简单的实体替换测试 XXE 是验证 XXE 漏洞的轻量级方式。

6. “亿次笑声”攻击不仅仅是 XML 特有的，它是利用嵌套实体消耗指数级内存并使解析服务发生拒绝服务（DoS）攻击的手段。

7. 即使某些服务明确使用 JSON 来传递数据，它们的底层服务器通常也能够使用不同的数据格式。有时，仅仅通过使用不同的 Content-Type 头部，就可以解锁这些格式。

第八章

1. 通过模糊化实现的安全性是一种有效的方式来阻止机会性攻击，但它不能成为健全安全策略的基础。

2. API 密钥、访问令牌、密码以及账户和应用数据通常是用于漏洞奖励的内容。

3. Burp Proxy 包含设置，用于被动地发现隐藏字段——一个简单的黑客技巧。

4. API 密钥授予对 API 或服务的完全访问权限。访问令牌通常与更个性化或基于角色的身份验证系统相关联，尽管这并不是一个绝对的区分标准。

5. 通用错误代码和描述、浏览器的“自动填充”功能以及通常不提供相关攻击场景的信息，通常不值得奖励。

6. 绝对不能信任用户输入。

7. Web 应用程序是漏洞百出的，但错误消息、隐藏字段和客户端源代码是敏感信息潜藏的地方。

第九章

1. CVE 代表公共漏洞和暴露。它是一个系统，允许不同的工具和组织共享已知漏洞的数据。

2. WordPress 被互联网上大量网站使用，因此成为黑客攻击的丰富目标。此外，作为动态类型语言的 PHP 也有其自身的弱点。

3. wpscan CLI 允许更好地与现有的自动化套件集成，但 Burp 扩展更好地支持被动扫描功能。

4. 在探测漏洞时，始终牢记 Rails 的意见结构和会话认证的历史性弱点。

5. Docker 提供了一个简单的容器化结构，用于封装工具可能需要的任何依赖集，使其更加便携和可扩展。

6. OVAL 代表开放漏洞评估语言，是一系列用于标准化、机器可读的已知漏洞测试定义。

7. 将 Django 的 DEBUG 模式保持开启是一个常见问题，可能为攻击情景提供潜在路径。此外，还应注意与 Django 默认管理页面相关的任何暴露的管理员功能。

第十章

1. RCE 代表远程代码执行。

2. 链接到 OWASP 或其他受尊敬的安全组织关于特定漏洞种类的页面，可以帮助所有参与漏洞验证的人达成共识。

3. 每个漏洞报告提交必须至少包含漏洞类型、描述、时间戳、攻击场景和重现步骤。

4. VRT 是 Bugcrowd 创建的一套标准，旨在促进研究人员、开发人员和其他安全利益相关者对漏洞严重性有一个共同的理解。CVSS 是一个类似且兼容的系统。

5. 如果内部团队无法重现你的问题，他们无法确定其严重性和影响。

6. 写得好的攻击场景是具体的、技术知情的、有文档支持的并且是现实的。它们传达了情况的严重性，而不会过度扩展。

7. HackerOne 的 Hacktivity 部分和 Vulnerability Lab 的主页等是记录生产漏洞的优秀资源。

8. 截图、纯文本文件和其他支持文档在漏洞报告中都非常重要。

第十一章

1. 在考虑采用任何工具时，问自己一系列问题非常重要，分析它如何融入现有的工作流，它能带来什么价值，它如何独特地为这种价值做出贡献，等等。

2. Burp Notes、Burp Python Scripter 和 JSON Beautifier（多个美化器中的一个）只是我们覆盖的几个优秀扩展。

3. nmap 和 Aircrack-ng 都是网络渗透测试的最佳实践工具。

4. Burp Pro 提供了 Burp 扫描器、自动化 PoC 生成以及其他一些有用的高级手动工具。

5. Kali Linux 配备了许多研究人员依赖的工具。它还可以从磁盘启动的事实使其成为任何渗透测试实验室的轻量级解决方案。

6. OSINT 代表开放源代码情报，是指从公开可获得的来源（如社交媒体个人资料和公共记录数据）收集关于目标的信息的过程。

7. Metasploit 自称为一个漏洞利用框架，旨在检测和生成利用漏洞的代码。作为一个在利用阶段表现出色的工具，我们在本书中对它的涉及较少。

第十二章

1. DoS/DDoS 攻击需要广泛的预防措施，而且由于恶意流量常常伪装成合法业务流量，因此很难进行缓解。这使得它超出了范围——除非某个特定的漏洞使得服务更容易受到 DoS/DDoS 攻击。

2. Self-XSS 的影响范围过于有限，并且需要太多步骤，不能算作一个严重漏洞。用户最终是在执行 XSS 时让自己处于风险之中，而并不会对其他人造成实际影响。

3. OPTIONS 请求可能会暴露调试信息，这些信息可能帮助攻击者，但单独来看，这并不是一个漏洞。

4. 像 BEAST 这样的 SSL 漏洞需要其他多个受影响点才能构成攻击场景。

5. Clickjacking 是指攻击者将恶意链接隐藏在透明或遮挡的链接下方，并放置在一个合法且安全的按钮之下，使得用户被欺骗点击到黑帽 URL。

6. 物理测试涉及闯入公司的实际办公室或建筑，通过现场设备获取网络访问权限。对于公共漏洞奖励计划，这是完全不在范围之内的。

7. 如果 CSRF 漏洞与匿名表单或其他未授权输入相关，那么攻击场景不足以支持支付奖励。

8. 黑暗模式是旨在欺骗或诈骗用户的用户体验设计。

9. 大多数服务可以通过暴力破解进行攻击，前提是有足够的时间和资源。指出这一点并不构成有用的、可执行的安全建议。

第十三章

1. SANS Institute、Bugcrowd 博客、Darknet、HighOn.Coffee 等，都是获取最新技术教程和安全新闻的良好来源。

2. 公共漏洞奖励计划不授予研究人员对源代码的特权访问权限，严格来说，它们是黑盒类型的。

3. RCE（远程代码执行）允许进行一系列令人震惊的攻击。借助图灵完备的脚本语言的全部功能，攻击的破坏力是没有限制的。

4. 这里的“安全港”用来描述一种政策，即公司不会起诉那些遵循特定条款的研究人员。

5. 跨源资源共享（Cross-Origin Resource Sharing，CORS）是一个系统，用于管理来自不同源（主机名、端口等）的资源请求的安全过程。

6. 一个组织的安全态势指的就是它阻止、检测和应对数字威胁的能力。

7. 对应用进行指纹识别可以提供服务器软件和版本信息、应用语言、数据库信息及其他有用的数据点，以帮助制定渗透测试策略。

8. OSCP 代表进攻性安全认证专业人员，这是由进攻性安全公司提供的专业认证。