一种SSTI漏洞的检测方法、装置及介质

技术领域

本申请涉及漏洞检测领域，特别是涉及一种SSTI漏洞的检测方法、装置及介质。

背景技术

随着互联网(Web)的不断发展，人们对于互联网的界面、数据和信息安全要求越来越高，开发人员为了提升互联网开发效率提出了一种MVC软件架构模式(Model-View-Controller)，该架构模式包括模型(Model)、视图(View)和控制器(Controller)三个基础部分，在MVC架构中，通过视图进行接收用户的输入，并传输至控制器，由控制器调用模型或者其他的控制器进行处理，最后返回给视图，由视图进行显示以便用户查看。

在此过程中，视图中大量使用了模板的技术，如今大多数网站都采用模板引擎来做数据及界面的展示，若网站对传入模板引擎参数未作过滤极易产生模板注入(SSTI)漏洞。当服务端接收了用户的恶意输入后，未经任何处理就将其作为Web应用模板内容的一部分，模板引擎在进行目标编译渲染的过程中，执行用户插入的可以破坏模板的语句，会导致敏感信息的泄露、代码执行、GetShell等问题。

目前，对于SSTI漏洞的检测和修复，需要人工手动输入各种模板引擎的SSTI漏洞检测有效负载(Payload)以检测当前网站是否存在SSTI漏洞，进而消耗大量的人力成本。此外，不同的模板引擎有不同的语法规则，依次输入不同模板的Payload进行检测会占用较多资源，且检测效率低。

由此可见，如何提升SSTI漏洞的检测效率，降低人力成本，提高网络信息安全，是本领域技术人员亟待解决的问题。

发明内容

本申请的目的是提供一种SSTI漏洞的检测方法、装置及介质，通过启动浏览器爬虫以爬取属于待检测网站的所有URL路径，并根据预先建立的检测Payload库和爬取的各URL路径编写SSTI检测脚本，然后通过启动漏洞扫描器，使用Requests对各SSTI检测脚本进行请求得到请求结果以确定所述待检测网站中是否存在SSTI漏洞，实现自动检测SSTI漏洞的目的，进而提升检测效率。

为解决上述技术问题，本申请提供一种SSTI漏洞的检测方法，包括：

获取待检测网站；

启动浏览器爬虫以爬取属于所述待检测网站的URL路径；

根据各所述URL路径和预先建立的检测Payload库编写SSTI检测脚本；

启动漏洞扫描器，以便所述漏洞扫描器使用Requests对各所述SSTI检测脚本进行请求得到请求结果以确定所述待检测网站中是否存在SSTI漏洞。

优选地，在所述启动浏览器爬虫以爬取属于所述待检测网站的URL路径之后还包括：

解析各所述URL路径以确定各所述URL路径对应的可控参数和http请求方式。

优选地，根据各所述URL路径和预先建立的检测Payload库编写SSTI检测脚本包括：

将各所述可控参数对应的参数值依次替换为所述检测Payload库中的各检测Payload；

对各所述检测Payload赋值预设表达式；

将各所述URL路径与对应的所述可控参数进行拼接得到所述SSTI检测脚本。

优选地，所述检测Payload库依据以下步骤获得，包括：

获取各类模板引擎中的Payload；

根据各所述Payload的特征对各类所述模板引擎的所述Payload进行分类以得到所述检测Payload库。

优选地，确定所述待检测网站中是否存在SSTI漏洞包括：

判断各所述URL路径对应的各所述SSTI检测脚本的请求结果是否存在所述预设表达式对应的结果；

若存在，则确定所述待检测网站中存在所述SSTI漏洞。

优选地，在所述将各所述可控参数对应的参数值依次替换为所述检测Payload库中的各检测Payload之前还包括：

判断所述http请求方式是否为GET请求方式；

若是，则根据所述GET请求方式对应的语法规则对所述检测Payload库中的各所述检测Payload进行修改。

优选地，在确定所述待检测网站中存在所述SSTI漏洞之后还包括：

发送存在所述SSTI漏洞的所述URL路径和所述可控参数至客户端以便用户查看；

