网络应用对当今的文明至关重要。我知道这听起来很大胆，但当你想到这项技术如何改变了世界时，毫无疑问，全球化是通过互联网在世界大部分地区进行远距离信息快速交换的原因。虽然互联网是许多东西，但最具内在价值的组件是那些数据所在的组件。自 20 世纪 90 年代万维网问世以来，这些数据呈爆炸式增长，世界目前在未来两年内产生的数据超过所有有记录的历史数据。虽然数据库和对象存储是这些惊人数量数据的主要存储库，但 web 应用是门户，通过它们可以对数据进行操作，并将其处理为可操作的信息。这些信息在最终用户的浏览器中动态地呈现给他们，这种信息所包含的相对简单性和访问性是 web 应用无法避免的主要原因。我们如此习惯于 web 应用，以至于我们中的许多人都会发现，如果没有这些应用，我们不可能超过几个小时。

金融、制造业、政府、国防、商业、教育和娱乐机构都依赖于 web 应用，这些应用允许它们相互运行和交互。这些无处不在的门户可以存储、处理、交换和呈现各种敏感信息和有价值的数据，同时保护它们免受伤害。工业界对这些系统非常信任。因此，对这些系统的任何损害或任何形式的信任违反都可能而且经常会造成深远的经济、政治或身体损害，甚至可能导致生命损失。每天都有关于网络应用受损的突发新闻充斥着这条新闻。每一次攻击都会导致这种信任的丧失，因为数据（从金融和健康信息到知识产权）被窃取、泄露、滥用和披露。公司受到无可挽回的伤害，患者受到威胁，职业生涯结束，命运改变了。这东西很重！

虽然有许多潜在问题使架构师、开发人员和运营商处于紧张状态，但其中许多问题发生的概率非常低�� 除了一个例外，犯罪和地缘政治行为人和活动家对计算机系统、网络和所有其他与之相连或利用它们的人或物构成了明显的危险。糟糕的编码、不恰当的实施或缺少应对措施都是这些对手的福音，为他们的活动提供了进入或掩护。当潜在的攻击者看到肆虐的机会时，他们会投入更多资金，自我教育，开发新技术，然后实现更雄心勃勃的目标。这个循环会重复。保护网络、系统和应用免受这些威胁是一项崇高的事业。

防御方法也存在，可以帮助降低风险和减少暴露，但渗透测试人员（也称为白帽黑客确保他们能够胜任任务。通过像攻击者一样思考，并使用许多相同的工具和技术，笔测试人员可以发现设计或实现中的潜在缺陷，并允许应用涉众在恶意黑客（也称为黑帽黑客）之前填补这些漏洞安全是一个旅程，而不是目的地，笔测试人员可以作为引导其他利益相关者走向安全的向导。

在本书中，我假设您是一位感兴趣或经验丰富的渗透测试人员，希望使用 Kali Linux（当今最流行的开源渗透测试平台）专门测试 web 应用。Kali Linux 及其工具的基本设置和安装在许多其他地方都有介绍，无论是 Packt 自己的使用 Kali Linux 进行的 Web 渗透测试-第二版（由Juned Ahmed Ansari编写，可在上获得） https://www.packtpub.com/networking-and-servers/web-penetration-testing-kali-linux-second-edition 或大量书籍和网站之一。

在第一章中，我们将了解以下内容：

• 领先的 web 应用体系结构和趋势
• 通用 web 应用平台
• 云和私有托管解决方案
• 共同防御
• 在本书中，我们将对建筑软点的高级视图进行评估

Web 应用在过去 15 年中有了很大的发展，从早期的单片式设计发展到分段式设计，目前在更专业的部署实例中占据了市场主导地位。他们还看到了这些架构元素的托管方式的转变，从纯本地服务器到虚拟化实例，到现在的纯云或混合云部署。我们还应该理解，客户在这个体系结构中的角色可能会有很大的不同。这一演变提高了规模和可用性，但所涉及的额外复杂性和可变性可能会对不那么勤奋的开发人员和运营商不利

整个 web 应用的体系结构可能在物理上、逻辑上或功能上是分段的。这些类型的分割可能以组合形式出现；随着跨应用集成在企业中如此普遍，这些边界或特征可能始终处于过渡状态。这种细分有助于提高可伸缩性和模块化，划分管理域以匹配人员或团队结构，提高可用性，还可以提供一些急需的细分，以在出现妥协时提供帮助。这种模块化的程度以及功能在逻辑和物理上的划分方式在很大程度上取决于所使用的框架。

