Re: [mod-security-users] ARGS question

[Nicola B. <bia...@gm...>]

Brian,
I agree with your consideration and I have a question:

if the content type header is declared as *application/x-www-form-**
urlencoded* and modsecurity/core-rules can not find a *=* character in the
post, why this is not considered a "protocol violation"?

Regards.
  Nick


On Thu, Mar 19, 2009 at 5:19 PM, Brian Rectanus
<Bri...@br...>wrote:

> Ryan Barnett wrote:
>
>> -----Original Message-----
>> From: Christian Bockermann [mailto:ch...@jw...]
>> Sent: Thursday, March 19, 2009 10:47 AM
>> To: Nicola Bianchi
>> Cc: Mod Security
>> Subject: Re: [mod-security-users] ARGS question
>>
>>
>> Am 19.03.2009 um 15:30 schrieb Nicola Bianchi:
>>
>>  Hi people,
>>> I've a question about the ARGS variable.
>>>
>>> To prevent html injection in some forms we created this rules:
>>>   SecRule ARGS "<.+>"  log,deny,status:403,phase:2,t:lowercase
>>>
>>> Now I have an application that generate something like this:
>>>
>>> ############################################
>>> POST /FinalImage.xml HTTP/1.1
>>> Host: www.mydomain.com:8080
>>> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:
>>> 1.9.0.7) Gecko/2009021910 Firefox/3.0.7
>>> Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/
>>> *;q=0.8
>>> Accept-Language: it,en-us;q=0.7,en;q=0.3
>>> Accept-Encoding: gzip,deflate
>>> Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
>>> Keep-Alive: 300
>>> Connection: keep-alive
>>> Cookie: JSESSIONID=EA28BA4AEB3A4046F4BEF3879597CC7E
>>> Referer: http://www.mydomain.com:8080/test.swf
>>> Content-type: application/x-www-form-urlencoded
>>> Content-length: 552
>>>
>>> <imageParameters><imageWidth>2880</imageWidth><imageHeight>1854</
>>> imageHeight><x1>-10</x1><y1>-8</y1><x2>252</x2><y2>161</y2><xx1>115</
>>> xx1><yy1>86</yy1><xx2>2764</xx2><yy2>1767</
>>> yy2><scale>9.09895833333333</scale><rotation>0</rotation><flipx>100</
>>> flipx><imageKeyNo>-1=</imageKeyNo><shortFileName>1236866715292</
>>> shortFileName><processNo>1</processNo><circuit>XXX</circuit><logo>N</
>>> logo><uploadedFile>true</uploadedFile><clientType>P</
>>> clientType><back>false</back><noImgGal>0</noImgGal></imageParameters>
>>> ############################################
>>>
>>> and the request is correctly denied!
>>>
>>> But if in the same POST I don't have a "=" character the request is
>>> not denied....
>>>
>>> ############################################
>>> <imageParameters><imageWidth>2880</imageWidth><imageHeight>1854</
>>> imageHeight><x1>-10</x1><y1>-8</y1><x2>252</x2><y2>161</y2><xx1>115</
>>> xx1><yy1>86</yy1><xx2>2764</xx2><yy2>1767</
>>> yy2><scale>9.09895833333333</scale><rotation>0</rotation><flipx>100</
>>> flipx><imageKeyNo>-1</imageKeyNo><shortFileName>1236866715292</
>>> shortFileName><processNo>1</processNo><circuit>XXX</circuit><logo>N</
>>> logo><uploadedFile>true</uploadedFile><clientType>P</
>>> clientType><back>false</back><noImgGal>0</noImgGal></imageParameters>
>>> ############################################
>>>
>>> Why? Is it correct?
>>>
>>
>> Ehh... though a little bit confusing, the answer is: Yes, it's sort of
>> "correct"  :-)
>>
>> It relies on how ModSecurity fills the ARGS collection. With ARGS you
>> specify a collection of (key,value) pairs resulting from parsing the
>> request data. In HTTP requests variables and their values are
>> separated by "=", e.g.
>>
>>     id=idvalue&var2=value2
>>
>> If ModSecurity finds this in your request it will start splitting the
>> request body first by "&" (in case of the query-string) and then split
>> the resulting parts by "=", which will finally reveal the variable
>> names and their associated values. These are
>> then added to the ARGS collection.
>>
>> If no "=" is found, then there is in a sense no variable (even an
>> empty variable would be transmitted as "variable=". Thus, your second
>> POST request does not include any variable, therefore ModSecurity does
>> not fill the ARGS collection.
>>
>> [Ryan Barnett] This scenario is also an example of why we populate and
>> evaluate the ARGS_NAMES collection.  As Christian outlined, if the format of
>> the REQUEST_BODY does not conform to normal "
>> application/x-www-form-urlencoded" standards of the name=value pairs, then
>> essentially the entire payload would most likely be considered an argument
>> name with no value.
>>
>> If you aren't sure how ModSecurity is handling the data, you should review
>> the debug log.
>>
>>
> Just to clarify, ModSecurity uses the Content-Type header to determine,
> well, the content type ;)  So, if you have the following (as I see above you
> do)
>
> Content-Type: application/x-www-form-urlencoded
>
> It is going to attempt parse the body with the URLENCODED processor (ie
> "var1=val1&var2=val2") by default.
>
> ModSecurity also understands multipart/form-data and will populate ARGS in
> this format as well.  What you have is XML and you may want to force the
> parser to XML with:
>
> ctl:requestBodyProcessor=XML
>
> You may also want to change the content type in the post to a more sensible
> "text/xml".  With this, you can also check the body with xpath expressions
> as well as a buffer (REQUEST_BODY).
>
> See:
>
>
> http://modsecurity.org/documentation/modsecurity-apache/2.5.9/modsecurity2-apache-reference.html#N11661
>
> and
>
>
> http://modsecurity.org/documentation/modsecurity-apache/2.5.9/modsecurity2-apache-reference.html#N1133F
>
>
> -B
>
> --
> Brian Rectanus
> Breach Security
>