本发明涉及网络安全技术领域，尤其涉及一种通用web应用漏洞检测、修复方法以及装置。
背景技术
伴随着互联网的迅猛发展，利用web漏洞进行网络攻击的事件时有发生。通用web应用漏洞是一种服务器入侵的主要渠道，通常通用web漏洞被曝光，如果用户没有及时修复，黑客就可以利用漏洞获取web服务的权限，从而进一步获得服务器的权限，所以如何在黑客利用前快速有效的检测出未修复的已存在通用web漏洞并且提前进行修复是避免黑客入侵造成损失的重要方式。
通用web漏洞的传统检测方式通常采用的是在主机外远程访问web应用，采用poc进行模拟远程攻击的方式进行探测，该方式首先要求远程可访问web服务，同时比较依赖于网络请求，效率较低，并且容易由于网络层中间的各种问题而导致检测失败或者出现误漏报的情况，另外无法进行修复。
技术实现要素：
为了解决上述技术问题，本发明提出了一种客户端性能测试方法、装置以及终端。
本发明的一方面，提供一种通用web应用漏洞检测方法，其特征在于，述方法包括如下步骤：响应于漏洞检测指令，获取所述通用web服务的物理路径；获取通用web漏洞的相对路径；拼接所述通用web服务的物理路径与所述通用web漏洞的相对路径，以获得通用web漏洞的绝对路径；判断所述通用web漏洞的绝对路径是否存在通用web应用漏洞。
本发明的另一方面，提供一种通用web应用漏洞修复方法，所述方法包括如下步骤：响应于漏洞修复命令，接收漏洞信息、与所述漏洞信息对应的替换文件以及通用web漏洞的绝对路径信息；判断存在通用web漏洞的文件是否存在；判断存在通用web漏洞的替换文件是否存在；判断存在通用web漏洞的文件与所述替换文件的特征值是否匹配；使用所述替换文件替换所述存在通用web漏洞的文件。
本发明的另一方面，还提供一种通用web应用漏洞检测装置，所述装置包括如下模块：物理路径获取模块，用于在接受到漏洞检测指令时，获取所述通用web服务的物理路径；相对路径获取模块，用于获取通用web漏洞的相对路径；拼接模块，用于拼接所述通用web服务的物理路径与所述通用web漏洞的相对路径，以获得通用web漏洞的绝对路径；判断模块，用于判断所述通用web漏洞的绝对路径是否存在通用web应用漏洞。
本发明的另一方面，还提供一种通用web应用漏洞修复装置，所述装置包括如下模块：接收模块，用于在接收到漏洞修复命令时，接收漏洞信息、与所述漏洞信息对应的替换文件以及通用web漏洞的绝对路径信息；漏洞文件判断模块，用于判断存在通用web漏洞的文件是否存在；替换文件判断模块，用于判断存在通用web漏洞的替换文件是否存在；特征值判断模块，用于判断存在通用web漏洞的文件与所述替换文件的特征值是否匹配；替换模块，使用所述替换文件替换所述存在通用web漏洞的文件。
本说明书提供的技术方案带来的有益效果包括：通过主机内的检测方式，定位web服务的物理路径，然后通过文件匹配和判断的方式直接定位和判断漏洞文件的存在与否与是否修复，以此来进行漏洞的检测，同时通过替换补丁文件的方式进行修复，该方式避免了网络等因素对结果的干扰，并且由于是对文件直接检查，所以该检测方式快速有效。
附图说明
为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1是本说明书实施例提供的检测系统构架和检测流程示意图；
图2是本说明书实施例提供的通用web漏洞修复流程示意图；
图3是本说明书实施例提供的通用web应用漏洞检测方法流程示意图；
图4是本说明书实施例提供的通用web应用漏洞检测方法流程示意图；
图5是本说明书实施例提供的通用web应用目录结构示意图；
图6是本说明书实施例提供的根据关键字串匹配判断是否存在通用web漏洞的子步骤方法流程示意图；
图7是本说明书实施例提供的通用web漏洞修复方法流程图；
图8是本说明书实施例提供的通用web应用漏洞检测装置原理框图；
图9是本说明书实施例提供的判断模块结构原理框图；
图10是本说明书实施例提供的第二判断子模块结构原理框图；
图11是本说明书实施例提供的终端的结构示意图。
具体实施方式
为了使本技术领域的人员更好地理解本发明方案，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分的实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本发明保护的范围。
如图1所示，其展示了本发明的一个应用场景中的检测系统构架和检测流程，不同于使用远程poc进行探测，该场景中利用主机内的代理(agent)对通用web应用对漏洞进行探测，即整个探测过程都是在主机本地实现的。本地主机代理(agent)会等待检测命令的下发，并在接收到检测命令后调用控制模块开启检测。检测包括两个分支：
第一分支，web服务物理路径探测模块探测本地主机web服务所在的物理路径，并在获取物理路径之后，对其进行临时存储。
第二分支，检测控制模块查询漏洞知识库或者从其它途径获取到通用web漏洞的相对路径以及通用web漏洞文件所对应的文件特征码，特征码可以是md5码，也可以是其它具有唯一标识作用的识别码，例如用于文件版本更新的内置码等等，其用途是确定检测到的文件是否与通用web漏洞文件是否一致，本说明书不对该特征码的类型进行限定。获取到的通用web漏洞文件相对路径和特征码被存在临时存储空间。
通过以上两个步骤之后，将第一分支获得的主机web服务所在的物理路径与通用web漏洞的相对路径进行拼接，获得完整的通用web漏洞的绝对路径。通过通用web漏洞的绝对路径可以对路径指向位置进行判断，看该位置是否存在文件。若该位置存在文件则该位置存在通用web漏洞的可能，可以通过后续判断确定该通用web漏洞的绝对路径所指向的位置是否存在通用web漏洞。
在一个可能的示例中，探测过程中采集漏洞对应关键缺陷文件的md5值，探测web服务物理路径，然后通过匹配相对路径的指定缺陷文件的md5值及文件内容中的关键字符串，以此进行漏洞存在与否的判断。还可以通过web应用漏洞的探测方式，通过对最新漏洞跟踪和分析，建立漏洞知识库。
本说明书中涉及的概念解释如下：
通用web应用漏洞：通用web应用指的是通过通用的web系统，如discuz、wordpress等进行部署搭建的web应用；而通用web应用漏洞则该类型web应用所包含的漏洞，通常该类型漏洞的出现会影响众多使用该对应系统的web服务。
漏洞知识库：用于存储已跟踪分析的通用web漏洞相关基础信息和匹配文件信息、md5值等。
agent:用于进行主机的相关监控和管理。
控制模块：用于进行检测整体处理控制。
web服务物理路径探测模块：探测主机内的web服务的物理路径。
检测控制模块：用于实际的文件探测和匹配。
结果回收模块：回收检测检测并存储数据库。
如图2所示，在一个可能的示例中，由于通用web漏洞是由于单个或者多个文件代码缺陷导致漏洞存在，可以通过替换补丁文件即可达到修复效果。该方式通过主机内的方式可以有效的探测主机内部署的web服务存在的通用web漏洞，同时通过替换文件的方式进行漏洞修复，避免了传统远程poc请求探测由于网络问题的各种限制，快速有效。
具体地，代理(agent)接收到修复命令后，调用检测得到的漏洞修复路径，该漏洞修复路径指向了存在通用web漏洞的文件。漏洞信息修复指令调用控制模块提取预置的漏洞修复补丁，以覆盖漏洞修复路径指向的缺陷文件，从而实现对漏洞的修复。
在一个可能的实施例中，如图3所示，提供一种通用web应用漏洞检测方法，所述方法包含如下步骤：
s310,响应于漏洞检测指令，获取所述通用web服务的物理路径。
漏洞检测指令是本地主机获得的外部指令，该外部指令可以是来源于外部服务器的网络指令，也可以是本地代理(agent)的指令，该指令用于触发本地主机对于通用web应用的漏洞检测。接收到漏洞检测指令后，则启动对通用web服务的物理路径的获取步骤。
通用web服务的物理路径则与web服务的部署有关，例如，a用户把网站部署在服务器的/data/www目录下，则/data/www目录构成了该通用web服务在服务器上的物理路径。web服务在服务器上的物理路径会随着用户对于网站的设定的路径而发生改变，例如，b用户把网站部署在服务器的/var/www/web目录下，则/var/www/web目录构成了该通用web服务在服务器上的物理路径；同理，b用户把网站部署在服务器的/var/temple/web目录下，则目录构成了该通用web服务在服务器上的物理路径。
因此，在web应用漏洞检测过程中，为了对通用web应用进行检测，第一步就是要获得通用web应用所在的物理路径，并根据获得的物理路径进行之后的检测。
s320,获取通用web漏洞的相对路径。
web应用漏洞同时伴随着缺陷文件的产生，缺陷文件的路径指向了导致漏洞的代码的文件的位置，其是一个通用web应用的相对路径，通过获取所述缺陷文件的路径可以获得通用web应用的存在位置。
通过获取通用web漏洞的相对路径，可以精确地确定通用web漏洞的存在位置，同时可以将通用web漏洞与缺陷文件的相对位置关系关联起来。即通过相对路径，获取与该相对路径相关联的文件，例如，通过相对路径/data/www/phpcms/classes/api/api.php，关联文件api.php；或者，根据路径/data/www/phpcms/classes/phpsso_server/plugin.php关联文件plugin.php。
如果获取通用web漏洞所在的文件，或者通用web漏洞所在文件的的相对路径，那么就可以确定在任何主机上存在web漏洞的文件所在位置，或者存在web漏洞文件所在的路径。
在一个可选的实施例中，通过预设的通用web漏洞数据库获得通用web漏洞所在的漏洞。通用web漏洞数据库可以通过外部获得，可以是已有的专家数据库，或者专用引擎查获的通用web漏洞。
在一个可选的实施例中，通过轮询预设的通用web漏洞数据库的方式获得一条通用web漏洞所在的漏洞。
需要说明的是，步骤s310和步骤s320中对于物理路径和通用web漏洞的相对路径的获取顺序是可以替换的，其不影响本发明实施例技术方案的实施，亦不会对后续的步骤产生任何影响。
s330,拼接所述通用web服务的物理路径与所述通用web漏洞的相对路径，以获得通用web漏洞的绝对路径。所述通用web漏洞的绝对路径，指向可能存在的通用web漏洞。
将步骤s310中获得的所述通用web服务的物理路径与步骤s320中获得的所述通用web漏洞的相对路径进行拼接。如此，可以获得对应服务器中通用web漏洞的绝对路径。
通用web服务的物理路径与所述通用web漏洞的相对路径拼接过程如下：若通用web服务的物理路径为/var/www/web，通用web漏洞的相对路径为/data/www/phpcms/classes/api/api.php，那么拼接后的通用web漏洞的绝对路径为/var/www/web/data/www/phpcms/classes/api/api.php。此时，如果在待检测主机中存在对应的通用web漏洞，那么可以通过对该绝对路径的文件实现检测。通过上述示例也可以看出，web服务的物理路径用于表示服务所在的真实物理路径，该路径通过上级目录路径的形式来表示。通用web漏洞的相对路径为则是表示可能存在漏洞的虚拟物理路径，该路径通过下级目录路径的形式来表示。
s340,判断所述通用web漏洞的绝对路径是否存在通用web应用漏洞。
在步骤s330通过拼接获得通用web漏洞的绝对路径之后，对该路径下是否存在漏洞进行判断。
基于上述步骤，即可以实现对于通用web漏洞的判断。
综上所述，本说明书实施例提供的方法，可以在主机内有效的探测主机内部署的web服务存在的通用web漏洞，避免了传统远程poc请求探测由于网络问题的各种限制，快速有效。
在一个可能的实施例中，如图4所示，提供一种通用web应用漏洞检测方法，所述方法包含如下步骤：
步骤s410,响应于漏洞检测指令，获取所述通用web服务的物理路径。
漏洞检测指令是本地主机获得的外部指令，该外部指令可以是来源于外部服务器的网络指令，也可以是本地代理(agent)的指令，该指令用于触发本地主机对于通用web应用的漏洞检测。接收到漏洞检测指令后，则启动对通用web服务的物理路径的获取步骤。
通用web服务的物理路径则与web服务的部署有关，例如，a用户把网站部署在服务器的/data/www目录下，则/data/www目录构成了该通用web服务在服务器上的物理路径。web服务在服务器上的物理路径会随着用户对于网站的设定的路径而发生改变，例如，b用户把网站部署在服务器的/var/www/web目录下，则/var/www/web目录构成了该通用web服务在服务器上的物理路径；同理，b用户把网站部署在服务器的/var/temple/web目录下，则目录构成了该通用web服务在服务器上的物理路径。
因此，在web应用漏洞检测过程中，为了对通用web应用进行检测，第一步就是要获得通用web应用所在的物理路径，并根据获得的物理路径进行之后的检测。
步骤s420,获取通用web漏洞的相对路径。
web应用漏洞同时伴随着缺陷文件的产生，缺陷文件的路径指向了导致漏洞的代码的文件的位置，其是一个通用web应用的相对路径，通过获取所述缺陷文件的路径可以获得通用web应用的存在位置。
在一个示例中，例如phpcms的通用web应用，其在固定的版本中的目录结构是固定的，如图5所示，在该通用web应用中，具有固定的目录结构，例如图中的api目录下面存在api.php文件，当缺陷文件出现在api.php中时，获取的通用web应用的相对路径即该文件所在的相对路径，例如/data/www/phpcms/classes/api/api.php，其中/data/www/phpcms/classes/是api目录的上级目录，图中未示出。同理,当缺陷文件出现在plugin.php中时，获取的通用web应用的相对路径即该文件所在的相对路径，例如/data/www/phpcms/classes/phpsso_server/plugin.php，其中/data/www/phpcms/classes是phpsso_server的上级目录，图中未示出。
通过获取通用web漏洞的相对路径，可以精确地确定通用web漏洞的存在位置，同时可以将通用web漏洞与缺陷文件的相对位置关系关联起来。即通过相对路径，获取与该相对路径相关联的文件，例如，通过相对路径/data/www/phpcms/classes/api/api.php，关联文件api.php；或者，根据路径/data/www/phpcms/classes/phpsso_server/plugin.php关联文件plugin.php。
如果获取通用web漏洞所在的文件，或者通用web漏洞所在文件的的相对路径，那么就可以确定在任何主机上存在web漏洞的文件所在位置，或者存在web漏洞文件所在的路径。
在一个可选的实施例中，通过预设的通用web漏洞数据库获得通用web漏洞所在的漏洞。通用web漏洞数据库可以通过外部获得，可以是已有的专家数据库，或者专用引擎查获的通用web漏洞。
在一个可选的实施例中，通过轮询预设的通用web漏洞数据库的方式获得一条通用web漏洞所在的漏洞。
需要说明的是，步骤s410和步骤s420中对于物理路径和通用web漏洞的相对路径的获取顺序是可以替换的，其不影响本发明实施例技术方案的实施，亦不会对后续的步骤产生任何影响。
步骤s430,拼接所述通用web服务的物理路径与所述通用web漏洞的相对路径，以获得通用web漏洞的绝对路径。
将步骤s410中获得的所述通用web服务的物理路径与步骤s420中获得的所述通用web漏洞的相对路径进行拼接。如此，可以获得对应服务器中通用web漏洞的绝对路径。
通用web服务的物理路径与所述通用web漏洞的相对路径拼接过程如下：若通用web服务的物理路径为/var/www/web，通用web漏洞的相对路径为/data/www/phpcms/classes/api/api.php，那么拼接后的通用web漏洞的绝对路径为/var/www/web/data/www/phpcms/classes/api/api.php。此时，如果在待检测主机中存在对应的通用web漏洞，那么可以通过对该绝对路径的文件实现检测。通过上述示例也可以看出，web服务的物理路径用于表示服务所在的真实物理路径，该路径通过上级目录路径的形式来表示。通用web漏洞的相对路径为则是表示可能存在漏洞的虚拟物理路径，该路径通过下级目录路径的形式来表示。
步骤s440,判断所述通用web漏洞的绝对路径所指向的文件是否存在。当通用web漏洞的绝对路径不存在文件时，即不存在与通用web漏洞对应的文件，那么可以确定该web服务中不存在该类型通用web漏洞。
步骤s450,当通用web漏洞的绝对路径存在文件时，比较该文件与通用web漏洞文件的特征值是否相同。
当通用web漏洞的绝对路径存在文件时，即存在与通用web漏洞对应的文件，此时对应文件有存在通用web漏洞的可能。但是此时并不能确定通用web漏洞的绝对路径指向的文件是存在通用web漏洞的文件。例如，通用web漏洞的绝对路径为/var/www/web/data/www/phpcms/classes/api/api.php，该路径的指向存在文件为api.php，不过，无法确定该api.php文件确实是存在通用web漏洞的文件。例如，由于版本升级，将原有的api.php文件更新为新的文件，从而消除通用web漏洞的情况，此时路径的指向存在文件，但是该文件并不是存在通用web漏洞的文件。因此，需要比较该api.php文件与存在通用web漏洞的文件的特征值，例如md5值是否是相同的，当特征值相同时，判断该文件存在通用web漏洞的文件；否则，该文件不是存在通用web漏洞的文件。
步骤s460,当文件与通用web漏洞文件的特征值不同时，那么可以确定该文件并不是可能产生通用web漏洞的文件，此时判定不存在通用web漏洞。
步骤s470,当文件与通用web漏洞文件的特征值相同时，根据关键字串匹配判断是否存在通用web漏洞。
当文件与通用web漏洞文件的特征值相同时，那么可以确定该文件是可能产生通用web漏洞的文件，此时需要对该文件进行特征关键字串比对，如果存在特征关键字段，则判定存在通用web漏洞；如果不存在特征关键字段，则判定不存在通用web漏洞。
在一个可能的实施例中，如图6所示，步骤s470具体包括：
步骤s4701，构建表征漏洞的正则表达式。
步骤s4702，使用所述正则表达式对文件代码进行匹配比对。
步骤s4703，当所述正则表达式与所述文件代码匹配比对相同时，判定文件中存在漏洞代码；
步骤s4704，当所述正则表达式与所述文件代码匹配比对不相同时，判定文件中不存在漏洞代码。
可以构架表征漏洞代码的正则表达，例如，$upload_func($file,$newfile)，由于漏洞是该代码产生的，如果该漏洞被修复，那么修复后的代码就与该代码的形式不同，这表明漏洞已经被修复，在匹配时，自然就无法匹配到该字符串，因此此时可以判断文件中不存在漏洞代码；与此相对地，如果漏洞没有被修复，文件中的漏洞代码一致存在，在匹配对比时，可以获得与正则表达相符的字符串，此时，判定文件中存在漏洞代码。
在例如$upload_func($file,$newfile)的正则表达中，利用$匹配输入行尾。在设置regexp对象的multiline属性之后，利用$匹配“\n”或“\r”也可以大大提高运行的效率。
在一个可能的实施例中，可以利用nfa引擎进行匹配回溯算法，以指定顺序测试正则表达式的所有可能的扩展并接受第一个匹配项。基于nfa构造正则表达式的特定扩展以获得成功的匹配，进而捕获子表达式匹配和匹配的反向引用。因为在匹配过程中，只需要寻找与指定的正则表达式匹配的漏洞代码，无需担心nfa引擎接受找到的第一匹配之后，导致其他可能更长的匹配未被发现。所以使用nfa引擎进行正则表达式的匹配可以大大节省匹配过程中的资源损耗，提高运行效率。
基于上述步骤，即可以实现对于通用web漏洞的判断。
在步骤s470之后，还可能存在对结果进行回收的步骤。
步骤s480，格式化检测结果。
在一个可选的实施例中，将检测结果加密并转换为固定格式的内容，如此，可以方便云端的处理模块可以将结果识别和处理入库。
步骤s490，上传检测结果。
通过本地代理(agent)上传结果到云端数据，可以在云端形成针对检测的专家数据库，方便本地的监测过程对数据库进行获取，或者对云端数据进行读取。
综上所述，本发明实施例通过对最新漏洞跟踪和分析，建立漏洞知识库，采集漏洞对应关键缺陷文件的md5值，探测web服务物理路径，然后通过匹配相对路径的指定缺陷文件的md5值及文件内容中的关键字符串，以此进行漏洞存在与否的判断。同时，由于通用web漏洞是由于单个或者多个文件代码缺陷导致漏洞存在，可以通过替换补丁文件即可达到修复效果。该方式通过主机内的方式可以有效的探测主机内部署的web服务存在的通用web漏洞，同时通过替换文件的方式进行漏洞修复，避免了传统远程poc请求探测由于网络问题的各种限制，快速有效。
在一个可能的实施例中，如图7所示，通过图3步骤s310-s340或者图4步骤s410-s490获得对于通用web漏洞的检测结果之后，还可能存在对漏洞进行修复的步骤：
在判断本地主机存在通用web漏洞之后，本地主机会将检测结果上传，例如通过代理(agent)将检测结果上传到控制台。在控制台确认本地主机存在通用web漏洞之后，则可以开启修复流程，向本地主机下发修复命令，并传递漏洞信息，补丁文件，检测出的存在缺陷的漏洞文件路径等等，本地主机则进行如下操作：
步骤s710，响应于漏洞修复命令，接收漏洞信息、与所述漏洞信息对应的替换文件以及通用web漏洞的绝对路径信息；
步骤s720，判断存在通用web漏洞的文件是否存在；
步骤s730，判断存在通用web漏洞的替换文件是否存在；
步骤s740，判断存在通用web漏洞的文件与所述替换文件的特征值是否匹配；
步骤s750，使用所述替换文件替换所述存在通用web漏洞的文件。
综上所述，基于步骤s710-步骤s750可以实现对于通用web漏洞的修复。
在一个可能的实施例中，如图8所示，提供一种通用web应用漏洞检测装置，所述装置包含如下模块：
物理路径获取模块,用于响应于漏洞检测指令，获取所述通用web服务的物理路径。
漏洞检测指令是本地主机获得的外部指令，该外部指令可以是来源于外部服务器的网络指令，也可以是本地代理(agent)的指令，该指令用于触发本地主机对于通用web应用的漏洞检测。接收到漏洞检测指令后，则启动对通用web服务的物理路径的获取步骤。
通用web服务的物理路径则与web服务的部署有关，例如，a用户把网站部署在服务器的/data/www目录下，则/data/www目录构成了该通用web服务在服务器上的物理路径。web服务在服务器上的物理路径会随着用户对于网站的设定的路径而发生改变，例如，b用户把网站部署在服务器的/var/www/web目录下，则/var/www/web目录构成了该通用web服务在服务器上的物理路径；同理，b用户把网站部署在服务器的/var/temple/web目录下，则目录构成了该通用web服务在服务器上的物理路径。
因此，在web应用漏洞检测过程中，为了对通用web应用进行检测，第一步就是要获得通用web应用所在的物理路径，并根据获得的物理路径进行之后的检测。
相对路径获取模块,获取通用web漏洞的相对路径。
web应用漏洞同时伴随着缺陷文件的产生，缺陷文件的路径指向了导致漏洞的代码的文件的位置，其是一个通用web应用的相对路径，通过获取所述缺陷文件的路径可以获得通用web应用的存在位置。
通过获取通用web漏洞的相对路径，可以精确地确定通用web漏洞的存在位置，同时可以将通用web漏洞与缺陷文件的相对位置关系关联起来。即通过相对路径，获取与该相对路径相关联的文件，例如，通过相对路径/data/www/phpcms/classes/api/api.php，关联文件api.php；或者，根据路径/data/www/phpcms/classes/phpsso_server/plugin.php关联文件plugin.php。
如果获取通用web漏洞所在的文件，或者通用web漏洞所在文件的的相对路径，那么就可以确定在任何主机上存在web漏洞的文件所在位置，或者存在web漏洞文件所在的路径。
在一个可选的实施例中，通过预设的通用web漏洞数据库获得通用web漏洞所在的漏洞。通用web漏洞数据库可以通过外部获得，可以是已有的专家数据库，或者专用引擎查获的通用web漏洞。
在一个可选的实施例中，通过轮询预设的通用web漏洞数据库的方式获得一条通用web漏洞所在的漏洞。
需要说明的是，物理路径获取模块和相对路径获取模块对于物理路径和通用web漏洞的相对路径的获取是可以同步或者异步的，其获取顺序并不影响本发明实施例技术方案的实施，亦不会对后续的步骤产生任何影响。
路径拼接模块,用于拼接所述通用web服务的物理路径与所述通用web漏洞的相对路径，以获得通用web漏洞的绝对路径。
将获得的通用web服务的物理路径与通用web漏洞的相对路径进行拼接。如此，可以获得对应服务器中通用web漏洞的绝对路径。
通用web服务的物理路径与所述通用web漏洞的相对路径拼接过程如下：若通用web服务的物理路径为/var/www/web，通用web漏洞的相对路径为/data/www/phpcms/classes/api/api.php，那么拼接后的通用web漏洞的绝对路径为/var/www/web/data/www/phpcms/classes/api/api.php。此时，如果在待检测主机中存在对应的通用web漏洞，那么可以通过对该绝对路径的文件实现检测。通过上述示例也可以看出，web服务的物理路径用于表示服务所在的真实物理路径，该路径通过上级目录路径的形式来表示。通用web漏洞的相对路径为则是表示可能存在漏洞的虚拟物理路径，该路径通过下级目录路径的形式来表示。
判断模块,用于判断所述通用web漏洞的绝对路径是否存在通用web应用漏洞。
在路径拼接模块通过拼接获得通用web漏洞的绝对路径之后，对该路径下是否存在漏洞进行判断。
基于上述步骤，即可以实现对于通用web漏洞的判断。
综上所述，根据本实施例提供的装置，可以在主机内有效的探测主机内部署的web服务存在的通用web漏洞，避免了传统远程poc请求探测由于网络问题的各种限制，快速有效。
在一个可能的实施例中，提供另一种通用web应用漏洞检测装置，所述装置包含如下模块：
物理路径获取模块,用于执行步骤s410,响应于漏洞检测指令，获取所述通用web服务的物理路径。
相对路径获取模块,用于执行步骤s420,获取通用web漏洞的相对路径。
拼接模块，用于执行步骤s430,拼接所述通用web服务的物理路径与所述通用web漏洞的相对路径，以获得通用web漏洞的绝对路径。
判断模块，用于执行步骤s440,判断所述通用web漏洞的绝对路径所指向的文件是否存在。当通用web漏洞的绝对路径不存在文件时，即不存在与通用web漏洞对应的文件，那么可以确定该web服务中不存在该类型通用web漏洞。
如图9所示，所述判断模块包括：
第一判断子模块，用于判断所述通用web漏洞的绝对路径所指向的文件是否存在；
特征值比较模块，用于当通用web漏洞的绝对路径存在文件时，比较所述文件与通用web漏洞文件的特征值是否相同；
第二判断子模块，用于在所述文件与通用web漏洞文件的特征值相同时，根据关键字串匹配判断是否存在通用web漏洞。
在一个可能的实施例中，如图10所示，第二判断子模块具体包括：
关键字串构件子单元，用于执行步骤s4701，构建表征漏洞的正则表达式。
关键字串匹配子单元，用于执行步骤s4702，使用所述正则表达式对文件代码进行匹配比对。
第一判定子单元，用于执行步骤s4703，当所述正则表达式与所述文件代码匹配比对相同时，判定文件中存在漏洞代码；
第二判定子单元，用于执行步骤s4704，当所述正则表达式与所述文件代码匹配比对不相同时，判定文件中不存在漏洞代码。
基于上述装置，即可以实现对于通用web漏洞的判断。
请参考图11，其示出了本发明一个实施例提供的终端的结构示意图。该终端用于实施上述实施例中提供的方法。具体来讲：
终端1000可以包括rf(radiofrequency，射频)电路110、包括有一个或一个以上计算机可读存储介质的存储器120、输入单元130、显示单元140、视频传感器150、音频电路160、wifi(wirelessfidelity，无线保真)模块170、包括有一个或者一个以上处理核心的处理器180、以及电源190等部件。本领域技术人员可以理解，图8中示出的终端结构并不构成对终端的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。其中：
rf电路110可用于收发信息或通话过程中，信号的接收和发送，特别地，将基站的下行信息接收后，交由一个或者一个以上处理器180处理；另外，将涉及上行的数据发送给基站。通常，rf电路110包括但不限于天线、至少一个放大器、调谐器、一个或多个振荡器、用户身份模块(sim)卡、收发信机、耦合器、lna(lownoiseamplifier，低噪声放大器)、双工器等。此外，rf电路110还可以通过无线通信与网络和其他设备通信。所述无线通信可以使用任一通信标准或协议，包括但不限于gsm(globalsystemofmobilecommunication，全球移动通讯系统)、gprs(generalpacketradioservice，通用分组无线服务)、cdma(codedivisionmultipleaccess，码分多址)、wcdma(widebandcodedivisionmultipleaccess,宽带码分多址)、lte(longtermevolution,长期演进)、电子邮件、sms(shortmessagingservice，短消息服务)等。
存储器120可用于存储软件程序以及模块，处理器180通过运行存储在存储器120的软件程序以及模块，从而执行各种功能应用以及数据处理。存储器120可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)等；存储数据区可存储根据终端1000的使用所创建的数据(比如视频数据、电话本等)等。此外，存储器120可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。相应地，存储器120还可以包括存储器控制器，以提供处理器180和输入单元130对存储器120的访问。
输入单元130可用于接收输入的数字或字符信息，以及产生与用户设置以及功能控制有关的键盘、鼠标、操作杆、光学或者轨迹球信号输入。具体地，输入单元130可包括图像输入设备131以及其他输入设备132。图像输入设备131可以是摄像头，也可以是光电扫描设备。除了图像输入设备131，输入单元130还可以包括其他输入设备132。具体地，其他输入设备132可以包括但不限于物理键盘、功能键(比如音量控制按键、开关按键等)、轨迹球、鼠标、操作杆等中的一种或多种。
显示单元140可用于显示由用户输入的信息或提供给用户的信息以及终端1000的各种图形用户接口，这些图形用户接口可以由图形、文本、图标、视频和其任意组合来构成。显示单元140可包括显示面板141，可选的，可以采用lcd(liquidcrystaldisplay，液晶显示器)、oled(organiclight-emittingdiode，15有机发光二极管)等形式来配置显示面板141。
终端1000可包括至少一种视频传感器150，视频传感器用于获取用户的视频信息。终端1000还可以包括其它传感器(未示出)，比如光传感器、运动传感器以及其他传感器。具体地，光传感器可包括环境光传感器及接近传感器，其中，环境光传感器可根据环境光线的明暗来调节显示面板141的亮度，接近传感器可在终端1000移动到耳边时，关闭显示面板141和/或背光。作为运动传感器的一种，重力加速度传感器可检测各个方向上(一般为三轴)加速度的大小，静止时可检测出重力的大小及方向，可用于识别手机姿态的应用(比如横竖屏切换、相关游戏、磁力计姿态校准)、振动识别相关功能(比如计步器、敲击)等；至于终端1000还可配置的陀螺仪、气压计、湿度计、温度计、红外线传感器等其他传感器，在此不再赘述。
视频电路160、扬声器161，传声器162可提供用户与终端1000之间的视频接口。音频电路160可将接收到的音频数据转换后的电信号，传输到扬声器161，由扬声器161转换为声音信号输出；另一方面，传声器162将收集的声音信号转换为电信号，由音频电路160接收后转换为音频数据，再将音频数据输出处理器180处理后，经rf电路11以发送给比如另一终端，或者将音频数据输出至存储器120以便进一步处理。音频电路160还可能包括耳塞插孔，以提供外设耳机与终端1000的通信。
wifi属于短距离无线传输技术，终端1000通过wifi模块70可以帮助用户收发电子邮件、浏览网页和访问流式媒体等，它为用户提供了无线的宽带互联网访问。虽然图9示出了wifi模块170，但是可以理解的是，其并不属于终端1000的必须构成，完全可以根据需要在不改变发明的本质的范围内而省略。
处理器180是终端1000的控制中心，利用各种接口和线路连接整个手机的各个部分，通过运行或执行存储在存储器120内的软件程序和/或模块，以及调用存储在存储器120内的数据，执行终端1000的各种功能和处理数据，从而对手机进行整体监控。可选的，处理器180可包括一个或多个处理核心；优选的，处理器180可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序等，调制解调处理器主要处理无线通信。
可以理解的是，上述调制解调处理器也可以不集成到处理器180中。
终端1000还包括给各个部件供电的电源190(比如电池)，优选的，电源可以通过电源管理系统与处理器180逻辑相连，从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。电源190还可以包括一个或一个以上的直流或交流电源、再充电系统、电源故障检测电路、电源转换器或者逆变器、电源状态指示器等任意组件。
尽管未示出，终端1000还可以包括蓝牙模块等，在此不再赘述。
具体在本实施例中，终端1000还包括有存储器，以及一个或者一个以上的程序，其中一个或者一个以上程序存储于存储器中，且经配置以由一个或者一个以上处理器执行。上述一个或者一个以上程序包含用于执行上述辅助信息展示方法的指令。所述指令用于在被处理器执行时实现如下步骤：响应于辅助信息展示请求，收集用户界面的界面信息；根据所述用户界面的界面信息，生成辅助信息请求；检索与所述辅助信息请求匹配的辅助数据；根据触发条件，在当前用户界面展示所述辅助数据。
应当理解的是，在本文中提及的“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，a和/或b，可以表示：单独存在a，同时存在a和b，单独存在b这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。
上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。
本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。
以上所述仅为本发明的较佳实施例，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。