让我们讨论一些更常用的逻辑模型以及这些模型实现的一些突出框架。

大多数小型或即席 web 应用在某一点或另一点上托管在物理或虚拟服务器上，并在单个单片安装中，这通常在简单的自托管应用中遇到，如小型或中型企业网页、库存服务、票务系统等。随着这些应用或其相关数据库的增长，有必要分离组件或模块，以更好地支持扩展，并与相邻的应用和数据存储集成。

这些应用倾向于使用常用的交钥匙 web 框架，如 Drupal、WordPress、Joomla！，Django 或许多其他框架，每个框架都包括一个内容交付管理器和语言平台（例如 Java、PHP:超文本预处理器（PHP）、活动服务器页面（ASP.NET）等），以超文本标记语言（HTML生成内容，以及他们支持的一种或多种数据库类型（各种服务器查询语言（SQL）、Oracle、IBM DB2，甚至平面文件和 Microsoft Access 数据库）。作为单个映像或安装介质提供，所有功能都驻留在相同的操作系统和内存空间中。为该模型选择的平台和数据库组合通常更像是开发人员能力和偏好的问题。在负责团队中收集社会工程和开源信息肯定会有助于描述 web 应用的体系结构

下图显示了简单的单层或独立体系结构：

独立体系结构是历史上第一个遇到的，并且通常是任何应用发展的第一步。

从概念上讲，三层设计仍然用作参考模型，即使大多数应用已迁移到其他拓扑或尚未从独立实现演变而来。虽然许多应用现在偏离了这个经典模型，但我们仍然发现它对于理解实际应用所需的基本设施很有用。我们称之为三层模型，但它也假设了第四个未命名的组件：客户端

这三层包括 web 层（或前端）、应用层和数据库层，如下图所示：

三层体系结构提供了现代企业应用所需的更大的可扩展性和专业化。

每一层的作用都需要考虑：

• Web 或表示层/服务器/前端：此模块提供用户界面（UI）、身份验证和授权、可扩展性以适应大量用户、高可用性功能（处理负载转移、内容缓存和容错），以及必须为客户机提供或用于与客户机通信的任何软件服务。HTML、可扩展标记语言（XML）、异步 JavaScript 和 XML（AJAX）、通用样式表（CSS）、JavaScript、Flash、其他呈现内容和 UI 组件都驻留在这一层，它通常由 Apache、IBM WebSphere 或 Microsoft IIS 托管。实际上，这一层是用户通过浏览器看到的，并与之交互以请求和接收他们想要的结果。
• 应用或业务层/服务器：这是 web 应用的引擎。由 web 层部署的请求在此执行，这是业务逻辑、流程或算法所在的位置。该层还充当到多个数据库甚至其他应用的桥接模块，无论是在同一组织内还是与受信任的第三方。C/C++、Java、Ruby 和 PHP 通常是用于完成繁重工作并将数据库层的原始数据转换为 web 层呈现给客户机的信息的语言。
• 数据库层/服务器：各种形式的海量数据存储在称为数据库的专用系统中。这些信息的宝库是经过安排的，因此它们可以快速访问，但可以不断扩展。经典的 SQL 实现，如 MySQL 和 ProstgreSQL、Redis、CouchDB、Oracle 和其他常用于存储数据，以及帮助组织和访问数据的各种抽象工具。在数据收集和处理的高端，越来越多的超标量数据库架构不仅涉及 SQL（NoSQL），还涉及 Hadoop 等数据库抽象软件。这些通常存在于任何声称是大数据或数据分析的东西中，如 Facebook、谷歌、NASA 等。
• **客户端：**所有三层都需要一个观众，而客户端（更具体地说，是他们的浏览器）是用户访问应用和进行交互的地方。浏览器及其插件软件模块支持 web 层按照应用开发人员的意图显示信息。

供应商采用此模型并对其进行修改，以突出其优势或更紧密地传达其战略。例如，Oracle 和 Microsoft 的参考 web 应用体系结构都将 web 和应用层合并为一个层，但 Oracle 提请注意其在数据库方面的优势，而 Microsoft 则花了大量精力扩展其可为客户增加价值的补充服务列表（和微软的收入）包括负载平衡、身份验证服务，以及在全球大多数客户机上与自己的操作系统的连接

