[Owasp-modsecurity-core-rule-set] if i have mod-security installed and owasp-modsecurity-core-rule-set, to i need to worry about vulnerability like CSRF?

Tendani Munyai Mon, 25 Nov 2013 23:37:51 -0800

On 26/11/2013 01:28,owasp-modsecurity-core-rule-set-requ...@lists.owasp.org wrote:

Send Owasp-modsecurity-core-rule-set mailing list submissions to
        owasp-modsecurity-core-rule-set@lists.owasp.org


To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set

or, via email, send a message with subject or body 'help' to
        owasp-modsecurity-core-rule-set-requ...@lists.owasp.org

You can reach the person managing the list at
        owasp-modsecurity-core-rule-set-ow...@lists.owasp.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Owasp-modsecurity-core-rule-set digest..."


Today's Topics:

    1. Re: Location/LocationMatch failing to disable rules
       (Phill Watkins)
    2. Re: Location/LocationMatch failing to disable rules
       (Jose Pablo Valc?rcel L?zaro)


----------------------------------------------------------------------

Message: 1
Date: Mon, 25 Nov 2013 20:21:23 +0000
From: Phill Watkins <phill.watk...@gmail.com>
To: OWASP CRS Mailing List
        <owasp-modsecurity-core-rule-set@lists.owasp.org>
Subject: Re: [Owasp-modsecurity-core-rule-set] Location/LocationMatch
        failing to disable rules
Message-ID:
        <caonsccwsomwbvd8anxiaz2x9hikho11v6t_6mm4sf7nvacx...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

Thanks replying.

I'm using CRS version 2.2.8 with ModSecurity 2.7.5. As far as I can tell
the rule has already been updated as per your example.

I tried using Directory instead of Location but it didn't work and I kind
of understand this since Subsonic is essentially being accessed by proxy
(AJP connector).

Your nesting idea will work but will have the effect of disabling the rule
globally if mod_jk is enabled, which I'm trying to avoid.

Rule ID 330792 is from the Atomicorp (now defunct) delayed rules. I was
using this as an example to show that I've successfully used Location to a
disable a rule for Subsonic before. Sorry for the confusion.

Regards


On 25 November 2013 17:46, Jose Pablo Valc?rcel L?zaro <
pablo.valcarcel1...@gmail.com> wrote:

Sorry, I was wrong. You should be able to use location match as you have
written.

You should be able to comment original rule 330792 but instead disabling
at all, copy it into a customized.conf rules and try to rewrite rule to
bypass what is triggering that rule, in your case:

Message: Access denied with code 403 (phase 1). Match of "rx
^%{tx.allowed_request_content_type}$" against "TX:0" required. [file
"/etc/apache2/owasp-modsecurity-crs/activated_
rules/modsecurity_crs_30_http_policy.conf"] [line "64"] [id "960010"]
[rev "2"] [msg "Request content type is not allowed by policy"] [data
"text/plain"] [severity "CRITICAL"] [ver "OWASP_CRS/2.2.8"] [maturity "9"]
[accuracy "9"] [tag "OWASP_CRS/POLICY/ENCODING_NOT_ALLOWED"] [tag
"WASCTC/WASC-20"] [tag "OWASP_TOP_10/A1"] [tag "OWASP_AppSensor/EE2"] [tag
"PCI/12.1"]

I?m watching that is not 330792 rule id, instead it seems 960010 rule id
on /etc/apache2/owasp-modsecurity-crs/activated_
rules/modsecurity_crs_30_http_policy.conf and it?s blocked because of Request
content type is not allowed by policy.


It could be a older bug depending on mod_security rule version you are
using:

http://web.archiveorange.com/archive/v/eCIWmXcpDxoRYUESRQEg



There is a bug in that rule as it is missing a "chain" action on the 2nd
SecRule.  The
rule should be this -

SecRule REQUEST_METHOD "!^(?:GET|HEAD|PROPFIND|OPTIONS)$"
"phase:2,chain,t:none,pass,nolog,auditlog,msg:'Request content type is not
allowed
by

