WEB渗透 --- 常见问题总结

1. 不安全的HTTP方法 ：

1）描述：

不安全的HTTP方法一般包括： TRACE、 PUT、 DELETE、 COPY等。 其中最常见的为TRACE方法可以回显服务器收到的请求， 主要用于测试或诊断， 恶意攻击者可以利用该方法进行跨站跟踪攻击(即XST攻击)， 从而进行网站钓鱼、 盗取管理员cookie等。 其他说明方式如下所示：

常用方法：

方法	解释
PUT	向指定的目录上传文件
DELETE	删除指定的资源
COPY	将指定的资源复制到Destination消息头 指定的位置
MOVE	将指定的资源移动到Destination消息头 指定的位置

 

CONNECT	客户端使用Web服务器作为代理
PROPFIND	获取与指定资源有关的信息， 如作者、 大 小与内容类别
TRACE	在响应中返回服务器收到的原始请求
DEAD	返回报文的头部
OPTIONS	客户端询问服务器可以提交哪些请求方法
GET	获取服务器资源
POST	传输实体文本

 

 

2） 检测方法

1、 使用抓包软件抓取数据包

2、 拦截数据包， 将HTTP方法修改为GET、 POST、 HEAD、 PUT、 DELETE、TRACE等

3、 分别发送数据包到服务器

4、 查看每种HTTP方法的返回结果。 如果服务器完全忽略请求或者返回错误， 则该项是安全的。 如果服务器有其他任何返回， 则服务器响应了不必要的方法， 是不安全的。

注意： GET和POST响应是正常的， 其他的不正常

 

2. HTTP响应头拆分漏洞

1）描述

HTTP响应头拆分漏洞（CRLF） 是一种新型的web攻击方案， 它重新产生了很多安全
漏洞包括： web缓存感染、 用户信息涂改、 窃取敏感用户页面、 跨站脚本漏洞。 这项攻击方案包括其衍生的一系列技术产生， 是由于web应用程序没有对用户的提交进行
严格过滤， 导致非法用户可以提交一些恶意字符， 更具体来说， 是对用户输入的CR和LF字符没有进行严格的过滤。

CRLF是"回车 + 换行"(\r\n)的简称。 在HTTP协议中， HTTP Header与HTTP Body是用两个CRLF分隔的， 浏览器就是根据这两个CRLF来取出HTTP内容并显示出来。 所
以， 一旦我们能够控制HTTP消息头中的字符， 注入一些恶意的换行， 这样我们就能注入一些会话Cookie或者HTML代码， 所以CRLF Injection又叫HTTP Response
Splitting（HRS） 。 是应用程序没有正确的过滤用户提供的输入。 远程攻击者可以利用这个漏洞影响或错误的显示Web内容服务、 缓存或解释的方式， 这可能帮助诱骗客户端用户， 导致跨站脚本、 缓存破坏或页面劫持等漏洞。

3） 检测方法

通过web扫描工具进行扫描检测， 或者手工去判断。
手工判断举例： 一般网站会在HTTP头中用Location: http://baidu.com这种方式来进行302跳转， 所以我们能控制的内容就是Location： 后面的XXX某个网址， 如下所示为
抓包得到的相关数据包：

HTTP/1.1 302 Moved Temporarily
Date: Fri, 27 Jun 2014 17:52:17 GMT
Content-Type: text/html
Content-Length: 154
Connection: close
Location: http://www.sina.com.cn

然后手工输入链接：
http://www.sina.com.cn%0aSet-cookie:JSPSESSID%3Dwooyun后， 再次抓包得到
如下：

HTTP/1.1 302 Moved Temporarily
Date: Fri, 27 Jun 2014 17:52:17 GMT
Content-Type: text/html
Content-Length: 154
Connection: close
Location: http://www.sina.com.cn
Set-cookie: JSPSESSID=wooyun

这个时候这样我们就给访问者设置了一个SESSION， 可以发现在http header处多了一行， 如果某应用刚好可以受这个参数控制， 那将会有重大影响， 否则， 该漏洞的危
害比较小。 当然， HRS并不仅限于会话固定， 通过注入两个CRLF就能造成一个无视浏览器Filter的反射型XSS。

 

4）修复方案

建议过滤\r、 \n之类的换行符， 避免输入的数据污染到其他HTTP头

 

3. HTTP Host头攻击

1）描述：

一般通用web程序是如果想知道网站域名不是一件简单的事情， 如果用一个固定的URI来作为域名会有各种麻烦。 开发人员一般是依赖HTTP Host header(比如在php里
是_SERVER["HTTP_HOST"] )， 而这个header很多情况下是靠不住的。 而很多应用是直接把这个值不做html编码便输出到了页面中， 比如：

