web安全/渗透测试--25--服务器端包含注入(SSI注入)

版权声明:本文为博主原创文章,遵循 CC 4.0 by-sa 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/wutianxu123/article/details/82724637

1、漏洞描述:

SSI是英文Server Side Includes的缩写,翻译成中文就是服务器端包含的意思。从技术角度上说,SSI就是在HTML文件中,可以通过注释行调用的命令或指针。SSI具有强大的功能,只要使用一条简单的SSI命令就可以实现整个网站的内容更新,时间和日期的动态显示,以及执行shell和CGI脚本程序等复杂的功能。SSI可以称得上是那些资金短缺、时间紧张、工作量大的网站开发人员的最佳帮手。

(Server-side Includes)服务器端包含提供了一种对现有HTML文档增加动态内容的方法。apache和iis都可以通过配置支持SSI,在网页内容被返回给用户之前,服务器会执行网页内容中的SSI标签。在很多场景中,用户输入的内容可以显示在页面中,比如一个存在反射XSS漏洞的页面,如果输入的payload不是xss代码而是ssi的标签,服务器又开启了ssi支持的话就会存在SSI漏洞。

2、检测条件

1、Web服务器已支持SSI(服务器端包含)。

2、Web应用程序在返回HTML页面时,嵌入用户输入。

3、参数值未进行输入清理。

3、检测方法

1、黑盒检测

首先寻找Web服务器事实上是否支持SSI指令。由于SSI支持很常见,答案几乎是肯定的。然后只需要通过传统信息收集技术,了解我们的检测目标运行哪些类型的Web服务器即可。无论能否成功发现这一信息,我们都可以通过查看检测网站的内容来猜测其是否支持SSL:由于.shtml文件后缀名是用来表明网页文件是否包含SSI指令的,因此如果该网站使用了.shtml文件,那说明该网站支持SSI指令。然而.shtml后缀名并非是强制规定的,因此如果没有发现任何.shtml文件,并不意味着目标网站没有受到SSI注入攻击的可能。

下一个步骤。这不仅需要确认是否可以进行SSI注入攻击,还需要确认我们用来注入恶意代码的输入点。这一步的测试跟测试其它代码注入漏洞一样。我们需要找到运行用户提交输入的每一个网页,并确认应用程序是否正确验证了所提交的输入,反之则确认是否存在按输入原样显示的数据(如错误信息、论坛发帖等)。除了常见的用户提供的数据外,常考虑的输入变量就是容易伪造的HTTP请求头和Cookie内容。

一旦我们有了潜在注入点的清单,可以检查输入是否得到正确验证,并找出所提供的数据将在网站按原样显示的地方。必须确保我们能够使用SSI指令中使用的字符:

<!#=/."->and[a-zA-Z0-9]             //能在同一个地方通过服务器并被解析。

利用验证的缺乏就像使用如下所示的字符串进行表单提交那样容易:

<!--#includevirtual="/etc/passwd" -->

不要用传统的字符串:

<script>alert("XSS")</script>

当下次服务器需要提供指定的页面时,就会解析该指令,这样页面就包含了Unix标准密码文件内容。

如果Web应用程序将使用这些数据建立一个动态产生的页面,在HTTP头信息中也可以执行该注入:

GET/HTTP/1.0
Referer:<!--#exec cmd="/bin/psax"-->
User-Agent: <!--#virtualinclude="/proc/version"-->

2、灰盒检测实例

如果能查看应用程序的源代码,我们可以轻松找出:

A、是否使用SSI指令;如果使用,web服务器就启动了SSI支持。这就导致SSI注入至少成为需要调查的潜在问题;

B、用户输入、cookie内容和HTTP标题头在哪里处理;很快就能生成一张完整的输入变量清单;

C、如何处理输入、使用什么样的过滤方式、应用程序不允许什么样的字符通过、考虑了多少种编码方式。使用grep执行这些步骤,找到源代码中的正确关键词(SSI指令、CGI环境变量、涉及用户输入的变量任务、过滤函数等等)。

4、修复方案

由于未对用户输入正确执行危险字符清理,可能会在Web服务器上运行远程命令。这通常意味着完全破坏服务器及其内容。

1、清理用户输入。禁止可能支持SSI的模式/字符。

2、由于SSI会带来许多安全风险,建议您不在Web站点中使用SSI,即关闭服务器对ssi的支持即可。

展开阅读全文

没有更多推荐了,返回首页