使用Fuzzing自动检测Web应用程序中的漏洞(半机翻有删增)

摘要

自动检测漏洞是文献中研究的问题,也是具有安全要求的应用程序开发中非常重要的问题。Fuzzing是一种软件测试技术,自动或半自动化,涉及在软件中注入大量半随机输入以解决安全漏洞。许多漏洞检测技术需要专业人员进行手动分析,以确定是否存在任何漏洞。为了解决这个问题,决定开发一个使用模糊测试自动检测Web应用程序漏洞的系统。检测Web应用程序中的漏洞与在其他类型的软件中检测不同。发生这种情况是因为Web应用程序包含许多后端组件,这会导致特定的漏洞,因此,它可以方便地监视这些组件。这项工作提供了一个模糊Web应用程序的框架。在这项工作中,在每个Web应用程序组件内部进行监视。该框架检测一组有代表性的Web应用程序漏洞:SQL注入、本地或者远程文件包含、反射型或者存储型XSS。我们的SQL注入检测机制能够检测最近提出的这一类别的细微攻击。我们使用易受攻击的代码示例和开源Web应用程序对框架进行实验性评估。

介绍

漏洞检测是文献中广泛研究的主题,也是具有安全性要求的软件开发中的一个非常重要的问题。通过模糊测试发现了许多软件漏洞。Fuzzing 是一种软件测试技术,涉及在软件中重复注入半随机输入,以便由目标应用程序处理,并检查是否存在与预期不同的行为。如果是这样,某个输入可能会利用错误或漏洞。

此外,模糊测试是一种半自动或自动化过程,其中包括发送更有可能利用漏洞的值。有两类模糊器:基于突变和基于生成。基于变异的模糊器通过在输入中应用微小变化而不改变其结构来创建测试用例。基于生成的模糊器通过目标知识创建测试用例。

许多Web应用程序都具有复杂的体系结构,这是一个挑战,也是检测某些注入是否利用漏洞的机会。在非Web应用程序(如网络服务或命令行)中,模糊器仅尝试发送输入,但用户必须了解目标软件中是否存在任何异常行为。其他机制试图通过观察崩溃,监视CPU时间或内存消耗来检测异常行为。但是,用户需要了解这些异常是否是软件中的漏洞。许多Web应用程序漏洞与后端组件相关,例如,数据库管理系统(DBMS)或文件系统,这使监视变得复杂,但也允许在这些点上执行此操作。

本文提出了一个框架,用于模糊Web应用程序,以满足这一挑战和机遇。该工作的主要重点是监控目标应用中的注入效应,因此主要在其组件内部进行。

在Web应用程序组件中进行监视非常重要,因为:

1)它是传入数据流结束的点,因此是脆弱性的关键点;
2)作为输入流程结束的最后一点,关于如何处理输入的假设较少,例如,是否存在任何编码或验证过程;
3)允许使用组件功能以检测漏洞并进行有效检测。

该框架旨在检测输入验证漏洞,但在当前版本中,只实现了它们的一部分:SQL注入(SQLI);本地/远程包含(LFI / RFI);反射/存储的跨站点脚本(XSS)。选择这个漏洞子集是因为SQL和XSS几年来被认为是风险最高的漏洞,而LFI / RFI对用PHP编写的Web应用程序有特殊影响。

PHP语言目前在超过77%的Web应用程序中使用,这就是我们考虑它的原因。这项工作还展示了如何扩展框架以检测其他输入验证漏洞。

该框架被实现为由Zend Engine执行的PHP应用程序中的漏洞并使用MySQL作为DBMS。它通过小型易受攻击的代码示例和开源应用程序进行评估,同时考虑到发现的漏洞数量。

这项工作的主要贡献是:

1)一个模糊测试框架,其中包含一套监视多种攻击的机制;
2)基于缺乏输入验证来实现几种检测漏洞的机制。这些漏洞有:SQL注入;本地/远程文件包含;反射/存储的跨站脚本
3)框架的实验评估考虑了易受攻击的代码和开源应用程序。