从SSTI漏洞修复库中获取所述SSTI漏洞对应的修复方式以修复所述SSTI漏洞。

为了解决上述技术问题，本申请还提供了一种SSTI漏洞的检测装置，包括：

获取模块，用于获取待检测网站；

第一启动模块，用于启动浏览器爬虫以爬取属于所述待检测网站的URL路径；

编写模块，用于根据各所述URL路径和预先建立的检测Payload库编写SSTI检测脚本；

第二启动模块，用于漏洞扫描器，以便所述漏洞扫描器使用Requests对各所述SSTI检测脚本进行请求得到请求结果以确定所述待检测网站中是否存在SSTI漏洞。

为了解决上述技术问题，本申请还提供了一种SSTI漏洞的检测装置，包括存储器，用于存储计算机程序；

处理器，用于执行所述计算机程序时实现如所述的SSTI漏洞的检测方法的步骤。

为了解决上述技术问题，本申请还提供了一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如所述的SSTI漏洞的检测方法的步骤。

本发明所提供的一种SSTI漏洞的检测方法，包括：获取待检测网站，并启动浏览器爬虫以爬取属于待检测网站的所有URL路径，根据爬取的各URL路径和预先建立的检测Payload库编写SSTI检测脚本，并启动漏洞扫描器，以便漏洞扫描器使用Requests对各SSTI检测脚本进行请求得到请求结果以确定待检测网站中是否存在SSTI漏洞。由此可见，本申请所提供的技术方案，预先建立的检测Payload库避免了人工依次输入不同模板引擎的Payload以确定语法规则是否符合导致的低效率，同时，通过浏览器爬虫爬取到待检测网站的所有URL路径，并依据预先建立的检测Payload库和爬取的URL路径编写SSTI检测脚本，使用Requests对各SSTI检测脚本进行请求，并根据返回的结果确定待检测网站是否存在SSTI漏洞，实现了自动检测SSTI漏洞的目的，进而降低了人力成本，提高了网络信息安全。

此外，本申请还提供一种SSTI漏洞的检测装置及介质，与所述的SSTI漏洞的检测方法相对应，效果同上。

附图说明

为了更清楚地说明本申请实施例，下面将对实施例中所需要使用的附图做简单的介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例所提供的一种SSTI漏洞的检测方法的流程图；

图2为本申请实施例所提供的SSTI漏洞的检测装置的结构图；

图3为本发明另一实施例提供的SSTI漏洞的检测装置的结构图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下，所获得的所有其他实施例，都属于本申请保护范围。

本申请的核心是提供一种SSTI漏洞的检测方法、装置及介质，通过启动浏览器爬虫爬取待检测网站的所有URL路径，并根据爬取的URL路径和预先建立的检测Payload库编写SSTI检测脚本，然后启动漏洞扫描器使用Requests对编写的各SSTI检测脚本进行请求得到请求结果以确定待检测网站是否存在SSTI漏洞，实现自动检测SSTI漏洞，提升检测效率。

为了使本技术领域的人员更好地理解本申请方案，下面结合附图和具体实施方式对本申请作进一步的详细说明。

随着互联网(Web)的不断发展，人们对于互联网站点的界面、数据和信息安全要求越来越高，同时，随着信息时代的到来，人们对信息安全越来越重视。开发人员为了提升互联网开发效率提出了一种MVC软件架构模式，该架构模式包括模型(Model)、视图(View)和控制器(Controller)三个基础部分，在MVC架构中，通过视图进行接收用户的输入，并传输至控制器，由控制器调用模型或者其他的控制器进行处理，最后返回给视图，由视图进行显示以便用户查看。

在使用MVC软件架构的过程中，视图中大量使用了模板的技术，如今大多数网站都采用模板引擎来做数据及界面的展示，若网站对传入模板引擎参数未作过滤极易产生SSTI漏洞。当服务端接收了用户的恶意输入后，未经任何处理就将其作为Web应用模板内容的一部分，模板引擎在进行目标编译渲染的过程中，执行用户插入的可以破坏模板的语句，会导致敏感信息的泄露、代码执行、GetShell等问题。