policy',id:'960010',tag:'POLICY/ENCODING_NOT_ALLOWED',tag:'WASCTC/WASC-20',tag:'OWASP_TOP_10/A1',tag:'OWASP_AppSensor/EE2',tag:'PCI/12.1',
severity:'4',logdata:'%{matched_var}'"
         SecRule REQUEST_HEADERS:Content-Type "^([^;\s]+)" "chain,capture"
                 SecRule TX:0 "!@within %{tx.allowed_request_content_type}"
"t:none,setvar:'tx.msg=%{rule.msg}',setvar:tx.anomaly_score=+%{tx.

warning_anomaly_score},setvar:tx.policy_score=+%{tx.warning_anomaly_score},setvar:tx.
%{rule.id}-POLICY/CONTENT_TYPE_NOT_ALLOWED-%{matched_var
_name}=%{matched_var}"

This issue has already been reported in JIRA
(https://www.modsecurity.org/tracker/browse/CO...) and fixed in CRS
v2.0.6.  You can
manually add the "chain" action to your rule to fix the issue now.

-Ryan

Which mod_security rule version are you using?

Kind regards,


2013/11/25 Jose Pablo Valc?rcel L?zaro <pablo.valcarcel1...@gmail.com>

Or simply try to nest as follows:

<IfModule mod_jk.c>
  JkMount /subsonic ajp13_worker
JkMount /subsonic/* ajp13_worker
<IfModule mod_security2.c>
  SecRuleRemoveById 330039
</IfModule>
</IfModule>

Kind regards,


2013/11/25 Jose Pablo Valc?rcel L?zaro <pablo.valcarcel1...@gmail.com>

In mod_security migration matrix table you will see features against
different mod_security versions:

https://github.com/SpiderLabs/ModSecurity/wiki/ModSecurity-Migration-Matrix

Ability to manage rules in Apache Scope locations
SecFilterRemove is now SecRuleRemoveById or SecRuleRemoveByMsg.
SecFilterImport is no longer supported.

So following that feature, I guess location directive you just can only
use to disable rules.

If you want to enable a specific rule, you should develop within
specific rules and disable in all domains you don?t need to check it.

Kind regards,


2013/11/25 Jose Pablo Valc?rcel L?zaro <pablo.valcarcel1...@gmail.com>

Hi.

I have seen rules to disabling by id as follows:

<IfModule security2_module>
  <Directory /local/home/username/example.net>
         SecRuleRemoveById 330039
  </Directory>
</IfModule>

Have you try with  apache Directory directive?

Kind regards,


2013/11/25 Phill Watkins <phill.watk...@gmail.com>

  Hi,

For some reason I'm struggling to to disable rules using
SecRuleRemoveById inside a Location or LocationMatch.

I can disable rules globally (which isn't ideal) so I know the
directive works but I don't know why Apache doesn't act upon the
Location/LocationMatch.

One of the applications on my web server that I'm trying to disable a
rule for is Subsonic. Subsonic requires Tomcat and is a connected to Apache
via the AJP connector module.

  I have successfully disabled one of the Atomicorp delayed rules in
the past like this:

<IfModule mod_jk.c>
JkMount /subsonic ajp13_worker
  JkMount /subsonic/* ajp13_worker
<Location /subsonic/upload.view>
SecRuleRemoveById 330792
  </Location>
</IfModule>

I am now trying to disable rule 960010 from the CRS for the entire
application because of too many false positives.

I have tried <Location /subsonic/>  as well as multiple regular
expressions for days but nothing works.

Here is an example from the audit log:

--35e37e6c-A--
[12/Nov/2013:12:19:05 +0000] UoIcuX8AAQEAAAJ3AQgAAAAA hidden 45509
hidden 443
--35e37e6c-B--
POST /subsonic/dwr/call/plaincall/nowPlayingService.getNowPlaying.dwr
HTTP/1.1
Host: hidden
Connection: keep-alive
Content-Length: 214
Origin: https://hidden
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML,
like Gecko) Chrome/30.0.1599.114 Safari/537.36
Content-Type: text/plain
Accept: */*
Referer: https://hidden/subsonic/right.view?
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-GB,en-US;q=0.8,en;q=0.6
Cookie: player-656c6c6965=6; player-73727661646d=6;
JSESSIONID=088A746CDC6B4356A388E7C1D44EEE6A.ajp13_worker;
player-7068696c6c=9; compact_display_state=false

--35e37e6c-F--
HTTP/1.1 403 Forbidden
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 221
Keep-Alive: timeout=5, max=88
Connection: Keep-Alive
Content-Type: text/html; charset=iso-8859-1

--35e37e6c-H--
Message: Access denied with code 403 (phase 1). Match of "rx
^%{tx.allowed_request_content_type}$" against "TX:0" required. [file
"/etc/apache2/owasp-modsecurity-crs/activated_rules/modsecurity_crs_30_http_policy.conf"]
[line "64"] [id "960010"] [rev "2"] [msg "Request content type is not
allowed by policy"] [data "text/plain"] [severity "CRITICAL"] [ver
"OWASP_CRS/2.2.8"] [maturity "9"] [accuracy "9"] [tag
"OWASP_CRS/POLICY/ENCODING_NOT_ALLOWED"] [tag "WASCTC/WASC-20"] [tag
"OWASP_TOP_10/A1"] [tag "OWASP_AppSensor/EE2"] [tag "PCI/12.1"]
Action: Intercepted (phase 1)
Stopwatch: 1384258745437774 1085 (- - -)
Stopwatch2: 1384258745437774 1085; combined=426, p1=363, p2=0, p3=0,
p4=0, p5=63, sr=48, sw=0, l=0, gc=0
Producer: ModSecurity for Apache/2.7.5 (http://www.modsecurity.org/);
OWASP_CRS/2.2.8.
Server: Apache
Engine-Mode: "ENABLED"

--35e37e6c-Z--

I'd be grateful of any advice.

Thanks for your time.


_______________________________________________
Owasp-modsecurity-core-rule-set mailing list
Owasp-modsecurity-core-rule-set@lists.owasp.org

https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.owasp.org/pipermail/owasp-modsecurity-core-rule-set/attachments/20131125/ed883247/attachment-0001.html>

------------------------------

Message: 2
Date: Tue, 26 Nov 2013 00:28:05 +0100
From: Jose Pablo Valc?rcel L?zaro       <pablo.valcarcel1...@gmail.com>
To: Phill Watkins <phill.watk...@gmail.com>
Cc: OWASP CRS Mailing List
        <owasp-modsecurity-core-rule-set@lists.owasp.org>
Subject: Re: [Owasp-modsecurity-core-rule-set] Location/LocationMatch
        failing to disable rules
Message-ID:
        <cabkhglofbteb9chv28rmvh0oy8f97cxmg18xapjnn1f0aeo...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

Could you post denied trace?
Maybe you could copyright that rule in customized, comment original rule
and try to edit on customized to avoid triger with client specific
request.

Kind regards
El 25/11/2013 21:28, "Phill Watkins" <phill.watk...@gmail.com> escribi?:

Thanks replying.

I'm using CRS version 2.2.8 with ModSecurity 2.7.5. As far as I can tell
the rule has already been updated as per your example.

I tried using Directory instead of Location but it didn't work and I kind
of understand this since Subsonic is essentially being accessed by proxy
(AJP connector).

Your nesting idea will work but will have the effect of disabling the rule
globally if mod_jk is enabled, which I'm trying to avoid.

Rule ID 330792 is from the Atomicorp (now defunct) delayed rules. I was
using this as an example to show that I've successfully used Location to a
disable a rule for Subsonic before. Sorry for the confusion.

Regards


On 25 November 2013 17:46, Jose Pablo Valc?rcel L?zaro <
pablo.valcarcel1...@gmail.com> wrote:

Sorry, I was wrong. You should be able to use location match as you have
written.

You should be able to comment original rule 330792 but instead disabling
at all, copy it into a customized.conf rules and try to rewrite rule to
bypass what is triggering that rule, in your case:

Message: Access denied with code 403 (phase 1). Match of "rx
^%{tx.allowed_request_content_type}$" against "TX:0" required. [file
"/etc/apache2/owasp-modsecurity-crs/activated_
rules/modsecurity_crs_30_http_policy.conf"] [line "64"] [id "960010"]
[rev "2"] [msg "Request content type is not allowed by policy"] [data
"text/plain"] [severity "CRITICAL"] [ver "OWASP_CRS/2.2.8"] [maturity "9"]
[accuracy "9"] [tag "OWASP_CRS/POLICY/ENCODING_NOT_ALLOWED"] [tag
"WASCTC/WASC-20"] [tag "OWASP_TOP_10/A1"] [tag "OWASP_AppSensor/EE2"] [tag
"PCI/12.1"]

I?m watching that is not 330792 rule id, instead it seems 960010 rule id
on /etc/apache2/owasp-modsecurity-crs/activated_
rules/modsecurity_crs_30_http_policy.conf and it?s blocked because of Request
content type is not allowed by policy.


It could be a older bug depending on mod_security rule version you are
using:

http://web.archiveorange.com/archive/v/eCIWmXcpDxoRYUESRQEg




There is a bug in that rule as it is missing a "chain" action on the 2nd
SecRule.  The
rule should be this -

SecRule REQUEST_METHOD "!^(?:GET|HEAD|PROPFIND|OPTIONS)$"
"phase:2,chain,t:none,pass,nolog,auditlog,msg:'Request content type is
not allowed
by

policy',id:'960010',tag:'POLICY/ENCODING_NOT_ALLOWED',tag:'WASCTC/WASC-20',tag:'OWASP_TOP_10/A1',tag:'OWASP_AppSensor/EE2',tag:'PCI/12.1',
severity:'4',logdata:'%{matched_var}'"
         SecRule REQUEST_HEADERS:Content-Type "^([^;\s]+)" "chain,capture"
                 SecRule TX:0 "!@within
%{tx.allowed_request_content_type}"
"t:none,setvar:'tx.msg=%{rule.msg}',setvar:tx.anomaly_score=+%{tx.

warning_anomaly_score},setvar:tx.policy_score=+%{tx.warning_anomaly_score},setvar:tx.
%{rule.id}-POLICY/CONTENT_TYPE_NOT_ALLOWED-%{matched_var
_name}=%{matched_var}"