<link href=http://_SERVER["HTTP_HOST"]></link> //触发一个get请求
<form method=” POST” ></form> //触发POST请求

这样处理问题一般会很容易遭遇到两种常见的攻击： 缓存污染和密码重置。 缓存污染是指攻击者通过控制一个缓存系统来将一个恶意站点的页面返回给用户。 密码重置这
种攻击主要是因为发送给用户的内容是可以污染的， 也就是说可以间接的劫持邮件发送内容

2） 检测条件 

• 被测网站使用了依赖HTTP Host header的功能
• 网站具有密码重置， 发送邮件功能
  
  

3）检测方法

• 密码重置污染攻击， 点击重置密码的链接时， url::abs_site这一部分使用的Host
  header是来自用户重置密码的请求， 那么可以通过一个受他控制的链接来污染密码重
  置的邮件， 例如替换host： 当然这种攻击方式一定要能骗取用户点击访问这个受污染
  的链接， 如果用户警觉了没有点击， 那么攻击就会失败
  
  
• 通过Host header来污染缓存的攻击方法:
  
  因此为了能使缓存能将污染后的response返回给用户， 我们还必须让缓存服务器看到
  的host header和应用看到的host header不一样， 比如说对于Varnish(一个很有名的
  缓存服务软件)， 可以使用一个复制的Host header。 Varnish是通过最先到达的请求的
  host header来辨别host的， 而Apache则是看所有请求的host， Nginx则只是看最后一
  个请求的host。 这就意味着你可以通过下面这个请求来欺骗Varnish达到污染的目的
  
  
• 修改参数：
  
  http://example.com/?mode=guest&search=kittens&num=100
  //正常请求
  http://example.com/?mode=guest&search=kittens&num=100&search=dogs&num=1
  200
  //附加多余参数， 注意参数名不变， 数量增加， 参数数值改变。
  //如果响应返回内容与正常请求的返回内容不同， 则可能触发参数污染漏洞。
  
  

4. 命令注入

1）描述

Command Injection， 即命令注入攻击， 是指由于Web应用程序对用户提交的数据滤不严格， 导致黑客可以通过构造特殊命令字符串的方式， 将数据提交至Web应用程
序中， 并利用该方式执行外部程序或系统命令实施攻击， 非法获取数据或者网络资源等。 在命令注入的漏洞中， 最为常见的是PHP的命令注入。 PHP命令注入攻击存在的
主要原因是Web应用程序员在应用PHP语言中一些具有命令执行功能的函数时， 对用户提交的数据内容没有进行严格的过滤就带入函数中执行而造成的。 例如， 当黑客提
交的数据内容为向网站目录写入PHP文件时， 就可以通过该命令注入攻击漏洞写入一个PHP后门文件， 进而实施进一步的渗透攻击。

 

2） 检测条件：

已知某页面URL (假设为http://www.exmaple.com/abc.jsp) 接收参数， 且参数中接收
类似于系统命令的字符(假设为cmd=ls)

3） 检测方法

在Web应用程序中查看文件时， 文件名通常显示在URL中。 Perl允许进程通过管道把
数据传送到open语句中。 用户只需在文件名尾部追加管道符号" | "即可。
更改前的示例URL：

http://sensitive/cgi-bin/userData.pl?doc=user1.txt<br>

修改后的示例URL：

http://sensitive/cgi-bin/userData.pl?doc=/bin/ls|<br>

web服务器将执行命令" /bin/ls "。
在PHP页面的URL末尾添加分号， 然后再加上操作系统命令， web服务器将执行该命
令。 ％3B是分号经过URL编码后的值。

http://sensitive/something.php?dir=%3Bcat%20/etc/passwd<br>

假设有一个应用程序包含一系列文档， 你可以通过会联网浏览这些文档。 再使用
WebScarab工具， 可以捕获如下所示的POST请求。
在POST请求中， 我们留意到该应用是如何检索公共文档的。 现在我们可以测试是否
可以将操作系统命令注入到POST请求中。 尝试如下操作：

POST http://www.example.com/public/doc HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1)
Gecko/20061010 FireFox/2.0
Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,imag
e/png,*/*;q=0.5
Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Proxy-Connection: keep-alive
Referer: http://127.0.0.1/WebGoat/attack?Screen=20
Cookie: JSESSIONID=295500AD2AAEEBEDC9DB86E34F24A0A5
Authorization: Basic T2Vbc1Q9Z3V2Tc3e
Content-Type: application/x-www-form-urlencoded
Content-length: 33
Doc=Doc1.pdf