SQL-注入策略-二-

布客飞龙
102 阅读49分钟

SQL 注入策略（二）

原文：annas-archive.org/md5/8346460628ce82f0f83fee4bb3858144

译者：飞龙

协议：CC BY-NC-SA 4.0

第六章：将所有内容整合

到这里，我们终于走到了探索 SQL 注入秘密的旅程的尽头。到现在为止，你已经体验过 SQL 注入是什么，它在应用程序或更复杂系统中的含义，它可能对安全性带来的后果，以及为减轻或完全防止其影响所能采取的对策。

本章是对你通过阅读本书所学内容的总体回顾。它将通过简要总结和分析我们所见的内容来实现这一点，希望能够从批判性的角度审视一切，同时考虑到不仅是 SQL 注入的更广泛影响，还有在一个始终依赖信息技术和数据的世界中，安全漏洞的一般性问题。

其目标不仅是帮助你以结构化且易于跟随的方式简要回顾本书的知识和实践内容，还通过批判性地审视这些概念，为你提供思考的空间，并赋予这些概念更深层次的意义。毕竟，本书的目的是掌握 SQL 注入，不仅从技术角度，还要确切地了解它的含义。

本章涵盖以下主题：

  • SQL 注入——理论视角：在这一部分，将总结 SQL 注入的理论方面，描述 SQL 注入背后的主要概念，并提供相关评论。

  • SQL 注入——实践视角：在这里，我们将简要描述并讨论更实用的方面，尤其是从含义和影响的角度。我们还将突出与现实世界相关的方面，不仅涉及 SQL 注入的测试和对策，还包括更普遍的漏洞问题。

  • SQL 注入和安全影响——最终评论：最后，一些额外的最终评论将帮助你专注于本书的真正目标，并理解成为网络安全专家意味着什么，以此激发你对这一诱人领域的兴趣。

SQL 注入——理论视角

总结我们在本书第一部分中讨论的所有理论方面可能看起来有些困难。在这里，我们将按照我们遇到这些内容的顺序概述我们所覆盖的内容。

一般的 SQL 注入

首先让我们回顾一下什么是 SQL 注入，以及它为什么存在。SQL 注入本质上是由 SQL 引起的，SQL 是一种负责与关系型数据库模型交互的语言。SQL 是一种非常强大的语言，能够执行广泛的操作，包括在数据库中创建（CREATE）和插入（INSERT）信息，删除（DROP用于表和数据库，DELETE用于单条记录），修改（ALTER）或者在应用程序中更常见的，只是选择和查询（SELECT）其内容，并提供许多不同的选项。SQL 注入允许恶意用户在现有操作中注入原本未被应用程序设计所预见的操作，可能会导致有害的命令。

SQL 注入的常见用途包括让恶意用户获取本应保密的信息（例如访问凭证或个人信息），以及直接利用应用程序逻辑，绕过身份验证检查，甚至无需插入任何凭证。这还包括在未征得所有者同意的情况下修改数据库，可能导致通过不可修复的方式破坏应用程序功能（例如，删除包含所有访问信息的表，或删除对应用程序正常运行至关重要的信息），从而使应用程序无法使用。

尽管存在不同的基于 SQL 的数据库系统（例如 MySQL、SQLite、Oracle 数据库和 Microsoft SQL Server），从用户的角度来看，它们的主要区别仅在于查询语法。在某些情况下，一些字符被保留用于不同的目的（例如注释），而某些内置函数可能会因实现不同而有所差异。无论如何，它们的功能背后的逻辑大致相同——可以将它们的查询语言视为同一种语言：SQL 的地方方言。

SQL 是应用程序与支持的数据库系统进行交互的主要工具。SQL 注入是一种软件漏洞，因为恶意负载是在应用层注入的，绕过了通常由软件允许的有限操作集。数据库只会评估发送给它的 SQL 代码，因此我们可以说，尽管 SQL 注入是由于 SQL 本身提供的可能性而变得可能，但这并不是一个数据库问题。相反，应用程序应该包含安全控制，确保在连接的数据库上执行的操作仅限于设计时定义的操作，符合应用程序设计要求。

一些设计原则，如果在与 SQL 数据库交互的应用程序开发中得到应用，可以避免 SQL 注入，这些原则通常涉及正确处理查询内容；例如，抑制危险的字符和命令。一般来说，应用程序应严格控制用户能够执行的操作。

SQL 注入攻击技术

就具体的攻击技术而言，SQL 注入可以为潜在攻击者提供多种方式来操作数据库并改变其功能。让我们逐一讨论最常见的几种方法。

破坏应用程序功能

攻击者可以通过 SQL 注入，利用连接任意 SQL 命令到现有查询字符串的方式，执行任意数据库命令，并通过分号来结束语句。一种非常简单但具有破坏性的情况是使用 DROP 语句，或者修改数据库中的信息，如登录信息，这可能对应用程序的功能至关重要。然而，这些完全任意的命令在大多数情况下是无效的，因为 SQL 通常一次只支持一个查询。多条查询（如内联查询）通常不被支持，从而限制了这种类型的攻击。

然而，如果应用程序已经支持可以修改数据库内容的语句，这些命令可能会被修改，导致应用程序遭受严重破坏。想象一下，如果一个原本打算删除单个用户的操作，结果却删除了数据库中所有的用户。那么，这种情况虽然不常见，因为设计良好的应用程序通常主要使用 SELECT 语句，但这些语句仍然有可能被利用。

使用 UNION 查询的 SQL 注入

UNION 是一种 SQL 子句，可以添加到现有的 SELECT 语句中，从另一个查询返回结果，并将其包含在第一个查询的输出中。要做到这一点，两个查询需要具有相同数量的属性。然而，攻击者可以通过添加任意的静态值，如固定数字，并采取试错法来轻松利用这一点。