模型视图控制器（MVC设计是一个引导信息与曝光分离的功能模型，在一定程度上，还通过角色分离来解决干系人用户的特权。这允许应用防止用户及其输入与后端业务流程、逻辑和事务混合，从而使早期的体系结构暴露于数据泄漏中。MVC 设计方法实际上是由厚应用软件开发人员创建的，它不是服务和组件的逻辑分离，而是基于角色的分离。现在，web 应用通常必须在跟踪和强制执行角色的同时进行扩展，web 应用开发人员已经根据其使用情况对其进行了调整。MVC 设计还促进了代码重用和并行模块开发。

MVC 设计如下图所示：

模型-视图-控制器设计侧重于角色，而不是功能，并且通常与功能体系结构相结合。

在 MVC 设计中，四个组件如下：

• 模型：该模型维护和更新数据对象，作为应用的真实来源，拥有使应用有价值的规则、逻辑和模式。它不了解用户，而是接收来自控制器的调用，以处理针对其自身数据对象的命令，并将其结果返回给控制器和视图。另一种方式是模型决定应用的行为。
• 视图：视图负责将信息呈现给用户，因此，它负责内容交付和响应：获取控制器的反馈和模型的结果。它构建了用户查看和交互的界面。视图是用户看到应用工作的地方。
• **控制器：**控制器充当视图与模型之间的中心链接；在从视图的用户界面接收输入时，控制器将这些输入调用转换为模型所处理的请求。这些请求可以更新模型并根据用户的意图采取行动，或者更新呈现给用户的视图。控制器使应用具有交互性，允许外部世界刺激模型并改变视图。
• **用户：**与其他早期车型一样，用户是设计的推断组件；事实上，整个设计将围绕如何允许应用向客户交付价值而展开。

请注意，在 MVC 模型中，很少有关于软件模块的细节，这是有意的。通过关注角色和职责分离，软件（现在是 web）开发人员可以自由创建自己的平台和架构，同时使用 MVC 作为基于角色细分的指南。将此与独立或三层模型（分解应用的操作）进行对比，我们将看到它们以非常不同的方式思考相同的事情。

MVC 所灌输的一点是状态感，这意味着应用需要跟踪会话信息以实现连续性。这种连续性促使人们需要 HTTP Cookie 和令牌来跟踪会话，这本身就是我们的应用开发人员现在应该找到的安全方法。大量使用应用编程接口（API）也意味着现在存在更大的攻击面。如果应用只显示存储在数据库层中的一小部分数据，或者应该更有选择性地填充该信息，通过在模型中维护太多在错误配置或破坏时可以访问的信息来避免泄漏。在这些情况下，MVC 通常被当作一种方法论来回避，因为它很难管理其中的数据暴露。

应该注意的是，MVC 设计方法可以与功能的物理或逻辑模型相结合；事实上，使用一些 MVC 设计原则的平台为当今大多数 web 应用提供了动力

应用或其模块的位置直接关系到我们作为渗透测试人员的角色。目标应用可能位于连续统一体上的任何位置，从物理到虚拟，到云托管组件，或者三者的某种组合。最近，出现了第四种可能性：集装箱。托管选项的连续体及其相对规模和安全属性如下图所示。请记住，此处显示的日期与每种可能性的流行程度有关，但任何托管可能性都可能共存，而且实际上，也可以在云端或内部数据中心托管

下图显示了这种演变：

托管选项已经发展到更好地支持灵活和动态部署—大多数客户部署在多个位置。

多年来，应用架构和设计选择只需要考虑物理的、无骨的主机来运行体系结构的各个组件。作为 Web 应用的缩放和合并的专用平台，附加的主机被添加以满足需要。随着数据集变得更加多样化，新的数据库服务器被添加，需要额外的应用服务器来合并额外的软件平台，等等。劳动力和硬件资源专用于每个附加实例，但它们增加了数据中心的成本、复杂性和浪费。工作负载依赖于专用资源，这使得它们既脆弱又不灵活。