背景

检测漏洞利用

要确定是否漏洞已被利用,必须存在可以检测目标系统状态的监视机制或资源,尤其是在出现故障的情况下,例如:可记录任何故障或执行异常的日志文件;允许识别系统中的异常的调试器;应用程序返回的代码或消息;检查与目标系统的连接是否仍然存在。但是,此类机制尚未集成到模糊器中,因为无法准确检测利用Web应用程序中的漏洞的攻击。

web 应用漏洞

本节简要介绍了当前版本框架中考虑的漏洞。 对于每种类型的漏洞,都存在具有相同名称的相应攻击,例如,SQL注入攻击/漏洞。

SQL注入漏洞

允许攻击者使用输入来误导目标应用程序,以构建意外查询并将其提交到数据库。当用户的输入未经过验证并且攻击者可能通过插入SQL关键字来更改查询的结构时,就会发生此类攻击。如果此类攻击对目标的行为有立即影响,则称为一阶SQL注入。在二阶SQLI攻击中,攻击者首先向目标应用程序提供一个输入,它将存储在数据库中;之后,攻击者提供第二个输入,该输入创建查询以提取存储的最后一个查询,然后创建第二个修改查询。

RFI漏洞

允许攻击者从外部Web服务器中包含文件。此漏洞的发生是由于缺少用户输入的验证,允许攻击者通过包含函数包含远程内容,例如PHP中的函数包含。

LFI漏洞

与之前类似,但包含的文件必须存在于应用程序服务器中。为了执行此类攻击,首先,必须加载恶意文件或在现有本地文件中添加恶意内容(例如:日志文件)。在那之后,它只需要包含这个恶意的本地文件。

反射型XSS漏洞

当Web应用程序信任来自用户的输入并在响应中回显它们而没有经过验证、清理或编码时就会存在反射型XSS漏洞。 如果这些输入中的任何一个包含脚本,它将在受害者的浏览器中执行,并带来一些后果。

存储型XSS漏洞

基于先前漏洞的相同原则,仅在这种情况下,目标应用程序首先存储数据并随后回显它。

检测特定的Web应用程序漏洞

在本小节中将讨论以下漏洞的几种检测技术:SQL注入,本地/远程文件包含和跨站点脚本。

有许多方法可以检测SQLI漏洞。

Halfond和Orso的解决方案,通过静态代码分析检测这种类型的攻击,并在运行时监视应用程序。此外,还有一种解决方案CANDID基于SQL注入更改查询结构的原则。在此解决方案中,通过发送良性输入,作者打算提取所需的查询模型,以便与从未来请求生成的模型进行比较。如果模型之间没有匹配,则表示存在SQLI漏洞。这种方法不同于本工作中实现的SQLI检测机制,因为CANDID需要更改目标应用程序,而且,提取查询结构是DBMS的一个外部工具,可能无法提取查询结构。

关于检测RFI漏洞的机制

他们假装检查在到达关键功能(例如包括)之前是否存在不安全的输入是否是任何验证,消毒或编码过程的目标。如果是,则输入变得安全,否则可能利用漏洞。 中

还有一种解决方案发送一个输入,该输入引用被监视的远程服务器中的资源,以确定它是否已从目标应用程序接收到任何请求。如果是这样,Web应用程序容易受到攻击,因为它试图包含目标远程文件。

检测LFI漏洞

为了检测LFI漏洞,提出了一种解决方案,其中作者建议在目标应用程序中包含可执行资源,并确定应用程序行为是否有任何变化。

要检测XSS漏洞,有几种机制

一种机制基于静态分析。这些机制控制程序的执行,在作为响应发送之前,检查用户的输入是否是任何验证或清理过程的目标。除了这种方法之外,还有一种方案使用代理来分析对应用程序及其响应的请求。此解决方案检查请求中是否存在与HTML标记对应的任何字符。如果是,则该机制检查相应的响应是否包含相同的现有标记,以检查目标应用程序中是否存在任何漏洞。