使用 UNION 的 SQL 注入可以用来从一个易受攻击的数据库中收集大量信息。数据库模式本身，通常可以通过一些默认的表访问，能够查询到系统内的数据库、表格和表字段等信息，从而揭示数据库中包含的各种信息。这些结果可以直接用于查询数据库，为攻击者提供某种信息收集的蓝图，帮助其进行后续的攻击。UNION 查询的潜力因数据库而异。在某些情况下，它们可以用于检索比单个应用程序使用的数据库更多的信息，尤其是在 MySQL 和 MSSQL 中，由于许多数据库可以同时查询，如果目标系统托管了多个依赖数据库的应用程序。

提权

恶意用户还可以通过 SQL 注入来获得比通常情况下更高的权限，从而能够滥用本来无法访问的应用程序功能。

使用信息收集技术，如UNION 查询，可以让恶意用户从数据库中提取信息，这有时可能导致密码泄露。实际上，登录信息通常存储在数据库的特定部分。通常，密码信息以密码哈希的形式存储，但如果使用像 MD5 这样的弱哈希算法，密码攻击即使在离线状态下也可以将其解密。在某些情况下，身份验证可能通过直接包含一个始终为真的布尔表达式来绕过，这个布尔表达式用于登录过程中的逻辑检查。

盲 SQL 注入

最常见的 SQL 攻击技术之一被称为盲 SQL 注入。这个名字源于这样的事实：有时对数据库执行的操作不会在应用程序中返回数据库查询结果，因此攻击者只能自己猜测数据库的内容。所有不显示完整查询结果的技术，包括绕过身份验证的技术，技术上都可以包含在这个定义中，但这一类别中还有许多其他技术。

在某些情况下，尽管一个易受 SQL 注入攻击的应用程序不会显示实际的查询结果，但如果查询结果存在与否，可能会显示差异。这通常与满足特定的布尔条件相关联。在这种情况下，我们讨论的是基于布尔的 SQL 注入，因为攻击者可以利用这些信息，通过使用布尔条件来推断数据库内容。

然而，也有一些情况，应用程序在成功查询和失败查询之间没有任何差异。在这种情况下，使用基于布尔的 SQL 注入对攻击者没有任何价值。然而，恶意用户可能会找到方法来生成这种差异，最常见的方式是通过添加时间延迟来实现，当某个任意条件得到满足时。在这种情况下，我们讨论的是基于时间的 SQL 注入。

最后，盲 SQL 注入的另一种技术被称为拆分与平衡。其目标是检查使用等效的 SQL 查询时，SQL 代码是否被系统评估。在这种情况下，攻击者还可以在相同结构中插入任意子查询，确保语法正确，从而执行潜在的危险命令。

NoSQL 注入

最后，值得一提的是，尽管 SQL 注入是最常见的数据库注入案例，但在非关系型数据库中，这个漏洞也可能具有一定的意义。

实际上，尽管数据库并不总是依赖于提供与 SQL 相同可能性的查询语言，通常被认为比 SQL 本身更安全，但一些任意命令可能会在应用程序级别被注入。这些命令可能会被数据库评估，导致潜在的有害操作。

在 NoSQL 数据库的情况下，这被称为 NoSQL 注入。尽管我们讨论的许多技术并不涉及 NoSQL 数据库（例如，使用UNION查询进行数据库转储和使用复杂的任意语句），但攻击者可以通过在应用程序中放置输入来随意更改一些命令语义。一般来说，恶意用户可以通过在参数中插入元素来篡改 NoSQL 数据库的语法，并欺骗底层数据库评估意外值，这可能导致有害行为。

SQL 注入和其他安全漏洞

SQL 注入确实是一个有趣的话题，特别是考虑到使其可能的内部运作方式，因为它揭示了一个更广泛问题。SQL 注入实际上是一种特定类型的软件漏洞，涉及与数据库以某种形式互动的应用程序。这种漏洞的存在会触发意外行为，可能导致损害性后果，不仅仅是对应用程序本身，更普遍地影响周围的世界。

让我们看一个例子。想象一个允许经过身份验证的个人访问敏感信息的应用程序，例如个人身份信息、物理地址，甚至社会安全号码或其他一个人通常不会向任何人透露的细节。通过 SQL 注入，攻击者已经获取了数据库中包含的所有信息，并将其删除。在这种情况下，不仅应用程序受损，还有所有这些数据所属的人。恶意攻击者可以在互联网上披露这种数据库的内容，将这些人暴露给任何可能利用这些信息的恶意人士，这可能导致从骚扰到欺诈，甚至直接迫害的后果。公共数据可以被任何人使用，无论他们的意图如何，因此保持数据安全，不泄霩比严格必要的信息更多，以避免这些后果是至关重要的。

在当今世界，数据始终是一项关键资产。许多人已经在不知情的情况下向互联网上的各种实体提供了他们的个人信息访问权限，这些实体主要通过定向广告来利用这些信息获得商业优势。这些信息也被用来引导人们访问他们可能喜欢的内容。

从某种程度上讲，这也可能被用来强加一些思想和观点给目标人群，从而间接控制他们的思维方式和行为。这只是一个例子，让你一窥数据的重要性，以及任何人如何将其视为宝贵，因此你永远不应该对任何人透露过多信息。从这个角度来看，允许攻击者访问故意保密的信息的漏洞，当然是更为关键的，应该让每个人都对此感到担忧。

还有许多其他漏洞存在，这些漏洞不仅可能对目标系统造成破坏性后果，还可能泄露保密信息。大多数漏洞（如果不是全部的话）是硬件或软件有时意外功能的结果。这可能意味着编码错误、程序内存管理问题、用于连接的故障协议，或一些小疏忽，这些都可能导致即使是关键性的问题。

