Hugh Beaumont wrote:
> Hi,
>
> I am using this standard rule from the examples in the mod_security docs:
>
> # Only accept request encodings we know how to handle
> # we exclude GET requests from this because some (automated)
> # clients supply "text/html" as Content-Type
> SecFilterSelective REQUEST_METHOD "!^GET$" chain
> SecFilterSelective HTTP_Content-Type
> "!(^$|^application/x-www-form-urlencoded$|^multipart/form-data)"
>
> This rule is catching a lot of things like the following :
I think the rule is doing what it was designed to do. I see
such requests in my logs too.
The HTML specification defines only two content types (see
http://www.w3.org/TR/html401/interact/forms.html#h-17.13.4)
and those two are the ones used in the rule. Whoever wrote
the spam bot probably made a mistake.
--
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]

Hi,
I am using this standard rule from the examples in the mod_security docs:
# Only accept request encodings we know how to handle
# we exclude GET requests from this because some (automated)
# clients supply "text/html" as Content-Type
SecFilterSelective REQUEST_METHOD "!^GET$" chain
SecFilterSelective HTTP_Content-Type
"!(^$|^application/x-www-form-urlencoded$|^multipart/form-data)"
This rule is catching a lot of things like the following :
(I've xxx'd out a few things for privacy of the user involved)
HTTP/1.1 403 Forbidden
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-1
========================================
Request: xx.xx.xxx.xxx - - [27/Jul/2004:12:21:36 -0500] "POST /cgi-bin/fp.cgi HTTP/1.0" 403 284
Handler: cgi-script
----------------------------------------
POST /cgi-bin/fp.cgi HTTP/1.0
Connection: Keep-Alive
Content-Length: 343
Content-Type: application/x-www-url-encoded
Host: http://www.xxxxxxx.com
Referer: http://www.xxxxxxx.com/
Via: 1.0 BBSM52
mod_security-message: Access denied with code 403. Pattern match
"!(^$|^application/x-www-form-urlencoded$|^multipart/form-data)" at HEADER.
mod_security-action: 403
343
email=%0AFrom%3A+8pp0xbj%40xxxxxxx%2Ecom%0ATo%3A+xxxxxxxxxxxxxx%40xxx%2Exxx%0ASubject%3A++2yaz+tressful+Kiahsville+Packwood+Atik+antimoralism%27s+Corsica%0A%0AYugz+r+fVAclUiu05CcIa2SHeug+e1Zp++oyPj
idglW+JbEF0lUnPDv%0A%0A%2E%0A%0A&name=xxxx@...&url=xxxx@...&comments=xxxx@...&main=xxxx@...&RESET=xxxx@...
HTTP/1.0 403 Forbidden
Connection: close
Content-Type: text/html; charset=iso-8859-1
It appears to me that the reason this is hitting is because the client sent an encoding of :
Content-Type: application/x-www-url-encoded
and not :
Content-Type: application/x-www-form-urlencoded
One has url-encoded while the rule only allows urlencoded (no dash between url and encoded).
Does this seem correct?
Any advice on these?
I get a bunch of these hitting on various formmail type scripts. My guess is that this a badly
written spambot that is sending x-www-url-encoded.
Should I just let these continue to be dumped. From looking at the form payload it looks like
typical spam jibberish - but I may be reading them wrong.
Has anyone seen this before?
Would anyone recommend I adjust the rule to be:
SecFilterSelective HTTP_Content-Type
"!(^$|^application/x-www-form-urlencoded$|^application/x-www-form-url-encoded$|^multipart/form-data)"
(add the url dash encoded version)
Your thoughts are appreciated!
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail