[Oisf-devel] http evasion research

Peter Manev petermanev at gmail.com
Thu Jun 13 14:15:43 UTC 2013


On Thu, Jun 13, 2013 at 4:06 PM, Ivan Ristic <ivan.ristic at gmail.com> wrote:
> On Wed, Jun 12, 2013 at 9:53 PM, Ivan Ristic <ivan.ristic at gmail.com> wrote:
>> I'll try to have a look at some of those by the end of the week
>> (against libhtp 0.5.x).
>
> Here's what I have found:
>
> - On the inbound, a request that contains a T-E header with anything
> but "chunked" will error out (i.e., the stream will error out).
> - On the outbound, a T-E header in the response with anything but
> "chunked" will be ignored. Content-Length will be used when available,
> and if C-L is not available the body will stretch until the end of the
> connection.
>
> In the first instance, LibHTP should be raising flags for the invalid
> response T-E header (and possibly response smuggling; I haven't looked
> at this yet).
>
> Other than that, the question is how do we handle these cases when
> browsers interpret the same stream differently. Unlike with servers,
> where we can determine and set the correct personality (in theory, I
> wonder how many people would do that in practice), with outbound
> traffic we can't choose any one approach.
>

BTW - What do you think for "per browser inspection", like we do now
on  a per "OS type" stream reassembly. I am guessing it would be
really cool but almost impossible to implement?




> The possibilities are as follows:
> 1. Raise flags as appropriate
> 2. Force dechunking
> 3. Process the same stream twice, with and without chunking
>
> #1 is clearly easy and I suspect #2 would be fine, but more research
> is needed. Perhaps this is something that we can work on for LibHTP
> 0.6.x.
>
>



--
Regards,
Peter Manev



More information about the Oisf-devel mailing list