保持所有软件和固件更新的原因之一是，通常情况下，更新是用来修复发现的问题的。这并不一定意味着更新后的软件没有漏洞，但它确保了已知的漏洞在那时得到了修复。由于在安全漏洞的情况下，我们讨论的是通常未曾预见到的问题，因此漏洞可能会长时间未被发现。

在这种背景下，信息安全的使命是通过识别漏洞、提供对策，并在系统周围设置保护层，来保护 IT 环境，防止安全问题的发生。信息安全是一个协作性的努力，所有相关方都会参与其中：漏洞一旦被发现，就会公开披露，以警告所有人。这当然原则上可能有利于恶意攻击者，他们可能会获取这些潜在漏洞的知识并试图加以利用，但相比漏洞长期保密、仅为某些攻击者所知且能不受干扰地加以利用，这一风险微不足道。

一些已知的未公开漏洞案例包括一些 Windows 漏洞，这些漏洞长时间未被披露，允许一些监控机构（我不会提及具体名称）在全球范围内拥有某种后门——一种特权访问方式。虽然这种行为可以进行争论，但制造商和系统管理员对这些漏洞一无所知的事实，在这些秘密信息不小心泄露给负责保护它们的人时，带来了极高的风险。最近的例子包括导致 EternalBlue 攻击可能发生的漏洞，该漏洞影响了 Windows 系统。

这种漏洞使得恶意攻击者能够利用 Windows 中服务消息块（SMB）协议实现中的漏洞，如果未打补丁，可能会导致在目标机器上执行任意命令。此攻击由美国的国家安全局（NSA）设计。关于此类攻击和其利用的漏洞的信息在 2017 年浮出水面，恰逢该漏洞被修补之后，但估计 NSA 在此之前大约已知晓该漏洞五年之久。该漏洞的保密性使得许多网络犯罪分子在修补之前的几年里就已经利用了这一漏洞，这也为用户提供了一个充分的理由，永远不要将漏洞信息保密——攻击者迟早会发现这个漏洞，而且他们绝不会公开相关信息。

信息安全的使命是我们在本书第二部分关注实际方面的原因：测试是发现漏洞并进行修复的关键元素。对策使得测试变得有意义，从而使漏洞能够得到有效修复。让我们再一次回顾这一实践部分，解释我们所做的事情以及背后的原因。

SQL 注入——实践中的视角

在实践部分，我们搭建了一个安全的环境，以确保我们的测试不会对外部实体造成问题——这样模拟就像是在测试一个属于我们的真实系统——专注于识别和利用 SQL 注入漏洞。在处理了实践部分中可能是最有趣的部分之后，我们描述了防止 SQL 注入发生的措施。

使用 SQL 注入进行攻击

让我们回顾一下我们在选择的目标上所进行的测试，并回顾我们实践中的技术。

手动技术

通过利用 OWASP BWA 项目，我们能够探索我们在理论部分中看到的大多数攻击技术。这是通过选择三个特定的网络应用程序来实现的，这些应用程序让我们可以尝试多种 SQL 注入攻击。

我们的第一个目标是 Mutillidae II 网络应用程序，它是一个用于测试各种已知漏洞的培训网络应用程序。其中也包括了 SQL 注入漏洞。我们学习了如何利用SELECT语句从数据库中检索任意信息，以及如何通过INSERT语句来创建应用程序中的帐户，从而使得可以通过这些帐户提取信息。这些帐户的资料被修改，以包含数据库中存在的私密数据。

对于第二个目标，Magical Code Injection Rainbow，我们探索了多个以挑战形式呈现的 SQL 注入练习。在这里，我们测试了盲 SQL 注入、基于错误的 SQL 注入等技术，并利用可以通过错误信息返回查询结果的函数。

最后，通过 Peruggia，我们查看了一个伪真实的 Web 应用程序，它故意存在漏洞，但没有任何提示或指南。它的一个漏洞就是 SQL 注入。我们看到 SQL 注入如何为恶意用户提供绕过登录认证的方式。这个技术还可以通过盲注 SQL 注入进行推断，因为只有在条件满足时才会授予访问权限。通过使用布尔检查，可以验证数据库中的信息。

通过这些手动技术，我们看到了 SQL 注入的潜力以及测试这种漏洞的方法，以评估应用程序的安全性。

自动化技术

我们可以使用的另一个工具是使用特定的软件工具，这些工具可以帮助自动化地验证一个应用程序是否容易受到 SQL 注入攻击，从而在测试过程中节省时间。

OWASP ZAP 是一个多功能的 Web 应用程序安全测试工具套件，包含多种工具。具体而言，Spider 工具帮助我们在应用程序中查找网页，并设置爬虫来探索页面中的超文本链接，从而发现包含 Web 表单的动态网页。另一方面，Scan 工具以自动化的方式针对动态页面尝试各种有效载荷。这有助于我们发现漏洞，依据 Web 应用程序的响应：如果输出与易受攻击的响应匹配，ZAP 会将其记录为漏洞。当然，这并非完全无误，有时会导致误报，但它确实提高了效率。另一个有用的工具是 Fuzzer 模块，它通过将一组预设值替换到目标参数中，自动发送 Web 请求，从而进行更有针对性的测试，使用用户定义的特殊有效载荷。

sqlmap 是另一个重要工具，凭借其选项，它可以帮助识别目标网页上的 SQL 注入漏洞。提供了各种自定义选项，可以实现多种不同的攻击技术，还可以生成数据库转储。sqlmap 还具有破解密码哈希的功能，这些密码哈希可以从数据库转储中获取。