虚拟化彻底改变了这种模式。通过允许将硬件资源集中并逻辑分配给多个来宾系统，单个硬件资源池可以在一个同质的服务器池中包含所有不同的操作系统、应用、数据库类型和其他应用需求，它以优先的方式为多个组织提供集中管理和动态分配接口和设备。特别是 Web 应用从中受益，因为虚拟化的灵活性提供了一种创建并行应用环境、数据库克隆等的方法，用于测试、质量保证和浪涌容量的创建。由于系统管理员现在可以在同一个资源池上管理多个工作负载，因此硬件和支持成本（例如电源、占地面积、安装和资源调配）也可以降低，前提是许可成本不会抵消固有的效率。许多应用仍在虚拟本地环境中运行。

值得注意的是，随着安全相关方面责任的转移，虚拟化也在应用、系统管理和网络团队之间引入了新的紧张关系。因此，可能无法清楚地理解、正确履行职责，甚至无法对职责进行说明。听起来是一个很棒的笔测试机会！

亚马逊在 2006 年进一步提出了虚拟工作负载托管的概念，并引入了云计算，微软 Azure 和其他公司紧随其后。交钥匙软件即服务（SaaS的承诺通过互联网在高度可生存的基础设施中运行，使公司能够构建应用，而无需投资硬件、带宽甚至房地产。云计算本应取代私有云（传统的内部部署系统），一些组织确实做到了这一点。然而，对于大多数企业来说，主流趋势是私有云和公共云之间的应用出现分裂，基于这些服务的类型和稳态需求。

容器提供平行或交替包装；容器并没有包含整个操作系统和虚拟机中常见的仿真硬件，而是带来了它们独特的属性，并共享这些通用的辅助设备和功能，从而使它们变得更小、更灵活。这些特性使得谷歌和 Facebook 等大公司能够实时扩展，以满足用户微秒级的响应时间需求，并完成容器工作负载生成和销毁的自动化。

那么，这一切对我们意味着什么？web 应用的位置和打包会影响其安全状态。私有和公共云托管的应用通常都会与可能跨这两个域的其他应用集成。这些集成点提供了必须测试的潜在威胁向量，否则它们肯定会成为攻击的受害者。云托管应用也可能受益于服务提供商托管或提供的保护，但它们也可能限制可支持的各种防御选项和 web 平台。理解这些约束可以帮助我们专注于探索和消除不必要的工作。托管模式还决定了我们遇到的防守队员和操作员团队的组成。云托管公司可能有更强大的安全运营中心，但应用安全责任的划分可能会导致情报的碎片化，并提供一个可用于攻击目标的缺口。可用的底层虚拟化和操作系统还将影响应用平台的选择、周围的安全机制等。

应用开发人员遵循有助于根据计划和预算保持进度的流程。毫无疑问，每个开发应用的公司都有自己的流程，但这些流程的共同要素将是不同的阶段：从开始到交付/运营，以及任何所需的评审、可交付预期、测试流程和资源需求

web 应用中常用的开发过程是下图所示的应用或软件开发生命周期（SDLC），从中捕获 https://commons.wikimedia.org/wiki/File:SDLC_-_ 软件开发生命周期.jpg：

每个现代应用开发人员都遵循 SDLC 或类似的标准。

无论在公司的开发过程中定义了什么阶段，在每个阶段都必须包含测试，包括渗透测试，以尽可能降低过程中最具成本效益阶段的风险

我看到政府开发项目由于在周期的早期阶段对安全性和安全性测试考虑不足而很快超出了预算。在这些项目中，项目管理层经常将任何安全性测试推迟到产品离开实施阶段之后，相信测试阶段的名称涵盖了所有核查活动。在此阶段捕获 bug、缺陷或安全漏洞需要大量返工、重新设计或变通，这些都会严重影响进度和预算。

降低威胁和影响总体进度的成本是早期测试的最基本原因，并且通常是开发周期的一部分。如果您是一名在多学科团队中工作的测试人员，那么早期和协调的渗透测试可以消除缺陷，并在安全问题变得具体和昂贵之前解决它们。渗透测试要求应该是任何验证和验证测试计划的一部分。此外，开发团队应该在整个需求和设计阶段包括应用安全专家，以确保应用的设计考虑到安全性，这是 web 应用渗透测试人员非常适合提供的观点