其实就是一种是检查请求是否有异常,另一种是键查响应是否有异常

框架

它开发了一个框架,用于模糊测试Web应用程序并通过嵌入在后端组件中的机制监视它们的影响。接下来,将介绍框架的体系结构及其组件。

体系结构

Framework的体系结构如下图所示,其中包含其组件:

此处输入图片的描述

Fuzzer:

生成在目标Web应用程序的某些入口点注入的输入。此外,它还包含反映XSS攻击的监视机制。

Web应用程序:

顾名思义,它是由框架测试的Web应用程序。 它插入到具有特定操作系统的Web服务器中,并与许多后端组件(例如数据库,文件系统)通信;

服务器端语言解释器:

其中包括由于缺少输入验证而导致的漏洞的几种检测机制。如果它们分别与文件系统,DBMS或操作系统交互,则这些漏洞分为三类。

(1)监视执行的位置
监视以下漏洞:本地/远程文件包含(LFI / RFI);目录/路径遍历(DT / PT);源代码泄露(SCD)。
(2)检测存储的XSS攻击的机制
(3)OS命令包含攻击(OSCI)的监视机制
(4)还有一种服务器端语言代码注入攻击的监视机制。

数据库管理系统:

从Web应用程序接收查询并对其进行处理。它包含SQL注入攻击的监视机制。

特性

接下来,将展示开发框架的每个组件中存在的所有功能。

Fuzzer

fuzzer 基于通过模糊矢量生成输入,将自身插入迭代 fuzzer 的类别中。这些模糊测试向量包含一组先前选择的输入,包含几个存在的攻击特征。此外,fuzzer 对这些向量的每个元素应用突变机制。该机制随机地选择输入字符的子集以进行小的改变(例如:字符替换),从而产生可能意外地利用漏洞的更多种输入。

fuzzer 允许在发送输入之前将目标应用程序置于特定状态,将其自身插入内存模糊器的类别中。因此,可以手动地定义一系列请求以将目标应用程序置于给定状态或在发送特定输入后重置目标应用程序的状态。这一系列请求包含以下类型的HTTP请求:GET和POST。

此外,fuzzer 负责通过HTTP协议将生成的输入注入目标应用程序。为此,模糊矢量的每个元素的 fuzzer 发送其原始版本和它们的突变。如果启用了状态定义机制,则首先,fuzzer发送与预状态进程相对应的HTTP请求,即将目标应用程序置于某个状态以便对其进行测试。置于特定状态,fuzzer 将输入发送到目标应用程序。稍后,如果需要重置目标应用程序的状态,则 fuzzer 发送HTTP请求以重新建立其状态。重复执行此过程,直到所有输入都发送到目标应用程序。

检测SQL注入

在DBMS中检测到这种类型的漏洞,因为该机制使用其资源,更具体地说是其解析器。在下面的解释中,我们考虑了MySQL的具体情况,因为它是实现中使用的DBMS。

SQLI攻击检测的主要目标是识别某个查询是否接收来自用户的输入,如果其结构发生变化则考虑到良性模型结构。因此,首先,有必要确定目标应用程序中每个查询的预期行为。此标识的目的是能够比较某个查询的不同执行并检查其行为是否发生变化。如果是这样,应用程序中存在漏洞。

在MySQL的特定情况下,查询的结构可以被解释为堆栈或后序树。但是,MySQL将查询的结构存储在列表中。
接下来,通过SQLI检测机制呈现下面查询语句的结构。

SELECT * FROM user WHERE Age<23

此处输入图片的描述

为了理解查询的结构,必须从下到上观察其项目。

查询结构中的第一个元素是指FROM元素,在本例中是表用户。之后,它引用SELECT子句返回的元素,在本例中为所有collumns(符号*)。接下来,有一个对年龄和整数23的引用,并且应用这两个项目<操作,如上面的项目所示。

在此解决方案中,假设输入是良性的,首先执行接收输入的某个查询,定义查询的模板。因此,当第一次执行查询时,在运行时,机制将存储其结构。将在以下相同查询的执行中将此模板与获得的结构进行比较。