这两个工具被全球的安全专业人员使用，可以帮助大大提高 SQL 注入测试的效率，减少时间消耗。当然，这些工具不能替代手动测试，但通常足以帮助我们判断一个 Web 应用程序是否容易受到 SQL 注入攻击。

针对 Web 服务和移动应用程序的 SQL 注入

最后，在我们的 SQL 注入测试中，我们增加了针对 Web 服务和移动应用程序的测试，这可以定义大量可能的场景。事实上，Web 服务可能负责基于 Web 服务的简单应用程序，这些应用程序包含轻量级逻辑。对于移动应用程序尤其如此，它们通常代表远程 Web 服务的接口，而物联网场景通常在实现上相当简单，鼓励低计算强度的设备通过这些服务进行交互。

我们研究了这些，旨在证明 SQL 注入不仅仅与 Web 应用程序有关，而是与任何依赖 SQL 数据库的应用程序相关。

在进行这些测试后，我们转向了 SQL 注入的防御方面，即评估可能的对策。

防御 SQL 注入

从防御的角度来看，通常来说，这一切都涉及对应用程序的输入和输出进行检查和控制。毕竟，攻击一个应用程序通常是通过发送恶意输入来实现的。正如我们在 SQL 注入中看到的，原则总是相同的。首先，来自用户的输入需要被视为潜在的恶意输入，这样我们才能开始思考可以应用的安全措施。

在本书中，我们根据防御机制的应用场景进行了讨论，并将其分为代码级别防御和平台级别防御，具体取决于我们是在处理应用程序的实际编码还是围绕其的基础设施。

使用代码级别防御防御 SQL 注入

在将防御机制应用到我们的应用程序代码时，这些机制可以根据它们的目标被分为不同的类别。

输入验证包括检查输入并验证它是否符合我们的规则。通常我们可以通过两种方式来定义验证规则。最简单的一种是基于黑名单，即如果输入属于我们认为潜在危险的输入集合，我们就不接受它。然而，虽然这种方法容易实现，但我们需要具体定义什么是危险输入，可能会错过一些危险的情况，特别是当发现新的危险时。另一方面，白名单是一种更严格的方法，通常也更安全：我们只接受属于已接受输入列表的输入，从而排除我们不认为正常的任何东西。

另一种正确处理输入的方法是以安全的方式构造查询语句。我们已经看到，SQL 注入的“魔力”通常发生在查询语句是使用用户提供的输入构建时，从而生成了意外的命令。为避免这种情况，我们可以参考参数化查询，其中输入被保存到特定的参数中，并且在我们实际将查询发送到数据库之前，添加了一个额外的步骤。这确保了，如果正确应用，用户输入不会被解释为查询的一部分，从而改变语法。

另一个选项是构建我们的代码，使其排除用户输入中的有害字符，甚至忽略它们。如果我们将某个字符转换为另一种编码，使我们的应用程序能够读取它而不对 SQL 数据库造成危害，这称为字符编码。字符转义是指我们插入转义机制，使得数据库忽略这些字符，即使它们原样插入到查询中。

除了这些技术外，在开发应用程序时，还有一些有用的原则需要牢记。这些原则包括使用各种抽象层来构建应用程序，例如将用户界面与实际应用程序逻辑分开，从而不直接访问更敏感的区域。

通过添加加密技术和数据掩码来安全地处理敏感数据也非常重要，因为这可以防止恶意代理获取可能导致损害的私人信息，不仅对应用程序有害，在某些情况下还可能对用户的隐私造成威胁。尤其在考虑隐私和数据保护相关法律时，这一点尤为重要。

最后，即使专注于 SQL，我们也考察了使用存储过程而不是在应用程序中构建查询。这可以确保这些操作可以按照数据库本身决定的权限级别执行，因为发送命令到数据库的应用程序通常具有较高的权限级别。这意味着如果应用程序被攻破（例如，通过 SQL 注入），攻击者可能会完全访问数据库。另一方面，限制存储过程中的权限可以将攻击者的潜在影响限定于严格允许的范围，从而避免意外结果。

这就是我们对可以应用于应用程序代码和设计的对策的概述。现在，让我们继续查看应用程序上下文相关的方面。

使用平台级防御来防止 SQL 注入

在谈到平台级防御时，我们需要超越严格定义的应用程序安全性，因为我们还可以处理更多的附带方面。我们的目标是通过应用外部措施来保护应用程序，从而限制攻击的潜力，并降低成功攻击我们应用程序的可能性。

这个防御类型的第一个例子是Web 应用防火墙，简称WAF。WAF 是组件，通常是软件，能够接受或拒绝传递到我们应用程序的应用层请求。这类似于代码级别的输入验证，但发生在应用程序之外，从而防止恶意请求触及我们的应用程序逻辑，就像什么都没有发送一样。WAF 可以直接在 Web 服务器级别工作，通过处理发送到 Web 服务器的请求；在应用层，通过使用外部的应用程序模块，从而独立于服务器技术；以及在 Web 服务层，这在使用 SOAP 的 Web 服务时非常有用。

WAF 也可以作为被动模式使用，充当入侵检测系统。这样，WAF 可以持续监听流量，并且在发送到应用程序的内容异常时发送警报。这样，管理员可以在攻击尝试发生时及时采取行动。

防火墙逻辑也可以通过使用数据库防火墙在数据库级别应用。这些就像代理服务器，位于应用程序和数据库之间，检查本应发送到数据库的命令。如果是恶意命令，什么也不会发送到实际数据库，从而防止 SQL 注入等攻击的发生。

可以通过直接保护数据库来添加另一层安全性。这意味着通过加密或掩码来保护存储在数据库中的数据，并通过应用补丁和安全配置来保护数据库服务器，同时确保适当的身份验证机制。

