[Snort-sigs] [Emerging-Sigs] what s the real difference here?
jesler at ...435...
Tue Jul 13 20:06:52 EDT 2010
On Jul 13, 2010, at 8:03 PM, evilghost at ...3397... wrote:
>>> Riddle me this. If I constrain a content match to the URI buffer (ala http_uri;) can I now use content modifiers which do not work with a uricontent match? Some of these being
>>> depth, distance, isdataat, etc?
>> I'd like the Snort team to comment on this one, as I don't want to give you a wrong answer, but since it's reading a normalized field, my knee jerk reaction is to say "no."
> Thanks Joel, the reason I ask is I think I ran into this issue with a content match following another content match constrained to 'http_cookie;' which attempted to be relative to
> the previous content match with a modifier (from what I recall it was 'distance'). AFAIK it doesn't work this way and 'content:"spice"; http_uri;' is a pseudonym for
> 'uricontent:"spice";' and any content modifiers aren't applicable. I'm not sure that's going to be implied in the manual with regard to many of the content modifiers... Make sense?
Yes, I do understand. Like I said, I'd like a Snort team comment on this one, just so we can be clear. Are you saying that we should make it clear in the manual?
> Essentially, confining to the http_uri; isn't as "useful" as http_cookie; and http_header; due to the existence of uricontent.
Yeah, let me defer to comment from the dev. I am sure there was a reason for the separate development, even if it's planning for future use.
More information about the Snort-sigs