为了正确的操作机制,必须存在训练阶段,对其中执行代码中的所有点执行从具有良性内容的用户接收输入的查询以便生成模板。

在以下查询的执行中,将获得的结构与在训练阶段生成的相应模板进行比较。这种比较必须能够容忍某些方面,否则会产生许多误报。

例如,假装将给定属性与用户指定的值进行比较的查询必须容忍所提供的不同值。此外,它应该容忍使用与预期不同的值,但由于类型转换操作,这些值的含义是相同的。因此,该机制在称为基本类型的类别中考虑整数,浮点数,实数和字符串类型。

因此,该检测机制从获得的结构中观察每个元素,并检查类型(第一元素)和参数(剩余元素)是否与模板中的对应元素完全相等,除了在一种情况下。当查询结构的某些元素引用基本类型时,不必分析其参数,只需要模板中的对应元素为基本类型。

如果给定查询获得的结构与相应模板不对应,则意味着输入已更改查询的结构,并且它正在利用SQLI漏洞
该机制可以检测两种类型的SQL注入攻击:结构和模仿。此外,此机制能够检测一阶和二阶SQLI漏洞,因为在这两种情况下,当漏洞被利用时,查询结构会发生变化

出于安全目的,在模板中,不存储原始类型的参数,因此不可能提取任何敏感信息(例如密码)。

为了演示这种机制,我们假设以下查询:

SELECT info FROM users WHERE password = $input。

此查询执行两次:第一次为了生成带有良性输入’xpto’的模板;第二个为了用恶意输入攻击’evil’ or 1 = 1。下图显示的结构,分别表示为两个执行的堆栈,

此处输入图片的描述

(a)模板
(b)恶意查询的结构(以粗体输入)

可以观察到结构之间的差异,因为它在查询中包含恶意SQL代码作为输入,因此,该机制可以识别出SQLI漏洞。

检测本地/远程文件包含

要检测LFI / RFI攻击,必须在每个文件包含函数调用中提取有关包含文件的信息,例如,在PHP语言函数include和require中。这种检测是在服务器端语言解释器内进行的