最后，另一些可以在平台级别应用的安全原则包括避免不必要的信息泄露、抑制错误信息以及防止搜索引擎探索您的 Web 应用程序。

另一个重要原则是通过将应用程序逻辑与数据库以及前后端分开来安全地部署应用程序。使用网络访问控制（NAC）进行网络级身份验证也可以防止许多攻击，因为只有某些网络实体被允许在应用程序上执行敏感操作。它们还可以使用特定的证书或通过防火墙执行的网络规则进行身份验证。

现在我们已经浏览了这一路程中涉及的所有主题，让我们从应用安全性和计算机安全性的一般角度，审视这些主题在本书实际部分中的重要性。

管理漏洞和安全缺陷

要真正将我们所讨论的内容放入更大的视角中，我们需要关注复杂环境中安全问题和漏洞的整个生命周期，例如公司或大型企业。

一些安全专业人员的工作是发现网络基础设施中存在的漏洞和安全缺陷，包括资产——例如服务器或工作站——或更具体地说，在应用程序中。识别安全问题的最常见方式是进行漏洞评估，通过分析目标系统来查找是否存在已知的安全问题，例如系统配置本身的漏洞、缺少安全更新，或使用各种工具和技术进行扫描。这些活动的重要部分是测试这些问题，以验证这些漏洞是否真会被潜在的恶意攻击者利用。

我们在第四章，攻击 Web、移动和物联网应用程序中所经历的，正是模拟了安全专业人员的工作，负责识别安全缺陷——在本例中是应用程序——通过评估它们被利用的实际程度，从而正确评估其影响。当然，我们重点关注了 SQL 注入，但由于还有许多其他漏洞，这项工作可能相当复杂——但也充满了挑战，而且在某些情况下，非常有趣。这为你提供了新的挑战和思考不同难题的方式。

安全测试和发现安全问题显然是关于将有效的修复计划付诸实践，以便有效地解决这些问题。第五章，通过防御性解决方案防止 SQL 注入，帮助我们了解了如何修复 SQL 注入漏洞。根据具体情况，以及可能的工作量和时间限制，一个有效的漏洞修复计划可以通过应用最有效的修复措施进行优化，以便在最小的操作量下提供尽可能高的安全性。

在这种情况下，安全专业人员需要知道最有效的应对措施是什么，考虑到发现这些问题的环境，并确保这些行动的影响对组织是可接受的。虽然在大多数情况下，安全专业人员不需要亲自实施解决方案，但他们需要了解这些解决方案的内容，以便能够指导技术人员将这些变更应用于受影响的基础设施和/或系统。

本书的实践部分旨在为你提供一个关于如何应对漏洞的实用样本，特别是聚焦于 SQL 注入——从发现部分、通过测试评估损害可能扩展的程度，到实际修复漏洞，探索可以采取的各种对策。这为我们提供了具体的示例，特别是在处理常见编程语言时。

这样，通过扩展我们在这个特定案例中所遵循的路径，我们可以考虑安全问题的完整生命周期。首先，漏洞被发现——通常是通过自动化方式，正如我们在使用 OWASP ZAP 的扫描模块进行 SQL 注入测试时看到的那样。当然，单次扫描可能会识别出大量问题，这些问题需要在接下来的阶段逐一评估。

在第二步中，实际上测试了这样的漏洞——与许多其他漏洞一起——以评估自动化分析结果是否为假阳性，并查看此类问题的实际影响。通过参考我们在第四章中提供的教程，攻击 Web、移动和物联网应用程序，我们正是这样做的：我们知道这些应用程序容易受到 SQL 注入攻击，但我们研究了这些漏洞，看看它们可能导致什么问题。

实际上，应用程序可能确实存在漏洞，但利用该漏洞可能导致较小的后果——在这种情况下，变化的影响可能远低于 SQL 注入漏洞，但仍可能导致应用程序的完全妥协。SQL 注入攻击的可利用性可能取决于现有的对策，虽然这些对策未必同时存在，但即使部分存在，也能阻碍攻击者的工作。

最后，在漏洞测试完成后，可以考虑采取对策，同时要牢记任何已存在的防御机制。这需要对当前安全问题有精准的了解。因此，针对 SQL 注入攻击，我们展示了可以采取的最相关的对策，以保护应用程序免受此特定漏洞的影响。一个经验丰富的安全专业人士可以通过应用程序的行为来判断已应用了哪些对策，从而更好地建议可能的防御措施。

建议的防御措施出现在制定修复计划的过程中，目的是指导技术人员应该应用哪些防御措施。此时，通过这样的计划，就可以决定是否通过实施适当的防御机制来解决与安全问题相关的风险。或者，取决于风险的严重性，也可以选择接受这种风险，因此我们不必应用可能会因为操作上的权衡而变得过于苛刻的对策（例如，应用某个安全机制可能会要求关键服务器停机时间超过组织可容忍的时间）。

网络安全是一个不断发展的学科，需要专业人员时刻跟进最新的威胁、漏洞和风险。在这一实用部分中，我们希望能够让你体验到作为这一有趣领域专业人士的感受。现在，让我们再一次总结主要问题。

SQL 注入及其安全影响——总结评论

既然我们已经通过本书探讨了 SQL 注入，我们可以讨论现今 SQL 注入及其安全问题，同时考虑它在全球互联网安全方面的影响，以及在现实世界中的后果。

现今的 SQL 注入

SQL 注入确实是一个历史悠久且广为人知的漏洞，因此，通常在开发或发布新应用程序时会特别考虑，尤其是在全球互联网这样的 Web 应用程序中。大多数基础攻击通常是无效的，因为大部分常见的防范措施通常会应用于绝大多数案例，且许多具有内置控制的 Web 框架经常被使用。然而，仍然可能存在脆弱的应用程序，这通常是由于源代码中的错误或疏忽，或者是其他一些无法预见的情况。

