web安全实践（3）再谈基于http的服务器架构剖析
作者：玄魂
前置知识：http协议，代理服务器，web防火墙
本系列导航http://www.cnblogs.com/xuanhun/archive/2008/10/25/1319523.html
安全技术区http://space.cnblogs.com/group/group_detail.aspx?gid=100566
前言
web安全实践系列主要是对《黑客大曝光——web应用安全机密与解决方案（第二版）》的内容做的实践研究和部分编程实现。所以如果您能完全理解那本书可以跳过本文章。
另外我需要更多的像我一样的人来参与这项工作。
废话还是少说的好，我们进入今天的正题。
正文
昨天由于太累了，没把剩下的内容写完，今天继续。主要内容是代理和防火墙的探测。
3.1检测代理
如果代理服务器对外就表现为一个Web服务器，外部网络就可以简单把它当作一个标准的Web服务器而不需要特定的配置。不同之处在于，这个服务器没有保存任何网页的真实数据，所有的静态网页或者CGI程序，都保存在内部的Web服务器上。因此对反向代理服务器的攻击并不会使得网页信息遭到破坏，这样就增强了Web服务器的安全性。我们的主要目的是检测目标服务器是否通过代理服务器来响应请求，以免我们丢失目标。
（1）Trace请求。当我们像web服务器发送一个Trace请求之后，服务器会回显接收到的请求。如果正常情况下，返回的请求应该就是我们发送的请求。但是如果我们的请求是先到达一个代理服务器然后真正的web服务器接收到的就应该是代理服务器的请求，也是就是返回的信息也应该是代理服务器的请求信息而不是我们最初发送的请求。说着有点迷糊，下面看一个实际的例子。不过由于一些服务器在处理trace请求存在跨站漏洞，很多网站是不支持trace请求的。
HTTP/1.1 405 Method Not Allowed
Date: Sun, 26 Oct 2008 09:03:50 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
X-AspNet-Version: 2.0.50727
Cache-Control: private
Content-Type: text/html; charset=utf-8
Content-Length: 3432
.....
<title>Path 'trace' is forbidden.</title>
而我在测试过程中也发现有的网站虽然支持Trace请求但没返回请求信息，可能是忽略或容错的设置。
下面我们看到的是一个正常的响应。
TRACE / HTTP/1.0
Host:www.xuanhun.com
HTTP/1.1 200 OK
Date: Sat, 20 Oct 2007 20:39:36 GMT
Server:Apache/2.2.6(Debian)
PHP/4.4.4-9 mod_ruby/1.2.6 Ruby/1.8.6(2007-06-07)
Connection: close
Content-Type: message/http
TRACE / HTTP/1.0
Host: www.xuanhun.com
如果我们访问的是代理的话，一般会出现以下两种情况：
代理服务器添加了固定的头
如"via:"X-Forwarded-For:","proxy-Connection:"
或者改变host头
TRACE / HTTP/1.0
Host:www.xuanhun.com
HTTP/1.1 200 OK
Date: Sat, 20 Oct 2007 20:39:36 GMT
Server:Apache/2.2.6(Debian)
PHP/4.4.4-9 mod_ruby/1.2.6 Ruby/1.8.6(2007-06-07)
Connection: close
Content-Type: message/http
TRACE / HTTP/1.0
Host: www.xuanhun1.com
（2）Connect标准测试.
一般情况下HTTP代理服务都会支持HTTP CONNECT的方法，利用他能建立一个TCP连接来绕过一般的应用层功能。一般，HTTP CONNECT方法都用来通过HTTP代理来建立HTTPS连接。
利用Connect测试的方法就是向一个已知站点发送Connect，观察响应信息来确定是否来自代理。
3.2检测防火墙
（1）连续的具有入侵特征的连接。
如果有防火墙它会拒绝你的连接。对于服务器的入侵扫描一般都会遭到防火墙的拒绝。其实我们现在可以肯定的是几乎所有的正规网站都会有防火墙的。我们面临的难题应该是对方使用的是什么类型的防火墙而不是用没用防火墙的问题。
（2）防火墙类型的诊断。
其实这和http指纹研究一样也应该是个统计学的问题。判断的思想应该是向服务器发送各种类型的非法请求，并判断出是否是防火墙作出的回应，回应的特征是什么。总结过程该是各个有机会接触防火墙配置的人。这项工作的研究目前还不是十分完善。我的条件也不允许我做这这个实验，我还是希望得到更多的人关于这方面的反馈。
观察的方面：
响应信息
Teros Web 应用防火墙技术会对trace请求作出500响应，提示：Invalid method code。F5TrafficShield 会返回400错误，并提示：The Server could not anderstand your request。Your error ID is：
Netcontinuum对任何非法请求都返回404错误。
SecureIIs会返回406错误。
特殊的cookie
Teros 对每次响应都要使用同一个名——st8id。
TrafficShield 会使用cookie名为ASINFO。
特殊的错误情况
URLScan 如果接收一个Path长度大于260个字符的请求，就返回404错误，而且如果在请求中添加如ranslate，if，Lock-Token,Transfer-Encoding等头部，就会拒绝请求。
SecureIIs 默认头部最大长度为1024个字符。
3.3web服务器写权限刺探
试一个目录对于web用户是否具有写权限，采用如下方法：telnet到服务器的web端口(80)并发送一个如下请求：
PUT /dir/1.txt HTTP/1.1
Host:
Content-Length: 10
这时服务器会返回一个100( 继续)的信息：
HTTP/1.1 100 Continue
Server: Microsoft-IIS/5.0
Date: Thu, 28 Feb 2002 15:56:00 GMT
接着，我们输入10个字母：
AAAAAAAAAA
送出这个请求后，看服务器的返回信息，如果是一个 201 Created响应：
HTTP/1.1 201 Created
Server: Microsoft-IIS/5.0
Date: Thu, 28 Feb 2002 15:56:08 GMT
Location:http://iis-server/dir/my_file.txt
Content-Length: 0
Allow: OPTIONS, TRACE, GET, HEAD, DELETE, PUT, COPY, MOVE, PROPFIND,
PROPPATCH, SEARCH, LOCK, UNLOCK
那么就说明这个目录的写权限是开着的，反之，如果返回的是一个403错误，那么写权限就是没有开起来，如果需要你认证，并且返回一个 401(权限禁止) 的响应的话，说明是开了写权限，但是匿名用户不允许。如果一个目录同时开了"写"和"脚本和可执行程序"的话，那么web用户就可以上传一个程序并且执行它。
今天做了一天的实验，发现这部分知识总体上技术都不成熟，有待发展。其实这是矛盾的，技术成熟了对现有网站的威胁也就大了。但从技术的角度讲我希望得到相关专家的帮助。
明天的内容按计划应该是简单的http编程实践。