目前，对于SSTI漏洞的检测和修复，需要人工手动输入各种模板引擎的SSTI漏洞检测Payload以检测当前网站是否存在SSTI漏洞，会消耗大量的人力成本。此外，不同的模板引擎有不同的语法规则，依次输入不同模板的Payload进行检测会占用较多资源，且检测效率低。

为了提升SSTI漏洞的检测效率，并降低人力成本，本申请提出了一种SSTI漏洞的检测方法，预先建立一个检测Payload库，启动浏览器爬虫爬取待检测网站的URL路径，并根据爬取的URL路径和检测Payload库编写SSTI检测脚本，然后启动漏洞扫描器使用Requests对编写的各SSTI检测脚本进行请求得到请求结果以确定待检测网站是否存在SSTI漏洞。

图1为本申请实施例所提供的一种SSTI漏洞的检测方法的流程图，如图1所示，该方法包括：

S10：获取待检测网站。

S11：启动浏览器爬虫以爬取属于待检测网站的URL路径。

S12：根据各URL路径和预先建立的检测Payload库编写SSTI检测脚本。

S13：启动漏洞扫描器，以便漏洞扫描器使用Requests对各SSTI检测脚本进行请求得到请求结果以确定待检测网站中是否存在SSTI漏洞。

在具体实施例中，获取到用户需要检测的网站后，启动浏览器爬虫爬取该待检测网站的所有URL路径。在步骤S12中，根据各URL路径和预先建立的检测Payload库编写SSTI检测脚本时，需要先对爬取的所有URL路径使用正则表达式查找各URL路径中的可控参数和http请求方式，将各可控参数对应的参数值依次替换为检测Payload库中的检测Payload，并对替换的检测Payload赋值预设表达式，然后按照URL路径、可控参数和http请求方式原有的对应关系进行拼接得到SSTI检测脚本。

通过步骤S12得到SSTI检测脚本后，启动漏洞扫描器使用Requests对各SSTI检测脚本进行请求，并根据返回的结果确定待检测网站是否存在SSTI漏洞。

需要说明的是，漏洞扫描器可以是Xray扫描器，也可以是其他类型的漏洞扫描器，只要能实现于浏览器爬虫联动即可，对此本申请不作限定。本申请以Xray扫描器为例进行说明，在用户需要检测某各网站是否存在SSTI漏洞时，先开启Xray扫描器的被动监听模式，并开启监听服务器端口。在获取到待检测网站后，启动浏览器爬虫爬取待检测网站的所有URL路径，且根据各URL路径和预先建立的检测Payload库编写SSTI检测脚本后，浏览器爬虫获取到监听服务器端口，将各SSTI检测脚本流量信息传输至Xray扫描器，Xray扫描器使用Requests对各SSTI检测脚本进行请求以确定待检测网站是否存在SSTI漏洞。

可以理解的是，编写的各SSTI检测脚本对应的检测Payload赋值了预设表达式，使用Requests对各SSTI检测脚本进行请求时，若各请求结果为预设表达式对应的执行结果，则确定待检测网站中存在SSTI漏洞，否则确定为存在漏洞。值得注意的是，要确定待检测网站中是否存在SSTI漏洞，需要对该网站中的所有URL路径进行检测，且每个URL路径中的可控参数对应的参数值需要依次替换为检测Payload库中的检测Payload进行检测，由此，当返回结果中存在预设表达式对应的执行结果时，可确定待检测网站中的哪个URL路径、哪个可控参数存在SSTI漏洞。

此外，需要注意的是，http请求方式主要包括POST方式和GET方式，在编写SSTI检测脚本前，先确定http请求方式是否为GET方式，若为GET方式，则根据GET请求方式对应的语法规则对检测Payload库中的各检测Payload进行修改。

