Re: [mod-security-users] Nulls in post cause false negative (Bug?)

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

re...@g8... wrote:
>>   No, it is definitely a bug - I'll upload a fix to the CVS
>>   tonight.
> 
> Wow, that's quick :)

   I fixed it tonight. I checked, it is visible now via the
   anonymous CVS (sometimes it is up to a day late).


> I spent a little bit of time looking through mod_security.c.  It seems
> as if you'd still want this case to be caught when
> "SecFilterForceByteRange 0 255" was given as a setting.  The program
> on the receiving end (a cgi in this case) still sees 0x0 coming
> though, and everything afterwards.  In some languages, ^@ is a
> perfectly valid character.
> 
> This is a tricky one, since regexec() is expecting a null terminated
> string.  Perhaps remove_binary_content() after normalise_uri() would
> be the ticket.

   I agree. I don't think many people will expect (or even think
   about) null characters. I'll add one more remove_binary_content
   call there.

   While we are at the subject, please note that parameters are
   not parsed when multipart/form-data content type is used. I have
   the code to parse that and I'll integrate it some time soon.


> This is more of an RFE, but it would also be nice to allow arbitrary
> binary data in keyword patterns.  (Like "\177ELF" :).

   Did you try it? I've had no problem running regular expressions
   against binary files (with null characters removed). Maybe it
   already works.

   Would you settle for an external hook allowing you to run
   arbitrary scripts against the uploaded file?


> Thanks for the quick response.

   You are welcome :)

-- 
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]