有来自开放式 Web 应用安全项目（OWASP、等组织的参考资料 https://www.owasp.org/index.php/Testing_Guide_Introduction))、SANS（https://www.sans.org))和美国计算机应急响应小组（ https://www.us-cert.gov/bsi/articles/best-practices/security-testing/adapting-penetration-testing-software-development-purposes))可用于帮助指导渗透测试流程适应公司自身的开发周期。此早期且经常采用的策略的价值应易于向管理层阐明，但有关应对特定 web 应用漏洞和安全风险的具体建议，可在安全报告中找到，如 WhiteHat security，Inc.编制的安全报告（见 https://info.whitehatsec.com/rs/675-YBI-6img/WH-2016-Stats-Report-FINAL.pdf) ）以及来自 Verizon、Cisco、Dell、McAfee 和 Symantec 等主要公司。在整个开发过程中，必须有公司赞助，以确保充分且持续地考虑网络安全。

测试不应该只完成一次就勾选复选框，而且永远不会重来。Web 应用非常复杂；它们重用大量组织和项目提供的重要代码库。近年来，漏洞肯定有所增加，2014 年和 2015 年是攻击使用中的常见开源库的非常活跃的年份。诸如 Heartbleed、SSLPoodle 和 Shellshock 等攻击都利用了这些开源库，在某些情况下，这些库为当前 80%以上的 web 应用提供了强大的支持。管理员升级服务器可能需要几年的时间，而且随着编目弱点数量的增加，很难做到这一点。例如，2016 年是 Adobe Flash、Microsoft internet Explorer 和 Silverlight 漏洞的一年。整个社区不可能监控这些基本构建块的每一个用例，web 应用的所有者可能一开始就不知道包含了这些模块

应继续定期分析一组测试的申请，以确定其随时间的风险暴露。同样重要的是，确保尽可能多地使用不同的测试方法（如果不是不同的团队的话），以确保所有角度都得到考虑。该测试通过在测试和发展阶段提供所需的安全反馈来帮助完成 SDLC，以确保在合并新功能的同时，该应用的开发也使潜在攻击者领先一步。强烈建议您建议您的客户为该测试提供资金或支持，并雇佣内部和部分外部测试团队，以便将这些发现纳入补丁和修订计划，就像功能增强一样。

Web 应用渗透测试侧重于对应用、其软件框架和平台的全面评估。除了网络、无线或客户端（恶意软件）测试之外，Web 渗透测试已经发展成为一门专门的学科。我们很容易理解为什么最近的趋势表明，几乎 75%的网络攻击集中在 web 应用上。如果你从黑客的角度来看，这是有道理的：

• 门户和工作流是非常定制的，在开发过程中将它们与所有向量隔离是一项不小的壮举。
• Web 应用必须对外公开，以使用户能够实际使用它们。过多的安全被视为是一种负担，也是开展业务的潜在障碍。
• 防火墙和入侵系统对基于网络的攻击非常有效，不一定涉及 web 门户的交付。
• 这些应用向外部用户提供潜在的专有或敏感数据。这是他们的工作，因此利用这种信任可以公开大量高价值信息。
• Web 应用攻击通常会暴露整个数据库，而不会造成基于文件的漏洞，这使得归属和取证更加困难。

本章的大部分内容旨在向您介绍目标的体系结构方面。深入了解客户的应用将使您能够将精力集中在最有意义的测试上。

让我们再看看一个典型的三层应用架构（如下图所示），看看我们应该研究哪些潜在问题：

*

有害的 web 应用攻击集中在应用体系结构的各个方面——我们也将如此。

这些潜在载体是我们将要测试的主要威胁之一；在某些情况下，我们将包含一系列类似的攻击类型。它们的显示与三层设计中攻击通常生效的典型位置有关，但攻击者本身通常位于公共 web 层，与合法客户端非常相似。我们将继续讨论的攻击类别如下所示：

