[Snort-sigs] Question about Content-Disposition, Content-Type, etc. and http_header buffer

Joel Esler jesler at ...435...
Thu Oct 25 17:56:53 EDT 2012


Now I understand.

Let me start by apologizing for being confused.  The streams were crossed.

I understand what you are saying.  So currently, you have to use http_client_body to get to that field because of the way the current http_inspect parser works.  Let me doing some checking and I'll get back to you about future plans, (we are doing some code work in that area now).

--
Joel Esler
Senior Research Engineer, VRT
OpenSource Community Manager
Sourcefire


On Oct 25, 2012, at 5:50 PM, Mike Cox <mike.cox52 at ...2420...> wrote:

> I think the packets are correct.  I guess the situation is, when you have encoding such as multipart/form-data, some header fields like Content-Disposition can end up in the body of the message.  Thus, snort rules matching on such headers and using the http_header buffer, won't match as intended.  Make sense?
> 
> I was wondering if it was possible for http_inspect to realize this situation and populate the http_header buffer with the headers from the body so that rules matching on things like Content-Disposition in http_header will still alert properly with situations such as multipart/form data encoding.
> 
> Thanks!
> 
> -Mike Cox
> 
> On Thu, Oct 25, 2012 at 4:35 PM, Joel Esler <jesler at ...435...> wrote:
> On Oct 25, 2012, at 4:35 PM, lists at ...3397... wrote:
>> On 10/25/2012 03:07 PM, Joel Esler wrote:
>>> Am I still missing the point?  Am I insane?  
>> 
>> You're missing RFC 6266 which updates RFC 2616 ;)
> 
> There isn't anything in that rfc that alerts the behavior of where the header ends.
> 
> My point is, I think, if I'm right, is whatever program is generating the packets that Mike is talking about isn't doing so correctly.
> 
> --
> Joel Esler
> Senior Research Engineer, VRT
> OpenSource Community Manager
> Sourcefire
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-sigs/attachments/20121025/bec5734f/attachment.html>


More information about the Snort-sigs mailing list