mod-security-users

[mod-security-users] XML Parsing

[Pfeiffer, B. <ber...@br...>]

Hey!

Found some problem, parsing XML-Documents. The problem is, that modsecurity_crs_10_config.conf Line: ~ 407

SecRule REQUEST_HEADERS:Content-Type "text/xml" \
"id:'900017', \
phase:1, \
t:none,t:lowercase, \
nolog, \
pass, \
chain"
SecRule REQBODY_PROCESSOR "!@streq<https://github.com/streq> XML" \
"ctl:requestBodyProcessor=XML"

It is parsing every content, which includes "text/xml". I think it would be better,

SecRule REQUEST_HEADERS:Content-Type "^text/xml"

Do you agree with it?!

Hope for an answer.

Greets,
Bernhard

[mod-security-users] XML Parsing

[Jai H. <jai...@mu...>]

As expected, parsing an XML request takes a significant amount of time. I
am trying to determine if there is any benefit to parsing XML requests if
the only rules I am using are from OWASP CRS. Are there any OWASP CRS rules
which require XML requests to be parsed?

I see many rules with the following pattern:

SecRule ARGS_NAMES|ARGS|XML:/*
"(?:\n|\r)+(?:get|post|head|options|connect|put|delete|trace|propfind|propatch|mkcol|copy|move|lock|unlock)\s+"
\
    "msg:'HTTP Request Smuggling Attack',\
    phase:request,\
    id:921110,\
    rev:'1',\
     . . .

These rules are not doing anything "XML-specific". For the rule above, the
operator can be applied to a plain text request. So, why pay the penalty of
parsing XML?

Re: [mod-security-users] XML Parsing

[Robert P. <rpa...@fe...>]

Given that XML parsing shouldn't even occur unless the content type
indicates an XML document in the body, is it much of a concern? How much
XML traffic do you actually serve up?

As for the usefulness of the XML variable within the rule variables, that
itself might be a better question for the CRS mailing list/developers.

On Tue, Apr 24, 2018 at 7:52 AM, Jai Harpalani via mod-security-users <
mod...@li...> wrote:

> As expected, parsing an XML request takes a significant amount of time. I
> am trying to determine if there is any benefit to parsing XML requests if
> the only rules I am using are from OWASP CRS. Are there any OWASP CRS rules
> which require XML requests to be parsed?
>
> I see many rules with the following pattern:
>
> SecRule ARGS_NAMES|ARGS|XML:/* "(?:\n|\r)+(?:get|post|head|
> options|connect|put|delete|trace|propfind|propatch|mkcol|copy|move|lock|unlock)\s+"
> \
>     "msg:'HTTP Request Smuggling Attack',\
>     phase:request,\
>     id:921110,\
>     rev:'1',\
>      . . .
>
> These rules are not doing anything "XML-specific". For the rule above, the
> operator can be applied to a plain text request. So, why pay the penalty of
> parsing XML?
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
> Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> http://www.modsecurity.org/projects/commercial/rules/
> http://www.modsecurity.org/projects/commercial/support/
>
>

Re: [mod-security-users] XML Parsing

[William C. <wil...@mu...>]

XML parse errors fire a few rules in OWASP 3. Here's an example snip from
our logs related to such:

{"wafEvent":{"cluster":"","node":"icvlab11401","timestamp":"2018-04-24T15:47:50.312Z","clientIpAddr":"1.2.3.4","clientPort":666,"uri":"/acme/voodoo/lounge","serverIpAddr":"127.0.0.1","serverPort":999,"transId":2,"correlationId":"13cd1823-e5ba-42e3-bea0-b5131408212e"},"ruleMatch":[{"ruleId":200002,"ruleVersion":"","severity":2,"phase":2,"message":"Failed
to parse request
body.","tags":[]},{"ruleId":920130,"ruleVersion":"OWASP_CRS/3.0.0","severity":2,"phase":2,"message":"Failed
to parse request
body.","tags":["application-multi","language-multi","platform-multi","attack-protocol","OWASP_CRS/PROTOCOL_VIOLATION/INVALID_REQ","CAPEC-272"]},{"ruleId":949110,"ruleVersion":"","severity":2,"phase":2,"message":"Inbound
Anomaly Score Exceeded (Total Score:
5)","tags":["application-multi","language-multi","platform-multi","attack-generic"]},{"ruleId":980130,"ruleVersion":"","severity":0,"phase":5,"message":"Inbound
Anomaly Score Exceeded (Total Inbound Score: 5 -
SQLI=0,XSS=0,RFI=0,LFI=0,RCE=0,PHPI=0,HTTP=0,SESS=0): Failed to parse
request body.'","tags":["event-correlation"]}]}

On a somewhat related note, does anyone have a trick, patch or pointers to
the ModSec 3.0 source to prevent the libxml2 from spewing parse error
artifacts to the console? For example (body.xml ModSec's name for the
request document):

body.xml:8: parser error : expected '>'
</soapenv:Envelope>
^

Regards - Jay


On Tue, Apr 24, 2018 at 10:55 AM, Robert Paprocki <
rpa...@fe...> wrote:

> Given that XML parsing shouldn't even occur unless the content type
> indicates an XML document in the body, is it much of a concern? How much
> XML traffic do you actually serve up?
>
> As for the usefulness of the XML variable within the rule variables, that
> itself might be a better question for the CRS mailing list/developers.
>
> On Tue, Apr 24, 2018 at 7:52 AM, Jai Harpalani via mod-security-users <
> mod...@li...> wrote:
>
>> As expected, parsing an XML request takes a significant amount of time. I
>> am trying to determine if there is any benefit to parsing XML requests if
>> the only rules I am using are from OWASP CRS. Are there any OWASP CRS rules
>> which require XML requests to be parsed?
>>
>> I see many rules with the following pattern:
>>
>> SecRule ARGS_NAMES|ARGS|XML:/* "(?:\n|\r)+(?:get|post|head|op
>> tions|connect|put|delete|trace|propfind|propatch|mkcol|copy|move|lock|unlock)\s+"
>> \
>>     "msg:'HTTP Request Smuggling Attack',\
>>     phase:request,\
>>     id:921110,\
>>     rev:'1',\
>>      . . .
>>
>> These rules are not doing anything "XML-specific". For the rule above,
>> the operator can be applied to a plain text request. So, why pay the
>> penalty of parsing XML?
>>
>> ------------------------------------------------------------
>> ------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> mod-security-users mailing list
>> mod...@li...
>> https://lists.sourceforge.net/lists/listinfo/mod-security-users
>> Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
>> http://www.modsecurity.org/projects/commercial/rules/
>> http://www.modsecurity.org/projects/commercial/support/
>>
>>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
> Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> http://www.modsecurity.org/projects/commercial/rules/
> http://www.modsecurity.org/projects/commercial/support/
>
>