本申请实施例所提供的SSTI漏洞的检测方法，包括：获取待检测网站，并启动浏览器爬虫以爬取属于待检测网站的所有URL路径，根据爬取的各URL路径和预先建立的检测Payload库编写SSTI检测脚本，并启动漏洞扫描器，以便漏洞扫描器使用Requests对各SSTI检测脚本进行请求得到请求结果以确定待检测网站中是否存在SSTI漏洞。由此可见，本申请所提供的技术方案，预先建立的检测Payload库避免了人工依次输入不同模板引擎的Payload以确定语法规则是否符合导致的低效率，同时，通过浏览器爬虫爬取到待检测网站的所有URL路径，并依据预先建立的检测Payload库和爬取的URL路径编写SSTI检测脚本，使用Requests对各SSTI检测脚本进行请求，并根据返回的结果确定待检测网站是否存在SSTI漏洞，实现了自动检测SSTI漏洞的目的，进而降低了人力成本，提高了网络信息安全。

在具体实施例中，在启动浏览器爬虫爬取到属于待检测网站的URL路径之后，使用正则表达式解析查找各URL路径的可控参数和http请求方式。需要说明的是，本申请对各URL路径的解析方式不作限定。可控参数为追加到URL路径上的一个值对，可控参数以问号开始并采用name＝value的格式出现，若一个URL路径存在多个可控参数，则各可控参数间使用分隔符(&)隔开，为了便于理解，下面将举例说明。例如，URL路径为：http://server/path/document？name1＝value1&name2＝value2，该URL包含两个值对，即包含两个可控参数name1＝value1和name2＝value2，其中，value1和value2为该URL路径对应的参数值。URL路径的可控参数可以将浏览器端的请求信息传输到服务器，当服务器接收到请求后，将对应的请求页面提供给浏览器以便用户查看。

http请求方式主要包括POST方式和GET方式两种方式，可以理解的是，不同的http请求方式对应的语法规则不同，则对应的检测Payload库也不同，因此，在根据爬取的URL路径和预先建立的检测Payload库编写SSTI检测脚本时，需要依据http请求方式对应的语法规则对检测Payload进行调整。

本申请实施例所提供的SSTI漏洞的检测方法，在爬取到属于待检测网站的所有URL路径后，对各URL路径进行解析得到对应的可控参数和http请求方式，以便结合检测Payload库进行SSTI检测脚本的编写，进而使用Requests对各SSTI检测脚本进行请求以确定待检测网站中是否存在SSTI漏洞，由此，实现自动检测SSTI漏洞的目的，提升检测SSTI漏洞的检测效率，进而提升网络信息安全。

在具体实施中，根据各URL路径和预先建立的检测Payload库编写SSTI检测脚本包括：将各可控参数对应的参数值依次替换为检测Payload库中的各检测Payload，并对各检测Payload赋值预设表达式，最后将各URL路径与对应的可控参数进行拼接得到SSTI检测脚本。

可以理解的是，确定一个URL路径是否存在SSTI漏洞，需要输入各种模板引擎的Payload进行检测，然而人工依次输入各Payload进行检测将会耗费巨大的人力成本，因此本申请在编写SSTI检测脚本时，依次将各URL路径可控参数对应的参数值替换为检测Payload库中的各检测Payload，并对各检测Payload赋值预设表达式，由此得到多个SSTI检测脚本。

需要说明的是，预设表达式可以是一个数学计算表达式，也可以是一句疑问句，只要对预设表达式进行请求时能得到对应的结果即可，也就是说，该预设表达式必须包含对应的请求结果，因此，本申请对赋值的预设表达式不作限定。为了便于理解，下面将举例说明，例如，预设表达式为“1+1”，则对该预设表达式进行请求时得到的结果为2，预设表达式还可以时“世界上最高的山峰”，则对该预设表达式进行请求得到的结果为珠穆朗玛峰。当然，对各检测Payload赋值预设表达式时，可以赋值相同的表达式，也可以赋值不同的表达式，对此本申请不作限定。

