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

Mike Cox mike.cox52 at ...2420...
Thu Oct 25 18:03:26 EDT 2012


Thanks Joel.

Remember, never cross the streams :)

-Mike Cox

On Thu, Oct 25, 2012 at 4:56 PM, Joel Esler <jesler at ...435...> wrote:

> *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/0584e80d/attachment.html>


More information about the Snort-sigs mailing list