WEB中间件漏洞
写在前面
下午的一个电话面试让我措手不及，压根就没准备。不过面试官很好，引导我回答问题，也了解很多了知识，但自己不争气，给了他一种似懂非懂的感觉，估计是凉了。。。
WEB常见中间件
一开始我听到这个我人傻掉，啥是中间件，经过面试官引导才知道就是Tomcat、Weblogic、Jboss这些东西，我们经常管web中间件叫做web服务器或者web容器
中间件是提供系统软件和应用软件之间连接的软件，以便于软件各部件之间的沟通。中间件处在操作系统和更高一级应用程序之间。他充当的功能是：将应用程序运行环境与操作系统隔离，从而实现应用程序开发者不必为更多系统问题忧虑，而直接关注该应用程序在解决问题上的能力 。容器就是中间件的一种。
也就是说，关于中间件，我们可以理解为：是一类能够为一种或多种应用程序合作互通、资源共享，同时还能够为该应用程序提供相关的服务的软件。（注意：中间件是一类软件的总称，不是单独的一个软件）
web服务器：IIS、Apache、Nginx、Tomcat、Jboss、Jetty、Weblogic、Webshere、Glasshfish、Lighttpd等
web中间件：Tomcat、Jboss、Jetty、Weblogic、Webshere、Glasshfish等
web容器：IIS(asp容器)、Tomcat(servlet容器)、Jboss(EJB容器)
所以应该是 web服务器>web中间件>web容器
WEB常见中间件漏洞
一、IIS中间组件:
1、PUT漏洞
IIS Server 在 Web 服务扩展中开启了 WebDAV ，配置了可以写入的权限，造成任意文件上传。版本： IIS6.0
1）关闭WebDAV 和写权限
2、短文件名猜解
IIS的短文件名机制，可以暴力猜解短文件名，访问构造的某个存在的短文件名，会返回404，访问构造的某个不存在的短文件名，返回400。
1）升级.net framework
2）修改注册表禁用短文件名功能
3、远程代码执行
在IIS6.0处理PROPFIND指令的时候，由于对url的长度没有进行有效的长度控制和检查，导致执行memcpy对虚拟路径进行构造的时候，引发栈溢出，从而导致远程代码执行。
1）关闭 WebDAV 服务
2） 使用相关防护设备
4、解析漏洞
IIS 6.0 在处理含有特殊符号的文件路径时会出现逻辑错误，从而造成文件解析漏洞。
第一种是新建一个名为 “test.asp” 的目录，该目录中的任何文件都被 IIS 当作 asp 程序执行（特殊符号是 “/” ）
第二种是上传名为 “test.asp;.jpg” 的文件，虽然该文件真正的后缀名是 “.jpg”, 但由于含有特殊符号 “;” ，仍会被 IIS 当做 asp 程序执行
IIS7.5 文件解析漏洞
若有文件 test.jpg ，访问时在其后加 /.php ，便可以把 “test.jpg/.php” 交给 php ， php 修理文件路径 “test.jpg/.php” 得到 ”test.jpg” ，该文件存在，便把该文件作为 php 程序执行了
1）对新建目录文件名进行过滤，不允许新建包含‘.’的文件
2）曲线网站后台新建目录的功能，不允许新建目录
3）限制上传的脚本执行权限，不允许执行脚本
二、Apache中间组件:
1、解析漏洞
Apache默认一个文件可以有多个以点分隔的后缀，当右边的后缀无法识别（不在mime.tyoes内），则继续向左识别
1）将AddHandler application/x-httpd-php .php的配置文件删除。
2、目录遍历
由于配置错误导致的目录遍历
1）修改apache配置文件httpd.conf，找到Options+Indexes+FollowSymLinks +ExecCGI并修改成 Options-Indexes+FollowSymLinks +ExecCGI 并保存；
三、Nginx中间组件:
1、文件解析
对任意文件名，在后面添加/任意文件名.php的解析漏洞，比如原本文件名是test.jpg，可以添加test.jpg/x.php进行解析攻击。
2、目录遍历
Nginx的目录遍历与Apache一样，属于配置方面的问题，错误的配置可到导致目录遍历与源码泄露
1）将/etc/nginx/sites-avaliable/default里的autoindex on改为autoindex off
3、CRLF注入
4、目录穿越
Nginx反向代理，静态文件存储在/home/下，而访问时需要在url中输入files，配置文件中/files没有用/闭合，导致可以穿越至上层目录。
1）Nginx的配置文件/etc/nginx/conf.d/error2.conf的/files使用/闭合。
四、Tomcat中间组件:
1、远程代码执行
Tomcat 运行在Windows 主机上，且启用了 HTTP PUT 请求方法，可通过构造的攻击请求向服务器上传包含任意代码的 JSP 文件，造成任意代码执行。影响版本： Apache Tomcat 7.0.0 – 7.0.81
1）检测当前版本是否在影响范围内，并禁用PUT方法。
2）更新并升级至最新版。
2、war后门文件部署
Tomcat 支持在后台部署war文件，可以直接将webshell部署到web目录下。
若后台管理页面存在弱口令，则可以通过爆破获取密码。
1）在系统上以低权限运行Tomcat应用程序
五、jBoss中间组件:
1、反序列化漏洞
Java序列化，简而言之就是把java对象转化为字节序列的过程。而反序列话则是再把字节序列恢复为java对象的过程，然而就在这一转一变得过程中，程序员的过滤不严格，就可以导致恶意构造的代码的实现。
1）不需要http-invoker.sar 组件的用户可直接删除此组件；
2）用于对 httpinvoker 组件进行访问控制。
2、war后门文件部署
jBoss后台管理页面存在弱口令，通过爆破获得账号密码。登陆后台上传包含后门的war包。
六、WebLogic中间组件:
1、反序列化漏洞
Java序列化，简而言之就是把java对象转化为字节序列的过程。而反序列话则是再把字节序列恢复为java对象的过程，然而就在这一转一变得过程中，程序员的过滤不严格，就可以导致恶意构造的代码的实现。
2、SSRF
Weblogic 中存在一个SSRF漏洞，利用该漏洞可以发送任意HTTP请求，进而攻击内网中redis、fastcgi等脆弱组件。
方法一：以修复的直接方法是将SearchPublicRegistries.jsp直接删除就好了；
方法二：1）删除uddiexplorer文件夹 2）限制uddiexplorer应用只能内网访问
方法三：（常用）
Weblogic服务端请求伪造漏洞出现在uddi组件（所以安装Weblogic时如果没有选择uddi组件那么就不会有该漏洞），更准确地说是uudi包实现包uddiexplorer.war下的SearchPublicRegistries.jsp。方法二采用的是改后辍的方式，修复步骤如下：
1）将weblogic安装目录下的wlserver_10.3/server/lib/uddiexplorer.war做好备份
2）将weblogic安装目录下的server/lib/uddiexplorer.war下载
3）用winrar等工具打开uddiexplorer.war
4)将其下的SearchPublicRegistries.jsp重命名为SearchPublicRegistries.jspx
5）保存后上传回服务端替换原先的uddiexplorer.war
6）对于多台主机组成的集群，针对每台主机都要做这样的操作
7）由于每个server的tmp目录下都有缓存所以修改后要彻底重启weblogic（即停应用–停server–停控制台–启控制台–启server–启应用）
3、任意文件上传
通过访问config.do配置页面，先更改Work Home工作目录，用有效的已部署的Web应用目录替换默认的存储JKS Keystores文件的目录，之后使用”添加Keystore设置”的功能，可上传恶意的JSP脚本文件。
方案1：使用Oracle官方通告中的补丁链接：http://www.oracle.com/technetwork/security-advisory/cpujul2018-4258247.html；https://support.oracle.com/rs?type=doc&id=2394520.1
方案2:
1）进入Weblogic Server管理控制台；
2）domain设置中，启用”生产模式”。
4、war后门文件部署
由于WebLogic后台存在弱口令，可直接登陆后台上传包含后门的war包。
1）防火墙设置端口过滤，也可以设置只允许访问后台的IP列表，避免后台弱口令。
七、其它中间件相关漏洞
1、FastCGI未授权访问、任意命令执行
服务端使用fastcgi协议并对外网开放9000端口，可以构造fastcgi协议包内容，实现未授权访问服务端.php文件以及执行任意命令。
1）更改默认端口
2、PHP CGI远程代码执行
在apache调用php解释器解释.php文件时，会将url参数传我给php解释器，如果在url后加传命令行开关（例如-s、-d 、-c或-dauto_prepend_file%3d/etc/passwd+-n）等参数时，会导致源代码泄露和任意代码执行。此漏洞影响php-5.3.12以前的版本，mod方式、fpm方式不受影响。
1）升级php版本；（php-5.3.12以上版本）;
2）在apache上做文章，开启url过滤，把危险的命令行参数给过滤掉，由于这种方法修补比较简单，采用比较多吧。
具体做法：
修改http.conf文件，找到<Directory/>增加以下三行
RewriteEngine on
RewriteCond %{QUERY_STRING} ^(%2d|-)[^=]+$ [NC]
RewriteRule ^(.*) $1? [L]
重启一下apache即可，但是要考虑到，相当于每次request就要进行一次url过滤，如果访问量大的话，可能会增加apache的负担。
3）打上php补丁。补丁下载地址:https://eindbazen.net/2012/05/php-cgi-advisory-cve-2012-1823/
参考链接
https://www.jianshu.com/p/1e82b7a18866
https://www.jianshu.com/p/b8d95de87344
