[Snort-users] Why content and not uricontent?

Matt Kettler mkettler at ...4108...
Thu Apr 21 10:06:01 EDT 2005

Holger Mense wrote:

>thank you for your answer. I thought about it, however, I didn't get it ;)
>* Brian <bmc at ...950...>:
>>On Tue, Apr 12, 2005 at 11:43:59PM +0200, Holger Mense wrote:
>>>Now I am curios. Can someone explain me, if there are any reasons
>>>for using content over uricontent?
>>phf can be exploited via POST as well as GET.  http inspect doesn't
>>provide a normalized parameter detection method, 
>I don't understand this. Using uricontent="QALIAS" worked for me, even when 
>the string "qalias" used hex encoding. And this part of the URL already 
>belongs to the parameter.

I think Brian's point is that uricontent doesn't match the parameters to
a HTTP POST command, only the URI itself.

I assume in your testing you were using a GET, not a POST with an
exploiting parameter.

Since in the POST method, the parameter isn't a part of the URI, the
attack string won't be seen by uricontent rules if the attacker uses
this method.

Thus, while using uricontent closes the hole of encoded requests, it
opens the hole of someone using the POST command for the exploit.

On the other hand, content fails to handle encodings, but it does match
both POST and GET requests.

I'd suspect you really want both rules, one to deal with encoded GET
requests, the other to deal with exploits via the POST command.

Or, better yet, a http_inspect hack to allow a "uricontent" equivalent
for POST parameters. (you would want to create a new keyword for this..
) and use two rules, one with uricontent, the other with
"postparametercontent" or whatever.

More information about the Snort-users mailing list