在实施中，爬取到的各URL路径和可控参数以及http请求方式之间存在相对应的关系，因此在将各可控参数对应的参数值替换为检测Payload后，并对检测Payload赋值预设表达式后，按照原有的对应关系进行拼接的得到SSTI检测脚本。值得注意的是，为了准确确定每个URL路径是否存在SSTI漏洞，则需要依次将各URL路径中的参数值替换为检测Payload，而每替换一个检测Payload拼接得到一个SSTI检测脚本，最后对各SSTI检测脚本进去请求以确定是否存在SSTI漏洞。

本申请实施例所提供的SSTI漏洞的检测方法，通过浏览器爬虫爬取到属于待检测网站的所有URL路径，并解析得到各URL路径对应的可控参数和http请求方式后，将各可控参数对应的参数值依次替换为检测Payload库中的各检测Payload，并对各检测Payload赋值预设表达式，最后将各URL路径与对应的可控参数进行拼接得到SSTI检测脚本，自动检测SSTI漏洞的目的，进而提升SSTI漏洞的检测效率。

目前，检测各网站中是否存在SSTI漏洞，需要人工依次输入各模板引擎的Payload进行检测，采用这样的方式进行检测效率低，且耗费的成本高。因此，本申请预先建立一个检测Payload库，在建立检测Payload库时，先获取各类模板引擎中的Payload，并根据各Payload的特征对各类模板引擎的Payload进行分类以得到检测Payload库。

表1为本申请实施例所提供的检测Payload库的示意图。如表1所示，模板引擎Tornado和模板引擎Jinja2使用的语言相同，且根据检测Payload特征可归类至检测Payload为“{{*}}”的一类。需要说明的是，本申请对于检测Payload库的存储方式不作限定。此外，还需要说明的是，目前根据各类模板引擎的特征将检测Payload分为“${*}”、“{{*}}”、“#{*}”、“{{＝*}}”和“\n＝*\n”五类，其中，将可控参数替换为检测Payload后，需要对各检测Payload中的“*”进行赋值预设表达式，即将“*”替换为预设表达式。当出现新的模板引擎和新的检测Payload时，可对检测Payload库进行更新。

表1检测Payload库

在编写SSTI检测脚本时，将爬取的各URL路径可控参数对应的参数值依次替换为检测Payload，并对各检测Payload赋值预设表达式，为了便于理解，下面将举例说明。例如，预设表达式为“1+1”，且URL路径为：http://server/path/document？name1＝value1，可控参数为name1＝value1，其中，value1为该URL路径对应的参数值。在编写SSTI检测脚本时，将参数值value1替换为检测Payload，并将检测Payload中的“*”替换为“1+1”，然后按照URL路径、可控参数和http原有的对应关系进行拼接得到SSTI检测脚本，并对SSTI检测脚本进行请求以确定待检测网站是否存在SSTI漏洞。

本申请实施例所提供的SSTI漏洞的检测方法，获取各类模板引擎中的Payload，并根据各Payload的特征对各类模板引擎的Payload进行分类以得到检测Payload库，由此，本申请提供的技术方案可依据预先建立的检测Payload库对待检测网站的SSTI漏洞进行检测，避免了人工输入各模板引擎的Payload进行SSTI漏洞检测消耗的巨大人力成本，同时，提升了SSTI漏洞的检测效率。

在上述实施例的基础上，根据各URL路径和检测Payload库编写得到SSTI检测脚本后，启动漏洞扫描器，使用Requests对各SSTI检测脚本进行请求得到请求结果，判断各请求结果种是否预设表达式对应的结果，若存在，则确定确定待检测网站中存在SSTI漏洞。例如，预设表达式为“1+1”，对各SSTI检测脚本进行请求后，若请求结果中存在“2”这个结果，即可确定待检测网站中存在SSTI漏洞。

值得注意的是，确定一个URL路径是否存在SSTI漏洞时，需要获取该URL路径可控参数对应的参数值替换为检测Payload库中的各Payload对应的SSTI检测脚本，并对各SSTI检测脚本进行请求，返回结果中一旦存在“2”，即可确定该URL路径存在SSTI漏洞。同样的，待检测网站对应的任意一个URL路径存在SSTI漏洞即可确定该待检测网站存在SSTI漏洞。

