mod-security-users

[mod-security-users] url-encoded versus urlencoded

[Hugh B. <hbe...@ya...>]

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: 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=xx...@xx...&url=xx...@xx...&comments=xx...@xx...&main=xx...@xx...&RESET=xx...@xx...

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

Re: [mod-security-users] url-encoded versus urlencoded

[Ivan R. <iv...@we...>]

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 ]

Re: [mod-security-users] url-encoded versus urlencoded

[Hugh B. <hbe...@ya...>]

--- Ivan Ristic <iv...@we...> 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.
> 

Just as a follow up, I also saw this tonight :


Content-Type: application/x-vermeer-urlencoded
Date: Tue, 27 Jul 2004 22:49:20 GMT
Host: sdhenterprises.com
MIME-Version: 1.0
User-Agent: MSFrontPage/4.0
X-Vermeer-Content-Type: application/x-vermeer-urlencoded


Looks like Microsoft FrontPage is using:

Content-Type: application/x-vermeer-urlencoded

Just thought I'd add this as a note for the archives...




		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail