在本文中，我们将概述各种黑盒测试技术及其在针对 Web 应用程序执行攻击性测试中的有用性。我们还将研究有效负载的设计方式以及如何检测和区分应用程序生成的行为。
我们测试的目的
在黑盒测试环境中工作时，我们无法访问源代码。这意味着我们无法看到我们正在测试的函数如何实际工作或它如何处理我们的输入数据。因此，执行黑盒测试是为了了解函数中不同方面如何工作。
当我们执行黑盒测试时，我们通常希望结果能够回答我们对被测试功能的疑问，例如：
这个函数的目的是什么？
该功能需要我们做什么才能发挥作用？
该函数期望有哪些输入？
允许哪些输入？
我们的输入数据的数据类型是什么（例如int、string 或 array）？
哪些技术可能与该功能相关（例如数据库或API）？
可能存在哪些安全问题？
下图提供了黑盒工作流程的基本视觉概述：
为了了解我们正在测试的功能，我们收集它从我们的输入生成的所有数据。我们的测试持续时间越长，我们就越能理解该功能的工作原理。最后，我们希望对我们正在处理的事情有一个清晰的了解。
技巧
有许多黑盒测试技术，它们本质上都有一个主要目标：提高我们对功能的理解和/或触发意外行为。这些行为可能包括：
代码覆盖率
处理时间
错误信息
输入验证
崩溃
状态转换
这项技术帮助我们分析系统在不同输入条件下的行为。这是一种有用的测试技术，因为它可以帮助测试人员更好地理解特定用例中功能的工作流程。然后测试人员可以相应地调整未来的测试技术以提供更好的结果。
模糊测试通常与自动化工具结合使用，以检测功能的意外行为、崩溃或输出。通过利用自动化工具，这种众所周知的技术可以快速测试各种有效负载以发现异常行为。
基于生成和突变的模糊测试
模糊测试有多种类型，其中最有趣的两种是基于生成和基于突变的模糊测试。
基于生成的模糊器从头开始为每次新的测试尝试生成新的输入（有效负载）。与基于突变的模糊器不同，它通过修改最近使用的输入来生成输入。因此，基于突变的模糊器依赖于先前输入的质量和测试目标的行为来执行这些突变。下图给出了这两种模糊测试方法如何工作的基本概念：
错误猜测
错误猜测依赖于测试人员的创造力和经验来生成可能触发系统错误的测试用例。通过利用测试人员的专业知识和跳出框框思考的能力，该技术可以产生其他方法难以实现的重大突破和结果。
回归测试
此技术用于检查在对代码进行任何更改后函数是否仍按预期工作。该功能在系统更改之前和之后进行测试，并对结果进行比较，以发现任何意外行为。
例如，假设某个功能在使用旧版本的特定内容管理系统 (CMS) 的 Web 应用程序中完美运行，但当 CMS 更新到最新版本时开始表现奇怪。这表明存在以前不存在的潜在安全问题。
有效负载创建
例如，有效负载可以产生有用的结果，无论它是随机生成的还是手动生成的，或者是否仅由单个字符组成。
创建自己的有效负载的优点是它们可能是唯一的。这对于实现我们的目标非常有用，即从正在测试的函数触发意外行为，但不利用任何漏洞。
一个简单的例子是，如果我们尝试查找 XSS（跨站脚本）漏洞。
假设您使用类似 的有效负载"> <> alert(1) 。如果该有效负载有效并利用了 XSS 漏洞，那么该有效负载">
hello
应该足以证明潜在的 XSS，而无需实际利用它。
这样做时，您可以手动确认安全错误的存在，而不必冒被过滤、WAF 阻止、CSP 阻止等的风险。
有效的模糊测试有效负载可能如下所示：
该有效负载的目的是触发一般错误、引用爆发、模板引擎错误、XSS 检测、格式注入和暴露来自目标的无效输入消息。
用于有效负载的参考
根据应用程序中使用的技术调整我们的有效负载，然后我们就有更好的机会在目标中触发意外行为。
然而，为特定上下文设计有效负载非常耗时。一个折衷的解决方案是创建一个多语言有效负载，它可以容纳大多数技术的结构，并且可以在多个上下文中测试应用程序。
例如，最常见的语法错误是奇数个引号、方括号、括号或反斜杠。有了这些知识，我们就可以为我们的一般测试制作高精度的有效载荷。
结构变化
有效负载的结构是其最重要的部分。想象一下，有效负载在 Web 应用程序中触发服务器错误（意外行为），而原因集中在反斜杠字符上。
您测试了两个长度（字符数）相同的有效负载，但只有一个有效负载触发了意外行为：
Payload 1: 'z
Payload 2: z'
但哪一个触发了意外的输出呢？让我们考虑一下可以解释每个有效负载行为的理论。
1.第一个有效负载：有效负载很可能通过使用反斜杠字符转义最后一个引号来突破输入部分。这将导致语法错误，因为原始引号在后端将是奇数。
2.第二个有效负载：后端尝试解析z为转义序列。然而，有效的转义序列（如n或 ）t可能不会触发错误，因为有效负载包含z. 然后，服务器可能会尝试将其解析为有效的转义序列并失败，从而导致转义序列错误。
请记住，如果仅使用一种有效负载，则您有50% 的机会无法检测到意外行为。测试多种结构变化会增加取得突破的机会。
识别代码模式和行为
当有效负载在应用程序中触发意外行为时，它会提示以下问题：行为在哪里触发以及如何触发？
反射输出
当我们的测试负载反映在响应中时，我们可以更轻松地确定触发行为的位置。输入的反射可以来自多个不同的源，例如 DOM JavaScript 或后端服务器。以下方法有助于确定反映您的输入的来源。
DOM JavaScript
检测客户端 JavaScript 是否反映输入的最快方法就是在不启用客户端 JavaScript 的情况下向应用程序发出请求。这样，即使 JavaScript 未在客户端运行，您也可以查看您的输入是否得到反映，从而了解客户端 JavaScript 是否反映了输入。
请记住，客户端 JavaScript 也经常用于获取跨源请求，以便从其他服务器检索数据。在传出请求中包含用户输入是很常见的，有时您的输入在反映之前会被此过程修改。
后端服务器
要检测输入是否直接来自后端，我们可以使用与检查反射是否来自客户端 JavaScript 相同的技术。当我们的输入数据在没有运行客户端 JavaScript 的情况下被反映时，它是由后端服务器管理和反映的。唯一的问题是：哪一个？
这在很大程度上取决于我们正在测试的应用程序，我们的反射可能来自的一些可能的服务器可以是应用程序的后端、CDN、WAF 或与应用程序相关的其他代理服务器。
我们可以通过分析 HTTP 响应标头和/或响应文本来回答这个问题，看看它们是否暗示哪个源反映了我们的输入。
跟踪错误
此行为往往会暴露触发错误时使用的代码行和函数。通过提供此信息，跟踪错误使我们能够收集可能用于利用功能中的安全缺陷的代码片段、第三方代码或CVE 。
内容变更
内容的变化可能是最容易或最难确认的行为之一，无论它们是否意外。如果它们是应用程序响应中的较大更改，例如用以前未见过的新文本替换响应文本，那么它们很可能是易于确认的意外行为。
当答案出现微小变化时，挑战就开始了。这是因为大多数现代 Web 应用程序都基于定期更改的高度动态内容。在这种情况下，我们需要深入了解应用程序的工作原理，以便能够检测到实际上是由我们的有效负载触发的意外行为的微小变化。
我们过滤掉的动态垃圾内容越多，我们对响应内容的管理就越有效。如果属性和属性值似乎代表正常行为，我们可以通过首先提取并关注 HTML 节点来做到这一点。剩下的就是检查一般响应文本，例如单词和响应标题。
下一步是收集所有独特的单词，并将单词和标题与正常响应行为进行比较，以便识别与正常响应不匹配的单词。
Burp Suite具有内置功能 - “比较”选项卡 - 可以有效地比较这些响应。名为 Diff Last Response 的 Burp 扩展在这里也很有用，它可以比较当前和先前的响应以检测差异。
响应时间
服务器可能会产生不同的响应延迟。如果有效负载碰巧触发的延迟明显长于或短于平均延迟，则可能是由于应用程序中触发了我们尚未检测到的错误。
为了确认响应时间行为，我们通常必须停止应用程序的所有其他后台扫描和测试。这意味着我们可以将任何时间延迟归因于我们的有效负载，而不是应用程序超载或在不同进程中触发意外行为的另一个有效负载。
实际有效负载演示
之前创建的有效负载（请参阅“有效负载创建”）被随机插入到 OWASP Juicy Shop 和 DVWA 应用程序中的用户输入部分，以提供对有效负载在现实场景中可以完成的任务的基本了解。您可以在下面看到有效负载触发的意外行为：
正如您所看到的，我们仅通过在不同的输入部分中随机插入有效负载就产生了许多点击。虽然这些应用程序的核心显然容易受到攻击，但这仍然是测试和演示有效负载的准确性并了解其触发某些行为的有效性的有用方法。
原文始发于微信公众号（红队笔记录）：Web 应用程序黑盒测试
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论