本申请实施例所提供的SSTI漏洞的检测方法，通过各SSTI检测脚本的请求结果以确定待检测网站是否存在SSTI漏洞，实现了自动检测SSTI漏洞的目的，进而降低了人力成本，提高了网络信息安全。

在具体实施例中，将各可控参数对应的参数值依次替换为检测Payload库中的各检测Payload前，先判断http请求方式是否为GET请求方式，若是，则根据GET请求方式对应的语法规则对检测Payload库中的各检测Payload进行修改。值得注意的是，当爬虫爬取到待检测网站的所有URL路径后，对各URL路径的html源码进行解析即可确定http请求方式。

GET请求方法中使用“#”作为截断符，向服务端进行请求时会将“#”前面的字符URL路径信息传送至服务端进行请求，而“#”后的字符不进行发送请求。因此，为了将编写的SSTI检测脚本完成传入服务器端进行请求，则需要根据GET请求方式对应的语法规则对检测Payload库中的各检测Payload进行修改，而URL编码语句ascii表中“#”对应的为“％23”，因此需要将上述实施例检测Payload库中的“#”替换为“％23”

本申请实施例所提供的SSTI漏洞的检测方法，将各可控参数对应的参数值依次替换为检测Payload库中的各检测Payload前，先判断http请求方式是否为GET请求方式，若是，则根据GET请求方式对应的语法规则对检测Payload库中的各检测Payload进行修改，由此，不同http请求方式均可实现SSTI漏洞的检测，进一步节约成本，提高检测效率。

在实施中，当确定待检测网站存在SSTI漏洞后，将存在SSTI漏洞的URL路径和可控参数至客户端发送至客户端，以便客户端查看，同时从SSTI漏洞修复库中获取SSTI漏洞对应的修复方式以修复SSTI漏洞。

需要说明的是，从SSTI漏洞修复库为已公开的SSTI漏洞修复方式，确定待检测网站存在SSTI漏洞时，只需从该SSTI漏洞修复库中调取相应的修复方式供用户选择即可。

本申请实施例所提供的SSTI漏洞的检测方法，在确定待检测网站中存在SSTI漏洞后，发送存在SSTI漏洞的URL路径和可控参数至客户端以便用户查看，并从SSTI漏洞修复库中获取SSTI漏洞对应的修复方式以修复SSTI漏洞，由此，实现SSTI漏洞的自动检测和修复，提升检测效率，进而提升网络信息安全。

在上述实施例中，对于SSTI漏洞的检测方法进行了详细描述，本申请还提供SSTI漏洞的检测装置对应的实施例。需要说明的是，本申请从两个角度对装置部分的实施例进行描述，一种是基于功能模块的角度，另一种是基于硬件结构的角度。

图2为本申请实施例所提供的SSTI漏洞的检测装置的结构图，如图2所示，该装置包括：

获取模块10，用于获取待检测网站。

第一启动模块11，用于启动浏览器爬虫以爬取属于待检测网站的URL路径。

编写模块12，用于根据各URL路径和预先建立的检测Payload库编写SSTI检测脚本。

第二启动模块13，用于漏洞扫描器，以便漏洞扫描器使用Requests对各SSTI检测脚本进行请求得到请求结果以确定待检测网站中是否存在SSTI漏洞。

由于装置部分的实施例与方法部分的实施例相互对应，因此装置部分的实施例请参见方法部分的实施例的描述，这里暂不赘述。

本申请实施例所提供的SSTI漏洞的检测装置，包括：获取待检测网站，并启动浏览器爬虫以爬取属于待检测网站的所有URL路径，根据爬取的各URL路径和预先建立的检测Payload库编写SSTI检测脚本，并启动漏洞扫描器，以便漏洞扫描器使用Requests对各SSTI检测脚本进行请求得到请求结果以确定待检测网站中是否存在SSTI漏洞。由此可见，本申请所提供的技术方案，预先建立的检测Payload库避免了人工依次输入不同模板引擎的Payload以确定语法规则是否符合导致的低效率，同时，通过浏览器爬虫爬取到待检测网站的所有URL路径，并依据预先建立的检测Payload库和爬取的URL路径编写SSTI检测脚本，使用Requests对各SSTI检测脚本进行请求，并根据返回的结果确定待检测网站是否存在SSTI漏洞，实现了自动检测SSTI漏洞的目的，进而降低了人力成本，提高了网络信息安全。