根据 OWASP 在 OWASP 十大 Web 应用程序安全风险（2017 年最新版）中提到的内容，注入攻击是 Web 应用程序的最大风险因素，因为我们在本书中探讨的内容表明，其被利用的后果非常严重。SQL 注入当然属于这一类别，因为它仍然是恶意用户通过插入任意命令与应用程序的内部逻辑进行交互，从而利用 SQL 语言的表达能力的最常见方式之一。

SQL 和 NoSQL 注入实际上通常被视为此类攻击的第一个典型例子：它无疑是恶意用户针对 Web 应用程序最常尝试的攻击技术之一，因为它从战略角度和操作影响的角度来看，都能提供巨大的优势。尽管它声名狼藉，基于 SQL 注入的攻击依然时有发生。

最近的例子也进入了新闻报道。2014 年，据报道，一些网络犯罪活动——归咎于俄罗斯的网络犯罪团伙——通过各种 SQL 注入攻击获取了 12 亿对用户名和密码（来源：纽约时报，2014 年 8 月 5 日，www.nytimes.com/2014/08/06/technology/russian-gang-said-to-amass-more-than-a-billion-stolen-internet-credentials.html?_r=0）。

最近，一位漏洞赏金猎人——一种在特定程序中寻找漏洞的安全专家，经得程序所有者同意，并在漏洞被成功利用时给予金钱奖励——发现了一个 SQL 注入漏洞，导致了 Starbucks 的一个财务数据库暴露（来源：《The Daily Swig – Portswigger 的新闻博客》– 2019 年 9 月，portswigger.net/daily-swig/sql-injection-flaw-opened-doorway-to-starbucks-accounting-database）。尽管要利用这个漏洞需要更复杂的攻击手段——通过利用应用程序的其他弱点——这仍然表明 SQL 注入仍然是今天的一个问题，且可能带来较高的安全风险，可能暴露关键信息。

与 SQL 注入相关的其他问题也可能作为框架和软件中的漏洞存在。有时，一些新的漏洞影响了用于构建 Web 应用的软件，若被充分利用，通常通过复杂和不常见的攻击技术，可能导致使用这些软件的应用程序出现 SQL 注入问题；也就是说，如果没有采取进一步的对策。这些漏洞通常在发现后会被修复，因此，如果使用了外部软件组件，必须确保它们始终保持最新版本。

通过这一点，我们可以看到，尽管 SQL 注入是一个过时的漏洞，但它今天仍然具有相关性，再次强调了采取防范措施以应对该漏洞的重要性。恶意代理和网络犯罪分子将始终尝试对 Web 应用进行 SQL 注入攻击，因此最好的做法是通过实践所有已知的防御机制来做好准备。

超越 SQL 注入

虽然 SQL 注入仍然是那些希望破坏应用程序的攻击者最常使用的攻击技术之一，但它绝对不是 Web 应用安全领域唯一的安全风险。

OWASP 十大 Web 应用安全风险

我们已经提到过 OWASP 十大 Web 应用安全风险，但让我们提供一个大致概述。它包含了最相关的 Web 应用安全风险，并按风险级别排序。此列表不定期更新。最近的一版是 2017 年的，但 2020 版正在制作中。

下面是完整的 OWASP 十大 Web 应用安全风险，并附有简要说明：

  • 注入攻击：注入攻击是指插入不可信的数据，使其被解释为查询的一部分或更一般的命令。这包括 SQL 注入、NoSQL 注入和操作系统命令注入。

  • 身份验证失效：身份验证和用户会话管理实施不当，导致攻击者通过获得比预期更高的权限或窃取用户身份来破坏应用程序。

  • 敏感数据暴露：应用程序可能泄露敏感数据，如财务、医疗和个人信息，例如通过错误信息或可访问的资源。这使得这些数据容易遭受欺诈、身份盗窃或其他犯罪行为。

  • XML 外部实体攻击（XXE）：如果 XML 文档中的任意外部实体引用被评估，则可能被用于泄露内部文件、敏感信息，并可能导致远程代码执行和拒绝服务攻击。

  • 访问控制失效：用户权限的限制（即特定用户在应用程序中可以执行的操作）没有得到正确执行。这可能允许用户执行本应仅限管理员或更高权限的操作。

  • 安全配置错误：用户所在的应用程序和/或系统在安全性方面没有正确配置。这包括不安全的默认配置、不完整或临时的配置以及不必要的错误信息。

  • 跨站脚本攻击（XSS）：XSS 允许攻击者通过将客户端脚本（通常是 JavaScript）插入到受害者的浏览器中执行，从而可能危及用户会话或诱使用户访问危险网站。

  • 不安全的反序列化：输入未正确处理，且可以被应用程序直接接受，从而可能导致远程代码执行或注入攻击。

  • 使用具有已知漏洞的组件：具有已知漏洞的外部组件可能会使应用程序暴露于各种攻击，具体取决于漏洞类型。这些组件需要及时应用最新的安全更新。

  • 日志记录和监控不足：日志记录和监控不足意味着目标系统和应用程序没有正确地追踪可能的恶意行为，从而阻碍了任何可能的调查。

如您所见，SQL 注入虽然是最重要的漏洞类型之一，但只是冰山一角。这个列表只是为了向您展示 Web 应用程序可能在多少种方式下受到安全弱点的攻击。