• 身份验证、授权和会话管理攻击：这些攻击（以及我们的测试）侧重于应用本身验证身份和强制执行特定用户权限的严格程度。这些测试将侧重于说服网络层我们属于对话。
• 跨站点脚本（XSS）攻击：XSS 攻击涉及操纵客户端或 web 和/或应用层，将有效会话的流量或注意力转移到恶意位置，从而允许攻击者通过脚本攻击有效客户端。劫持企图通常也属于这一类。
• 注入和溢出：通过注入底层模块可能允许但应用实现应禁止的代码，在整个三层设计中发现各种攻击，迫使应用在测试边界之外工作。大多数注入（SQL、HTML、XML 等）都会迫使应用泄露不允许的信息，或者帮助攻击者找到管理权限，自行启动直接转储。
• 中间人（MITM）攻击：会话劫持是黑客或测试人员在不知情的情况下拦截会话的一种手段。这样做之后，黑客有能力操纵或模糊请求和响应，操纵一方或双方，并发现比合法用户实际拥有或有权拥有的数据更多的数据。
• 应用层攻击：有些应用没有配置为正确验证输入，无论是在验证如何输入操作或如何授予文件访问权限时。应用在实施真正的基于角色的控制方面也很常见；特权升级攻击经常发生，让黑客可以掌控局面。* *## Web 应用防御

如果我们退后一步，想想客户所面临的是什么，这确实是令人震惊的。构建一个安全的 web 应用和网络就像构建一个核反应堆工厂。没有一个细节是微不足道的，因此一个微小的故障（裂纹、弱焊接或小污染），尽管设计和实施中固有的所有优点，可能意味着失败。类似的事实也会影响 web 应用的安全性�� 仅仅一个缺陷，无论是错误配置还是众多组件中的遗漏，都可以为攻击者提供足够的缺口，从而造成巨大的伤害。除此之外，还有一个额外的问题，即在许多环境中，同样的主动防御措施也被用来帮助检测这些罕见事件（有时称为黑天鹅事件）。网络和应用管理员的工作很艰巨，我们的目的是帮助他们和他们的组织更好地完成这项工作。

Web 应用框架和平台包含一些条款，以帮助保护它们免受恶意参与者的攻击，但它们很少单独部署在生产系统中。我们的客户通常会部署网络防御系统，这些系统还可以增强其应用的保护、意识和抵御攻击的能力。在大多数情况下，客户会将更多的元素与更深入的防御联系起来，并承担更高级别的保护。与他们的应用平台提供的措施一样，这些附加系统只与负责安装、配置、监控这些系统并将其整体集成到体系结构中的流程和人员一样好。最后，考虑到这些应用在企业中的特殊地位，客户的各种利益相关者很有可能有错误的解决方案来防止我们将要测试的攻击形式。我们必须努力评估目标并教育客户。

那么，系统的哪些要素适合这里？下图显示了相对于三层设计，web 应用路径中涉及的最常见元素：

最严重的 web 应用将包括阻碍我们工作的防御措施，但所有安全元素都只与它们的最新补丁、配置和监控它们的运营商一样好。

典型 web 应用防御中的关键外部元素包括：

• 防火墙（FW）：关注安全的第一个要素通常是周界或互联网边缘防火墙，负责实施多种访问控制和策略，以减少企业（包括 web 应用）的整体攻击面。防火墙市场的最新进展使防火墙成为下一代防火墙（NGFW），其中这些策略不再由严格的源和目标端口以及 IP 地址对定义，而是以上下文方式定义，包含更多人类可读的元素，如对话中的用户或组、外部参与者的地理位置、声誉或类别，以及对话的应用或目的。
• 负载平衡器：许多规模化设计都依赖负载平衡器为一组 web 服务器提供无缝的工作负载分配。虽然这样做是为了让应用能够接触到更多的用户，但此功能通常与一些类似代理的功能相对应，这些功能可以使实际的 web 层资源不被黑客窥视。除了虚拟 IP 或反向代理功能外，一些负载平衡器解决方案还包括以安全为中心的服务。从功能上讲，它们可能包括 web 应用防火墙功能。负载平衡器在帮助提供分布式拒绝服务（DDoS方面也很重要扩展、转移或吸收恶意流量负载的保护。
• **Web 应用防火墙（WAF）：**WAF 提供应用层检查和攻击预防，以确保我们在本书中尝试的许多漏洞攻击要么不可能实现，要么难以实现。这些防火墙不同于外围的网络防火墙，因为它们只检查 HTTP/HTTPS 流是否存在攻击。WAF 往往非常依赖于特征码，必须与其他防御解决方案相结合，以覆盖其他载体。

上图中未显示的是额外的防御措施，这些措施可以作为防火墙上的功能运行，也可以在环境的一个或多个阶段独立运行。各种供应商在各种市场类别和能力集中销售这些解决方案。虽然品牌可能有所不同，但它们可分为两大类：