当第一次执行某个文件包含函数时,假设使用良性输入,机制定义该调用的预期行为,以便与该位置的未来的执行情况进行比较,将其定义为模板。此模板通用于涵盖所有良性输入,但也限制为排除恶意输入。存在训练阶段是必要的,其中存在这种类型的函数的代码中的所有位置都用良性输入执行以便生成相应的模板。
模板包含文件的路径和扩展名。如果文件是远程的,则路径包括外部地址的协议(例如:http://)

选择这些元素作为模板的一部分的原因基于两个原则:当攻击者假装包含本地或远程文件时,文件的路径必须通过路径遍历或包括外部地址协议来改变,而在正常执行中路径保持不变;当有一个文件包含时,它的扩展在执行时是相同的,因此认为改变文件的扩展是一个危险的操作。

在以下执行中,检测机制将特定调用中包括的文件与相应模板进行比较。如果包含文件的路径或扩展名与模板中定义的路径或扩展名不同,则表示目标应用程序中存在漏洞。

接下来,该机制检查是否包含文件。如果是这样,该机制会漏洞利用漏洞,否则会警告漏洞会被利用。

只有当攻击者试图在模板中包含具有相同路径和扩展名的恶意文件时,则出现此机制的限制

检测存储型 XSS

为了检测存储型XSS攻击,每当执行查询时,该机制都会检查按查询返回的内容是否包含Web浏览器可以解释的任何代码。此检测在服务器端语言解释器中进行,内容分析通过解析工具进行,该工具检查其中是否有任何代码。解析工具分析查询返回的内容,并检查是否有任何HTML或JavaScript代码标记(例如<script>

在通过解析工具分析内容之前,该机制会对此进行预检查,因为查询返回的大多数内容都是无害的,从而导致性能开销。此预检查假装验证是否存在任何危险字符(例如:<,>)或字符串(例如:href,javascript)。如果是这样,查询返回的内容是解析工具分析的目标,否则是无害的,没有必要进行任何进一步的分析。

如前所述,在预检查阶段之后,解析工具分析查询返回的内容并检查是否存在可由Web浏览器解释的任何代码标记。如果是这样,则检测机制通知存储的跨站点脚本攻击。

检测反射型 XSS

此机制检测是否发送脚本作为Web应用程序的响应。此检测在 fuzzer 内部进行。在 fuzzer 向应用程序发送输入之前,需要在考虑存在的情况下分析这些输入 代码(例如:HTML,JavaScript)。 如果是,则机制通过输入向目标应用程序发送HTTP请求。 接下来,分析应用程序的响应。

该分析通过Smith-Waterman算法检查响应是否具有重要的输入部分。该算法用于计算生物学领域,在两个字符序列之间进行局部对齐,并通过评分系统工作。在该得分系统中,当两个字符之间存在匹配时添加点,否则扣除点。这些分数可能因目标字符而异,例如,字符<和>的分数高于其他字符,因为它在此漏洞中具有重要性。该算法返回具有最高相似性的字符子序列,即其得分是最高的。在检测机制的目的中,它执行输入和应用程序响应之间的局部对齐,以获得与输入具有更高相似性的响应子序列。如果获得的分数是完美的,即获得的子序列与输入完全对应的,我们可以得出结论,目标应用程序是易受攻击的如果获得的分数不完美但高于阈值,则机制检查从算法获得的子序列。该分析想要检查子序列中是否有任何代码。如果是这样,那么它就是一个漏洞,否则被视为应用程序显着改变了输入。

作为限制,机制可能无法识别某些输入中的代码,因此无法识别漏洞,或者与输入相比,响应中的响应发生了显着变化,但仍然触发了攻击。

在正常执行中,将作为输入插入字符串Miguel,其未标识任何代码,因此不发送输入。假设将恶意内容

<script> alert(“XSS”)</script>

作为输入插入,这被标识为代码,因为有脚本标记,因此发送输入。当收到响应时,会对此进行分析,并确定输入中的现有代码完全包含在响应中,即通知存在反射型 XSS 漏洞

为了证明这种机制,请考虑以下代码示例,它接收来自用户的输入,并在后面反射它,它是这样的:

$name = $ GET[ ' name ' ] ;
echo "Welcome " . $name ;

检测其他漏洞

如前所述并在图1中提到,可以扩展框架以检测Web应用程序中存在的其他漏洞,例如,OS命令注入漏洞(OSCI),服务器端语言代码注入,目录/路径遍历和源代码泄露

框架旨在分析与这些漏洞相关的敏感接收器,并检查是否存在任何漏洞利用。为此,需要修改与每个漏洞相关的后端组件,并收集有关应用程序从用户发出的请求的信息。

该信息集中在请求结构中,以便根据用户的输入检查结构是否存在任何差异。在第一阶段,有必要收集每个调用与这些漏洞相关的函数的良性模型。接下来,当执行特定调用时,将获得的结构与各自的良性模型进行比较。如果存在差异,则机制通常存在漏洞,因为请求的结构与从良性输入获得的结构不同

实现

本节介绍了框架的架构,并考虑了实现的组件(如下图),此外,它还解释了框架的组件是如何实现的,即以下漏洞的模糊和检测机制:SQL注入,本地/远程文件包含和反射/存储XSS。

此处输入图片的描述

Fuzzer

为了实现fuzzer,它使用了由OWASP开发的名为JBroFuzz(版本2.4)的工具,该工具包含一个fuzzer以及一个包含多个类的库,这些类允许实现包含各种功能的fuzzer:模糊向量或模糊测试有多个参数。由于JBroFuzz fuzzer 不包含监视攻击的机制,因此必须使用此库来创建具有检测 XSS攻击机制的fuzzer。

还有必要实现其他功能:输入变异机制;使用生成的输入发送HTTP请求。关于模糊向量,fuzzer 模糊器包含针对每个漏洞的攻击签名,这些漏洞假装从不同的源和复杂性中检测到

Web应用程序经历了几个状态,其中只有一些是易受攻击的。 因此,当使用模糊测试来检测目标应用程序中的漏洞时,重要的是在所有不同的状态下进行并在每个状态下进行模糊测试。 fuzzer的当前实现包含一种机制,允许手动定义一组HTTP请求以将目标应用程序置于特定状态或在发送输入后重置应用程序的状态。 可以提供请求的类型,URL,参数和cookie。

检测 SQLI

要实现这个机制,有必要修改MySQL(版本5.7.4。),更具体地说,解析函数(mysql parse - le sql parser.cc)添加14行代码。此外,它创建了一个带有1098行代码的标题文件,以实现检测机制。通过这些更改,可以检测到多个SQLI攻击。

要实现这种机制,有必要修改MySQL(版本5.7.4。),更具体地说,解析函数(mysqlparse-sql parser.cc)添加14行代码。 此外,它创建了一个带有1098行代码的标题文件,以实现检测机制。 通过这些更改,可以检测到多个SQLI攻击。

此外,有必要以MySQL注释的形式向每个查询添加标识符。发生这种情况是因为这些标识符可以在应用程序中知道执行某些查询的位置。因此,程序员能够通过代码分析了解某些漏洞的原因。如果在查询中没有这样的标识符,MySQL继续正常运行只是不是机制的目标。

当前实现仅允许分析包含以下命令的查询:SELECT,INSERT INTO,UPDATE,FROM,WHERE,HAVING,ORDER BY,GROUP BY。

检测本地/远程文件包含

为了实现这个机制,有必要修改PHP解释器(版本5.5.12),即Zend Engine。这些更改集中在解释器的函数中,这些函数在PHP语言中实现文件包含函数(例如:include,include once,require和require once)。由此可以提取与包含目标相关的信息,并检查目标应用程序是否易受攻击

需要更改名为compile_file(zend_language_scanner.c)的ZendEngine函数。此函数接收将由PHP编译的文件作为参数,在本例中为包含的目标。

有必要在每个包含函数调用中添加一个标识符,以便知道代码中哪个位置确定包含。如果没有这样的标识符,PHP继续正常运行只是不是检测机制的目标。

为了提取有关包含函数标识符的信息,它被修改为file_zend_vm_execute.h,共有116行代码。通过更改此功能,检测机制能够区分漏洞警告和攻击真正利用漏洞的时间。

关于模板,它们通过包含相关信息的文件永久存储。

检测存储型 XSS

为了实现这个机制,它被修改了Zend Engine(版本5.5.12)。这些修改主要集中在实现PHP函数mysql查询的解释器函数,更具体地说,函数php mysql在Zend Engine中执行查询。

要分析查询返回的内容,有必要检查其中是否有任何代码,例如HTML或JavaScript。因此,它使用了一个用Java编写的解析工具(antixss.jar),它包含一个解析库,即jsoup(版本1.7.3),该库旨在解析HTML页面或其他类似语言(例如JavaScript,CSS)考虑到标签的存在。为了识别代码,机制为jsoup分析提供内容。此解析工具将内容插入到虚拟HTML页面中,由标记<html> <head> <body>表示,其中将进行解析。

利用通过解析过程获得的结构,将检查除了虚拟页面中的现有标签之外是否还存在至少一个代码标签。如果是这样,则意味着内容已更改结构并包含代码。

检测反射型 XSS

为了实现这个机制,它再次被用于jsoup库(版本1.7.3),但在这种情况下包含在fuzzer中(图3)。
关于Smith-Waterman算法,它是用Java语言实现的。有必要使用某些值来确定机制,以便在字符之间达成一致/不一致,间隙和所得到的得分与完美得分之间的相似性百分比被视为某种输入作为攻击。
如果两个角色之间存在协议(区分大小写),则会增加5分。当角色之间存在分歧时,这可以是三种类型:

  • 当对于包括对齐的子序列的空白空间的不一致关注从得分中扣除2个单位。这个惩罚是线性的,取决于添加的空格数量;
  • 当分歧指的是彼此不同但不是字符的两个字符< 或 >从分数中扣除5个单位。根据不同意见中的字符数,这种惩罚是线性的;
  • 当分歧指的是两个不同的字符时,其中一个字符<或>被扣除25倍于前一点扣除的单位。这是因为这些角色在反射型XSS 漏洞中的重要性,这种惩罚是线性的,取决于分歧中的字符数。

最后,当使用Smith-Waterman算法获得的分数大于完美分数的95%时,确定某些输入利用反映的XSS漏洞,即,如果对比较两个序列之间的所有字符,则获得分数。

结论

这项工作提供了一个框架,用于模糊Web应用程序并通过监视机制检测漏洞。所开发的解决方案与现有技术中提出的解决方案不同,因为在这项工作中,监视机制嵌入在Web应用程序的后端组件中。

这种类型的监控方法有许多优点:作为执行流的最后元素,不需要对以前的实体做出假设;不依赖于任何清理,验证或编码过程;使用来自Web应用程序组件的资源以帮助检测。

当前的框架版本可以检测到多个漏洞:SQL注入,本地/远程文件包含以及反射/存储的跨站脚本。

此外,该框架能够将目标应用程序置于特定状态,以便在所有状态下进行测试。

此外,SQL注入检测机制在考虑Ray和Ligatti代码注入定义的情况下进行了测试。我们可以得出结论,开发机制比其他最先进的机制表现更好。

关于未来的工作,我们考虑开发剩余的漏洞检测机制:OS命令注入;服务器端语言代码注入;目录/路径遍历;源代码披露。此外,可以通过状态识别功能来自动地分析目标应用程序并推断其执行状态,从而改进 fuzzer。

个人总结

本文介绍了常见的漏洞检测技巧

sqli : 静态代码分析和动态执行监控(动静结合),模型检测法
L/RFL : 包含远程文件或者是可执行文件,观察远程服务器或者本地服务器的变化
XSS : 一种是检查请求是否有异常,另一种是键查响应是否有异常

并开发了一个自动化的框架去实现这些检测

原文链接

Automatic Detection of Vulnerabilities in Web Applications using Fuzzing

文章目录
  1. 1. 摘要
  2. 2. 介绍
  3. 3. 背景
    1. 3.1. 检测漏洞利用
    2. 3.2. web 应用漏洞
      1. 3.2.1. SQL注入漏洞
      2. 3.2.2. RFI漏洞
      3. 3.2.3. LFI漏洞
      4. 3.2.4. 反射型XSS漏洞
      5. 3.2.5. 存储型XSS漏洞
    3. 3.3. 检测特定的Web应用程序漏洞
      1. 3.3.1. 有许多方法可以检测SQLI漏洞。
      2. 3.3.2. 关于检测RFI漏洞的机制
      3. 3.3.3. 检测LFI漏洞
      4. 3.3.4. 要检测XSS漏洞,有几种机制
  4. 4. 框架
    1. 4.1. 体系结构
      1. 4.1.1. Fuzzer:
      2. 4.1.2. Web应用程序:
      3. 4.1.3. 服务器端语言解释器:
      4. 4.1.4. 数据库管理系统:
    2. 4.2. 特性
    3. 4.3. Fuzzer
    4. 4.4. 检测SQL注入
    5. 4.5. 检测本地/远程文件包含
    6. 4.6. 检测存储型 XSS
    7. 4.7. 检测反射型 XSS
    8. 4.8. 检测其他漏洞
  5. 5. 实现
    1. 5.1. Fuzzer
    2. 5.2. 检测 SQLI
    3. 5.3. 检测本地/远程文件包含
    4. 5.4. 检测存储型 XSS
    5. 5.5. 检测反射型 XSS
  6. 6. 结论
  7. 7. 个人总结
  8. 8. 原文链接
|