在这样的背景下，安全专业人员在帮助保护应用程序和服务安全方面的作用显而易见。每当发现安全问题时，最好尽快采取措施进行缓解或解决。此外，通过阅读前十名的风险，您可能注意到某些风险之间是相互关联的。例如，不安全的反序列化可能会导致诸如注入等问题，这是由于对用户输入的不安全处理，而 XSS 可能是因为缺少输入验证，进而导致 SQL 注入。XSS 本身实际上是一种注入（在客户端脚本代码如 JavaScript 的情况下）。由于这些风险的相互关联，并且根据它们被检查的背景，安全专业人员主导的适当分析可以帮助优化缓解这些风险的过程。在此，他们选择优先处理最关键的问题，以最小化可能造成的影响。

OWASP Web 应用程序安全风险十大榜单进一步确认了 SQL 注入是 Web 应用程序中最关键的安全问题之一。这再次指向本书的任务：处理 SQL 注入问题，它是安全风险中最突出的风险之一。SQL 注入作为 Web 应用程序安全的理想切入点，带领我们进入更为复杂和全面的 Web 应用程序安全世界，而 Web 应用程序安全本身是计算机安全这一大分支的一部分，通常被称为信息安全或网络安全。

进一步探索信息安全

更深入地探索应用程序安全无疑是一个激动人心的道路，因为通过本书的实践部分所设立的测试环境，我们可以不断遇到新的挑战，并将直觉和技术技能付诸实践。这可以让你像某种侦探或医生一样，尝试做出正确的诊断。这对于有一些应用开发经验，想从安全角度审视已知问题的人尤其有益。

通常，安全专业人员可能需要在基础设施层面进行更多的操作。这种方法类似于 Web 应用程序安全，在这种情况下，您可以在目标系统上找到漏洞，这次是在系统级别。它可能需要精确了解操作系统如何工作，甚至了解在服务器和工作站上运行的协议和服务。由于需要直接在系统级别进行交互，而没有机会使用像 Web 应用程序安全评估中那样的用户友好界面，利用漏洞也可能变得相当具有挑战性。

网络安全的终极目标是为计算机和企业系统提供额外的安全层。这也可能导致采用针对性的安全解决方案，这些解决方案可以帮助组织和个人增强他们的安全态势。通过这种方式，安全专家可以根据初始背景建议最佳的安全解决方案。

无论如何，信息安全如今是最为讨论的话题之一。近年来，全球各国政府和超国家组织通过多项立法努力开始规范信息安全的各个方面。在考虑到网络战争的概念时，这一点尤为重要，因为即使是国家支持的网络攻击也可能针对全球的组织和实体进行。确保安全问题得到妥善处理至关重要，尤其是在考虑到组织乃至国家在面对计算机安全相关风险时，若未做好充分准备可能会面临的后果。

每天，信息安全总会以某种方式成为世界各地报纸和新闻的头条：这只是信息技术（IT）已成为我们社会中心的一个症状。因此，信息技术的安全变得极为重要，因为保护 IT 就是保护现实世界。随着时间的推移，这一说法变得愈发合理，因为技术已经与我们的生活紧密相连，渗透到我们日常生活的方方面面。

即使您对信息安全没有特别的兴趣，我们也建议您意识到它的重要性，因为它将始终贯穿我们的生活，特别是在未来。我们希望本书能够激发您进一步探索信息安全的话题。毕竟，您已经亲自了解了 SQL 注入的潜在后果。

总结

现在，我们来到了这段旅程的终点。在处理过我们所面对的所有主题之后，这一次以更加简洁的方式呈现，您掌握了关于信息安全的一些知识，并且看到即使是 SQL 注入漏洞（希望您已经掌握了这一主题），也能在现实世界中发挥重要作用。

既然您已经读完了本书，您可以随意探索信息安全的相关话题，或者继续在受控环境中进行实践。我们的希望是这段经历激发了您的好奇心，促使您更深入地了解安全话题。

感谢您阅读本书，并希望您在这个过程中也感到愉快。您可以随意使用您的模拟环境来测试 SQL 注入漏洞。您甚至可以使用 OWASP BWA 项目中的应用程序，了解其他安全问题。我们建议您首先探索 Mutillidae II 提供的所有内容，按照所有建议和指南进行操作。这将让您初步了解主要的 Web 应用程序安全风险。

现在你已经掌握了 SQL 注入，我们希望你能将所学应用于善事，而不是伤害任何人，尤其是考虑到你的行为可能带来的后果。

你知道他们怎么说的：伟大的力量伴随着伟大的责任。现在你已经掌握了 SQL 注入，要记得这一点。

问题

  1. 安全漏洞，包括 SQL 注入，通常是由什么引起的？

  2. 安全专业人员在漏洞测试中的工作是什么？

  3. 描述本书中我们识别的安全评估的三个主要阶段，不包括防御机制的实施。

  4. 你认为 SQL 注入作为一种老旧的漏洞，已经不再是一个真正的问题了吗？

  5. SQL 注入在 OWASP 前 10 大 Web 应用程序安全风险列表中的排名是什么？

第五章：评估

第一章

  1. 数据库是一种以永久的方式存储数据的方式，通常以结构化和可访问的方式存储，以便其内容可以轻松地进行查询。

  2. 关系型数据库是一种使用表格来存储数据的数据库。这些表格建模对象及其之间的关系，正如名字所示。

  3. 结构化查询语言(SQL) 是一种用于与关系型数据库交互的语言，它依赖于通过简单语法构建查询。

  4. 一些基于 SQL 的系统示例包括 MySQL、SQLite、Microsoft SQL Server 和 Oracle 数据库。

  5. SELECT 是最常见的 SQL 语句，它负责查询数据库并根据指定的要求返回数据。

  6. SQL 注入是一种通过输入数据插入任意 SQL 命令的攻击。这可能导致对目标应用程序正在使用的数据库进行本应受限的操作。