• 入侵检测/预防系统（IDS/IPS）：这些关键元素为企业提供了深度数据包检测能力，以检测原子和基于模式（异常）的威胁。在一个经典的实现中，这些对 web 应用没有什么价值，因为它们无法洞察黑客用来发起常见 web 应用攻击的看似有效的有效负载的各种操作。下一代 IPS（NGIPS）可能会提供更多的保护，以抵御某些威胁，因为它们不仅处理经典的 IDS/IPS 算法，而且结合上下文和滚动基线来识别异常交易或交互。这些工具也可以集成在网络防火墙内或环境层之间。较新的 NGIPS 技术可能具有检测常见 web 漏洞的能力，这些工具在保护使用未修补或错误配置的软件模块的目标系统方面显示出巨大的价值。
• 网络行为分析（NBA）：这些工具利用来自网络元素的元数据来查看趋势并识别异常行为。从系统日志和流提要（Neflow/IPFIX、sFlow、jFlow、NSEL 等）收集到的信息不会提供 IPS 可以收集到的深度数据包信息，但通过网络从许多流收集到的趋势和模式可能会提示运营商非法升级凭据。在 web 应用中，NBA 工具可能会识别出更严重的权限攻击，以及文件和目录抓取攻击。

提到的所有组件都可以以多种形式实现：从各种物理设备类型到虚拟机，再到云产品。更复杂的 web 应用通常会采用不同的多层结构，以提供更强的抗攻击能力，并为地理位置分散的托管站点安排提供总体功能。例如，一家公司可能有 10 个地点是全球负载平衡的，以服务于客户。在这种情况下，基于云的负载平衡器、WAF 和防火墙可以提供第一层防御，而每个数据中心可能都有额外的层，不仅提供本地 web 应用保护，还提供特定于该站点的其他关键服务。

这些组合是无限的，但请记住，随着部署的安全解决方案的复杂性的增加，它们被错误配置的可能性也会增加。我们的侦察工作和后续渗透测试计划需要考虑这些变量。

因为这是一本关于为了进行 web 应用渗透测试而掌握Kali Linux 的书，所以我们从基础主题开始，比如体系结构、安全元素等，可能会让人感到惊讶。我希望，涵盖这些主题将有助于将我们与那些经常参与笔试但价值最低的脚本小子区分开来。任何人都可以激发 KALI Linux 或其他分发，并开始黑客攻击，但没有这个基础，我们的测试运行的风险是不完整的或不准确的。我们的高收入工作依赖于帮助客户将他们的网络推向他们（约定的）极限，并帮助他们发现他们的弱点。同样，我们也应该向他们展示他们做得对。布莱克山信息安全公司（Black Hills Information Security）的所有者兼分析师约翰·斯特兰德（John Strand）喜欢这样说

我们应该努力在表现出色后被抓住

. 

虽然对工具和底层协议的了解往往是一个严重黑客与新手区别开来的原因，但这也是他们对猎物的了解以及他们提供的服务的深度。如果我们只是为客户运行脚本并报告突出的问题，那么我们就失去了成为一名雇佣渗透测试人员的意义。是的，关键缺陷需要解决，但看似较小的缺陷也需要解决。需要专家来检测一个潜在的缺陷，该缺陷现在不会影响性能，但会在一段时间后导致重大灾难。这不仅适用于发电厂，也适用于我们的 web 应用。我们不仅需要向他们展示他们自己能看到的东西，还要进一步帮助他们抵御明天的袭击。

在本章中，我们讨论了一些架构概念，这些概念可能有助于我们更好地了解我们的目标。我们还讨论了我们的客户可以采取的各种安全措施，我们需要了解这些措施，我们的讨论还包括在应用的整个生命周期中进行测试的重要性。这样做可以节省时间和金钱，并且在应用投入生产后肯定可以节省声誉并将风险降至最低。这些考虑应该值得让渗透测试人员成为任何开发团队的重要和永久成员。

在下一章中，我们将简要讨论如何准备一个功能齐全的沙盒环境，以帮助我们实践测试概念。我们还将讨论可以帮助我们提供全面测试覆盖率的主要测试框架。最后，我们将讨论合同以及我们工作的道德和法律方面；远离监狱是一个关键目标。*