图3为本发明另一实施例提供的SSTI漏洞的检测装置的结构图，如图3所示，SSTI漏洞的检测装置包括：存储器20，用于存储计算机程序；

处理器21，用于执行计算机程序时实现如上述实施例所提到的SSTI漏洞的检测方法的步骤。

本实施例提供的SSTI漏洞的检测装置可以包括但不限于智能手机、平板电脑、笔记本电脑或台式电脑等。

其中，处理器21可以包括一个或多个处理核心，比如4核心处理器、8核心处理器等。处理器21可以采用数字信号处理器(Digital Signal Processor，简称DSP)、现场可编程门阵列(Field－Programmable Gate Array，简称FPGA)、可编程逻辑阵列(ProgrammableLogic Array，简称PLA)中的至少一种硬件形式来实现。处理器21也可以包括主处理器和协处理器，主处理器是用于对在唤醒状态下的数据进行处理的处理器，也称中央处理器(Central Processing Unit，简称CPU)；协处理器是用于对在待机状态下的数据进行处理的低功耗处理器。在一些实施例中，处理器21可以集成有图像处理器(GraphicsProcessing Unit，简称GPU)，GPU用于负责显示屏所需要显示的内容的渲染和绘制。一些实施例中，处理器21还可以包括人工智能(Artificial Intelligence，简称AI)处理器，该AI处理器用于处理有关机器学习的计算操作。

存储器20可以包括一个或多个计算机可读存储介质，该计算机可读存储介质可以是非暂态的。存储器20还可包括高速随机存取存储器，以及非易失性存储器，比如一个或多个磁盘存储设备、闪存存储设备。本实施例中，存储器20至少用于存储以下计算机程序201，其中，该计算机程序被处理器21加载并执行之后，能够实现前述任一实施例公开的SSTI漏洞的检测方法的相关步骤。另外，存储器20所存储的资源还可以包括操作系统202和数据203等，存储方式可以是短暂存储或者永久存储。其中，操作系统202可以包括Windows、Unix、Linux等。数据203可以包括但不限于SSTI漏洞的检测方法中涉及的相关数据等。

在一些实施例中，SSTI漏洞的检测装置还可包括有显示屏22、输入输出接口23、通信接口24、电源25以及通信总线26。

本领域技术人员可以理解，图3中示出的结构并不构成对SSTI漏洞的检测装置的限定，可以包括比图示更多或更少的组件。

本申请实施例提供的SSTI漏洞的检测装置，包括存储器和处理器，处理器在执行存储器存储的程序时，能够实现如下方法：SSTI漏洞的检测方法。

本申请实施例所提供的SSTI漏洞的检测装置，通过预先建立的检测Payload库避免了人工依次输入不同模板引擎的Payload以确定语法规则是否符合导致的低效率，同时，通过浏览器爬虫爬取到待检测网站的所有URL路径，并依据预先建立的检测Payload库和爬取的URL路径编写SSTI检测脚本，使用Requests对各SSTI检测脚本进行请求，并根据返回的结果确定待检测网站是否存在SSTI漏洞，实现了自动检测SSTI漏洞的目的，进而降低了人力成本，提高了网络信息安全。

最后，本申请还提供一种计算机可读存储介质对应的实施例。计算机可读存储介质上存储有计算机程序，计算机程序被处理器执行时实现如上述方法实施例中记载的步骤。

可以理解的是，如果上述实施例中的方法以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-Only Memory，简称ROM)、随机存取存储器(Random Access Memory，简称RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

以上对本申请所提供的一种SSTI漏洞的检测方法、装置及介质进行了详细介绍。说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以对本申请进行若干改进和修饰，这些改进和修饰也落入本申请权利要求的保护范围内。

还需要说明的是，在本说明书中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。