This issue has already been reported in JIRA
(https://www.modsecurity.org/tracker/browse/CO...) and fixed in CRS
v2.0.6.  You can
manually add the "chain" action to your rule to fix the issue now.

-Ryan

Which mod_security rule version are you using?

Kind regards,


2013/11/25 Jose Pablo Valc?rcel L?zaro <pablo.valcarcel1...@gmail.com>

Or simply try to nest as follows:

<IfModule mod_jk.c>
  JkMount /subsonic ajp13_worker
JkMount /subsonic/* ajp13_worker
<IfModule mod_security2.c>
  SecRuleRemoveById 330039
</IfModule>
</IfModule>

Kind regards,


2013/11/25 Jose Pablo Valc?rcel L?zaro <pablo.valcarcel1...@gmail.com>

In mod_security migration matrix table you will see features against
different mod_security versions:

https://github.com/SpiderLabs/ModSecurity/wiki/ModSecurity-Migration-Matrix

Ability to manage rules in Apache Scope locations
SecFilterRemove is now SecRuleRemoveById or SecRuleRemoveByMsg.
SecFilterImport is no longer supported.

So following that feature, I guess location directive you just can only
use to disable rules.

If you want to enable a specific rule, you should develop within
specific rules and disable in all domains you don?t need to check it.

Kind regards,


2013/11/25 Jose Pablo Valc?rcel L?zaro <pablo.valcarcel1...@gmail.com>

Hi.

I have seen rules to disabling by id as follows:

<IfModule security2_module>
  <Directory /local/home/username/example.net>
         SecRuleRemoveById 330039
  </Directory>
</IfModule>

Have you try with  apache Directory directive?

Kind regards,


2013/11/25 Phill Watkins <phill.watk...@gmail.com>

  Hi,

For some reason I'm struggling to to disable rules using
SecRuleRemoveById inside a Location or LocationMatch.

I can disable rules globally (which isn't ideal) so I know the
directive works but I don't know why Apache doesn't act upon the
Location/LocationMatch.

One of the applications on my web server that I'm trying to disable a
rule for is Subsonic. Subsonic requires Tomcat and is a connected to Apache
via the AJP connector module.

  I have successfully disabled one of the Atomicorp delayed rules in
the past like this:

<IfModule mod_jk.c>
JkMount /subsonic ajp13_worker
  JkMount /subsonic/* ajp13_worker
<Location /subsonic/upload.view>
SecRuleRemoveById 330792
  </Location>
</IfModule>

I am now trying to disable rule 960010 from the CRS for the entire
application because of too many false positives.

I have tried <Location /subsonic/>  as well as multiple regular
expressions for days but nothing works.

Here is an example from the audit log:

--35e37e6c-A--
[12/Nov/2013:12:19:05 +0000] UoIcuX8AAQEAAAJ3AQgAAAAA hidden 45509
hidden 443
--35e37e6c-B--
POST /subsonic/dwr/call/plaincall/nowPlayingService.getNowPlaying.dwr
HTTP/1.1
Host: hidden
Connection: keep-alive
Content-Length: 214
Origin: https://hidden
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36
(KHTML, like Gecko) Chrome/30.0.1599.114 Safari/537.36
Content-Type: text/plain
Accept: */*
Referer: https://hidden/subsonic/right.view?
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-GB,en-US;q=0.8,en;q=0.6
Cookie: player-656c6c6965=6; player-73727661646d=6;
JSESSIONID=088A746CDC6B4356A388E7C1D44EEE6A.ajp13_worker;
player-7068696c6c=9; compact_display_state=false

--35e37e6c-F--
HTTP/1.1 403 Forbidden
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 221
Keep-Alive: timeout=5, max=88
Connection: Keep-Alive
Content-Type: text/html; charset=iso-8859-1

--35e37e6c-H--
Message: Access denied with code 403 (phase 1). Match of "rx
^%{tx.allowed_request_content_type}$" against "TX:0" required. [file
"/etc/apache2/owasp-modsecurity-crs/activated_rules/modsecurity_crs_30_http_policy.conf"]
[line "64"] [id "960010"] [rev "2"] [msg "Request content type is not
allowed by policy"] [data "text/plain"] [severity "CRITICAL"] [ver
"OWASP_CRS/2.2.8"] [maturity "9"] [accuracy "9"] [tag
"OWASP_CRS/POLICY/ENCODING_NOT_ALLOWED"] [tag "WASCTC/WASC-20"] [tag
"OWASP_TOP_10/A1"] [tag "OWASP_AppSensor/EE2"] [tag "PCI/12.1"]
Action: Intercepted (phase 1)
Stopwatch: 1384258745437774 1085 (- - -)
Stopwatch2: 1384258745437774 1085; combined=426, p1=363, p2=0, p3=0,
p4=0, p5=63, sr=48, sw=0, l=0, gc=0
Producer: ModSecurity for Apache/2.7.5 (http://www.modsecurity.org/);
OWASP_CRS/2.2.8.
Server: Apache
Engine-Mode: "ENABLED"

--35e37e6c-Z--

I'd be grateful of any advice.

Thanks for your time.


_______________________________________________
Owasp-modsecurity-core-rule-set mailing list
Owasp-modsecurity-core-rule-set@lists.owasp.org

https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set

_______________________________________________
Owasp-modsecurity-core-rule-set mailing list
Owasp-modsecurity-core-rule-set@lists.owasp.org
https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.owasp.org/pipermail/owasp-modsecurity-core-rule-set/attachments/20131126/1d4c3f2a/attachment.html>

------------------------------

_______________________________________________
Owasp-modsecurity-core-rule-set mailing list
Owasp-modsecurity-core-rule-set@lists.owasp.org
https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set


End of Owasp-modsecurity-core-rule-set Digest, Vol 56, Issue 6
**************************************************************


_______________________________________________
Owasp-modsecurity-core-rule-set mailing list
Owasp-modsecurity-core-rule-set@lists.owasp.org
https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set

[Owasp-modsecurity-core-rule-set] if i have mod-security installed and owasp-modsecurity-core-rule-set, to i need to worry about vulnerability like CSRF?

Reply via email to