第二章

  1. SQL 注入可以通过使用特定字符触发，这些字符在 SQL 语法中对应特定的功能，例如字符串定界符，用于在不打算终止输入字符串的地方终止输入字符串。这样可以在后面插入 SQL 代码，以及注释字符，使系统忽略查询的某些部分。

  2. 攻击者可以通过一个网页表单插入任意查询，返回可能相关的信息。他们可以查询默认表来查看数据库结构，方法是将结果附加到现有查询结果中，使用UNION，并通过注释掉输入后要使用的查询部分来绕过验证。

  3. 攻击者可以通过两种方式绕过用户认证：他们可以从先前的注入攻击中获取密码，或者通过插入一个始终为真的语句来欺骗应用程序，从而导致登录成功。

  4. 盲 SQL 注入是一种不依赖数据库输出的 SQL 注入技术。它可以依赖布尔表达式，前提是应用程序在结果为真或假时表现不同，或者如果应用程序在输出上没有任何差异，它可以引入时间延迟。

  5. 由于在结果为真或假的情况下，输出没有显著差异，我们能做的就是依赖基于时间的 SQL 注入。

  6. 几乎任何依赖查询的数据库系统，如果输入未经过消毒或验证，都可能容易受到注入攻击。

第三章

  1. 虚拟化软件是一种完全模拟系统的特殊软件。我们使用它来确保我们的测试不涉及外部第三方，这意味着我们的一切都在一个受控环境中进行。

  2. Kali Linux 是一个特殊的 Linux 发行版，包含一套为安全专业人员准备的软件。我们需要它来展示针对 Web 应用程序的自动化 SQL 注入攻击。

  3. OWASP BWA 项目是一个以虚拟机形式存在的集合，包含故意设计有漏洞的 web 应用程序。我们通常使用它作为我们 web 应用攻击的目标。

  4. 我们模拟 web 服务，它代表了与传统 web 应用程序不同的接口，以及移动设备，在移动环境中显示漏洞。

  5. 绝对不行。只能对属于你的系统进行测试。未经明确和正式表达同意（即合同）的情况下，绝不可对属于第三方的系统进行测试。

第四章

  1. 二分查找在进行盲 SQL 注入时尤为有用，可以逐个字符猜测，例如使用 MySQL 的ascii()函数。

  2. 将 SQL 查询插入依赖外部语言/模块的函数参数中（如ExtractValue()函数）可能会在 SQL 错误中返回查询结果。

  3. OWASP ZAP 提供了 Spider 工具，用于识别网页和可能存在漏洞的表单，另外还有 Scan 和 Fuzzer 工具，可以用于检查易受攻击的参数。

  4. 是的。sqlmap 具有一个密码破解模块，可以通过暴力破解从哈希值中提取密码。

  5. SQL 注入可以针对任何类型的应用程序执行，包括 web 应用程序、web 服务和移动应用程序，如本章所示。

第五章

  1. 用户输入应始终视为潜在的恶意输入，因此必须始终进行清理和验证。

  2. 验证输入意味着在接受输入之前决定它是否有效。黑名单会阻止所有已知的无效输入，而白名单仅接受已知的有效输入。

  3. 参数化查询是一种构建查询语句的方法，它将查询字符串分解为参数。这些参数首先作为变量存储，然后插入到查询的主体中。

  4. 字符编码和转义对于转化可能会被 SQL 解析的有害字符非常有用，这些字符可能会导致 SQL 注入攻击。

  5. Web 应用防火墙（WAF）的目的是在应用层过滤请求，并识别和防止危险的请求到达应用程序。

  6. 不。如果攻击者获得了加密数据，他们也可能获得加密密钥，从而使加密变得毫无意义。

第六章

  1. 安全漏洞通常是代码错误、配置错误或协议问题的结果。

  2. 安全专业人员在测试漏洞时，必须评估漏洞的可利用性，从而正确评估其影响和风险。

  3. 首先，发现漏洞。发现之后进行测试，以评估其风险。最后，基于已识别的风险，制定修复计划。

  4. SQL 注入，尽管是一个老旧的漏洞，依然在实际环境中存在，并且在今天仍然是一个问题。

  5. SQL 注入作为一种注入问题，位居 OWASP Web 应用安全风险十大漏洞之首。

第六章：其他您可能感兴趣的书籍

如果您喜欢这本书，您可能还会对 Packt 出版的以下其他书籍感兴趣：

Linux 安全与强化实战 - 第二版

Donald A. Tevault

ISBN: 978-1-83898-177-8

  • 创建锁定的用户账户，并设置强密码

  • 配置防火墙，包括 iptables、UFW、nftables 和 firewalld

  • 使用不同的加密技术保护您的数据

  • 强化安全外壳服务，防止安全漏洞

  • 使用强制访问控制保护系统免受漏洞攻击

  • 强化内核参数并设置内核级审计系统

Mastering Windows Security and Hardening

Mark Dunkerley, Matt Tumbarello

ISBN: 978-1-83921-641-1

  • 理解基准化并学习构建基准的最佳实践

  • 掌握基于 Windows 系统的身份管理和访问管理

  • 深入了解基于 Windows 系统的设备管理和远程管理

  • 探索硬化 Windows 服务器并保护客户端的安全性

  • 审计、评估和测试，确保控制措施成功应用并执行

  • 监控并报告活动，以掌握漏洞情况

留下评论 - 告诉其他读者您的想法

请通过在购买该书的网站上留下评论，与他人分享您对本书的想法。如果您是从亚马逊购买的书籍，请在本书的亚马逊页面上留下真实的评价。这对其他潜在读者非常重要，他们可以通过您的公正意见做出购买决定；我们也能了解客户对我们产品的看法；作者们也能看到您对他们与 Packt 合作创作的书籍的反馈。这仅需您几分钟时间，但对其他潜在客户、我们的作者以及 Packt 来说都非常宝贵。谢谢！

avatar
文章
阅读
粉丝