了解最新技术文章
当Burp Scanner在扫描期间进行审核时,它会分析应用程序的流量和行为,以识别安全漏洞和其他问题。Burp Scanner 采用多种技术来准确审核目标应用程序。
每次审核都包含几个阶段。审核阶段分为三种类型:
被动阶段。
活跃阶段。
JavaScript 分析阶段。
Burp 在每个区域内执行多个阶段,以使其能够:
查找并利用存储和返回用户输入的函数。
有效处理经常出现的问题和插入点,避免重复。
并行执行适用的工作以充分利用系统资源。
Burp 可以检测各种不同严重程度的问题。
可用的问题按 Burp Scanner 检测问题必须采取的操作类型进行分组:
被动- 可以纯粹通过检查应用程序的正常请求和响应来检测的问题。例如,HTTP 消息中的序列化对象。
轻度活动- 可通过发出少量良性附加请求来检测的问题。例如,信任任意来源的跨域资源共享(CORS)。
中等活跃- 通过发出应用程序可能合理地视为恶意的请求可以检测到的问题。例如操作系统命令注入。
侵入性活动- 可通过发出具有损坏应用程序或其数据的重大风险的请求来检测的问题。例如SQL注入。
JavaScript 分析- 通过分析应用程序在客户端执行的 JavaScript 可以检测到的问题,例如基于 DOM 的跨站脚本。检测这些问题可能需要大量的系统资源。这些问题也可以归类为“被动”(针对基于 DOM 的独立问题)或“中主动”(针对反射和存储的变体)。
问题还可以按发现问题的级别进行分组:
主机级别- 作为运行应用程序的主机 HTTP 服务的一部分而出现的问题。例如,宽松的Flash跨域策略。
请求级别- 在单个请求级别出现的问题。例如跨站请求伪造。
插入点级别- 在请求内的插入点级别出现的问题。例如文件路径遍历。
有关 Burp Scanner 可以找到的漏洞的完整列表,请参阅Burp Scanner 检测到的漏洞。
Burp Scanner 使用插入点将有效负载放置到请求内的各个位置。通常,插入点表示请求中可能由服务器端应用程序处理的一段数据。以下示例显示了一个请求,并重点介绍了一些常见的插入点类型:
Burp Scanner 单独审核插入点,依次将有效负载发送到每个插入点以测试应用程序对该输入的处理。
每个插入点通常需要一种数据编码。Burp Scanner 根据插入点类型自动对有效负载应用编码,以确保原始有效负载到达相关的应用程序功能。
例如,Burp Suite 将以下编码应用于以下插入点中的参数:
标准机身参数:
JSON 数据中的参数:
XML 数据中的参数:
Burp Scanner 还会检测应用程序何时使用与插入点类型无关的编码类型,例如 Base64:
某些应用程序对同一数据应用多层编码,以将一种格式嵌套在另一种格式中。Burp Scanner 检测到这种行为,并自动将相同的编码层应用于其有效负载。
某些应用程序将输入放入一种类型的参数中,但如果输入以不同类型的参数提交,则仍会处理该输入。发生这种情况是因为应用程序用于从请求检索输入的某些平台 API 不处理保存输入的参数类型。但是,某些应用程序安全措施(例如防火墙)可能仅适用于原始参数类型。
为了利用此行为,Burp Scanner 可以更改插入点参数类型。这会创建可能绕过保护并访问易受攻击的应用程序功能的请求。例如,如果在 URL 查询字符串参数中提交有效负载,则 Burp 还可以在正文参数和 cookie 中提交相应的有效负载。
自动爬网之后的审核能够使用爬网结果在审核期间自动维护会话,无需用户配置。
当 Burp 审核单个请求时,它会识别从爬网起始位置到达该请求的最短路径:
Burp 确定在有效会话中重复传递相同请求的最有效方法。它重新走该路径以获取会话令牌的新样本。接下来,它测试路径的各种简化,以查看即使未遵循路径中的所有步骤,会话是否仍得以维持。
在许多情况下,可以简单地一遍又一遍地重新发出最终请求。发生这种情况的原因有多种:
该请求不包含会话令牌。
该应用程序使用可重复使用的 cookie 作为会话令牌。
该请求同时包含 cookie 和CSRF令牌,但 CSRF 令牌可以重复使用:
Burp Scanner 可能需要先发出先前的请求,然后才能发出正在审核的请求。如果应用程序使用一次性 CSRF 令牌,通常会发生这种情况。这使得每次都需要重新发出先前的请求,以获得新的令牌。
在极端情况下,请求之间的每次转换都受到一次性令牌的保护。这可能发生在导航受到严格控制的高安全性应用程序中。在这种情况下,重复发出请求的最可靠方法是返回起始位置并走完全路径到请求。
一旦 Burp 确定了重复发出要审核的请求的最有效方式,它就会执行审核。
当 Burp 执行审计检查时,它会定期监视应用程序的响应以确认其会话仍然有效。如果会话仍然有效,Burp 会在已完成的审核检查上设置一个检查点。
如果 Burp 发现会话不再有效,它会回滚到最新的检查点并从那里恢复。这有助于最大限度地减少会话管理的开销,并避免会话频繁丢失时出现无限循环。例如:
Burp Scanner 使用各种技术来最大程度地减少重复工作和重复问题的报告。
一些被动检测到的问题可能存在于应用程序内的不同位置。这可能是由于架构选择或公共页面模板的重用造成的。
由于平台级配置,整个应用程序可能存在一些问题(例如,如果未强制执行严格的传输安全性)。
默认情况下,Burp Scanner 会聚合所有重复项并在相关级别报告单个问题,以避免返回重复的问题。这可能是主机的 Web 根目录或在其下发现所有问题的特定文件夹。
某些插入点可能存在于应用程序使用的许多或所有请求中,但并不代表有趣的攻击面。例如,一旦设置,某些 cookie 可能会在每个请求中提交。
全面审核每个请求中的这些插入点会产生大量冗余工作。Burp Scanner 默认情况下会识别频繁出现但不会产生任何问题的插入点,并对这些插入点执行更轻量级的审核。如果轻量级审核发现任何表明服务器端处理的有趣行为,Burp 将恢复为对插入点的完整审核。
Burp Scanner 分析应用程序响应中的 JavaScript,以识别基于 DOM 的漏洞。为此,Burp 结合使用静态和动态分析:
静态分析- Burp Scanner 解析 JavaScript 代码以构建抽象语法树 (AST)。它可以识别攻击者可能控制的受污染源,以及可用于执行攻击的危险接收器。它还分析通过代码的数据流,以找到恶意数据从受污染的源传播到危险接收器的潜在路径。
动态分析- Burp Scanner 将响应加载到嵌入式无头浏览器中。它将有效负载注入到攻击者可能控制的位置的 DOM 中,并在响应中执行 JavaScript。它还创建鼠标事件以实现尽可能多的代码覆盖率(例如,在onclick
事件处理程序中)。它监视可用于执行攻击的危险接收器,并识别到达这些接收器的任何注入的有效负载。
这些静态和动态方法具有不同的优点和缺点。
静态分析发现了一些动态分析无法发现的漏洞。这是因为静态分析可以识别可以在正确情况下执行但在动态分析期间不会执行的代码路径。
例如,执行中的分支可能由攻击者控制的许多参数控制。静态分析能够识别和分析该分支并找到其中的污点路径,而动态分析由于所需参数的组合可能无法触发相关执行。
然而,静态分析很容易出现误报结果。出现这种情况是因为扫描将代码分支的某些组合视为可执行,但实际上它们不是可执行的。此外,它不理解自定义数据验证逻辑,这意味着从源到接收器的受污染路径实际上不可利用。
动态分析具有相反的特征。它不太容易出现误报,因为它观察到执行期间受污染的数据从源传播到接收器。这提供了漏洞的具体证据。
然而,当动态分析注入的受污染数据未到达接收器的情况下,动态分析可能会出现误报。这可能是由于应用程序的当前状态或其他数据的值造成的,攻击者可能能够控制这些数据。
Burp Scanner 利用了静态和动态方法的联合优势。在可能的情况下,系统会报告问题以及从这两种技术获得的证据。使用这两种方法检测到的问题都被视为确定的。仅通过静态分析检测到的问题的置信度较低。
对 Web 应用程序执行全面审核是一个侵入性过程。扫描过程中经常会遇到连接失败、传输超时或后端组件中断等问题。此外,Web 应用程序防火墙等保护措施可能会根据特定负载或某些参数中的意外值等因素断开连接。
在审核时,Burp 以精细的方式跟踪错误情况。如果特定操作导致错误,Burp 会将该操作标记为失败并继续执行下一个操作。您可以配置扫描,以便如果重复操作在同一活动级别失败,则整个级别将被标记为失败。如果错误继续发生,Burp 将逐渐将更多扫描标记为失败,如下所示:
个别审计检查。
单独的插入点。
正在审核的整个请求。
整个扫描。
Burp 最初会捕获详细信息,并在遇到错误时继续扫描,因为孤立的错误很常见。完成审核后,Burp 会执行多次后续操作以重试失败的操作。当特定应用程序组件(例如后端数据库)在部分扫描中遇到问题时,这非常有用。
如果观察到太多错误,Burp 还可以暂停或中止扫描,以便您可以调查问题。一旦应用程序稳定,您可以恢复或重复扫描。