Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

exceptions for CRS rules syntax error

Rules
OSXBeta
2011-10-31
2013-06-12
  • OSXBeta
    OSXBeta
    2011-10-31

    Dear fellow ModSecs,

    i hope i hit the apropriate forum?

    i run ModSec 2.6.2 with CRS 2.2.3 (from SVN) and have a false positive while accessing a page via it's URL "http://myserver/index.php?page=Diva"

    with the following audit log:

    Message: Access denied with code 403 (phase 2). Pattern match "(?i:(?:(\"|'|`|\xc2\xb4|\xe2\x80\x99|\xe2\x80\x98)\\s*\\*.+(?:x?or|div|like|between|and|id)\\W*(\"|'|`|\xc2\xb4|\xe2\x80\x99|\xe2\x80\x98)\\d)|(?:\\^(\"|'|`|\xc2\xb4|\xe2\x80\x99|\xe2\x80\x98))|(?:^+( …" at ARGS:page.        
    Message: Audit log: Failed to lock global mutex: Permission denied
    Action: Intercepted (phase 2)
    Apache-Handler: php5-script
    Stopwatch: 1319547874541608 65643 (- - -)
    Stopwatch2: 1319547874541608 65643; combined=63699, p1=1661, p2=61784, p3=0, p4=0, p5=196, sr=149, sw=58, l=0, gc=0
    Response-Body-Transformed: Dechunked
    Producer: ModSecurity for Apache/2.6.2 (http://www.modsecurity.org/); core ruleset/2.2.3; core ruleset/2.2.3.
    Server: Apache
    WebApp-Info: "default" "5pq1kijivuga8j2im6ohlr2ga6" ""

    Accordingly i would like to make an exception for the QUERY_STRING but always am prompted with one of these errors:

    "Error creating rule: Variable QUERY_STRING does not support parameters."
    "SecRule takes two or three arguments, rule target, operator and optional action list"

    depending on which of the following attempts were made (i know not all make sense, it's purpose is to catch the syntax scheme…):

    SecRule REQUEST_COOKIES|REQUEST_COOKIES_NAMES|REQUEST_FILENAME|ARGS_NAMES|ARGS|!QUERY_STRING "!@streq Diva"|XML:/* …
    SecRule REQUEST_COOKIES|REQUEST_COOKIES_NAMES|REQUEST_FILENAME|ARGS_NAMES|ARGS|QUERY_STRING "!@streq Diva"|XML:/* …
    SecRule REQUEST_COOKIES|REQUEST_COOKIES_NAMES|REQUEST_FILENAME|ARGS_NAMES|ARGS|QUERY_STRING !@streq Diva|XML:/* …
    SecRule REQUEST_COOKIES|REQUEST_COOKIES_NAMES|REQUEST_FILENAME|ARGS_NAMES|ARGS|!QUERY_STRING:Diva|XML:/* …
    SecRule REQUEST_COOKIES|REQUEST_COOKIES_NAMES|REQUEST_FILENAME|ARGS_NAMES|ARGS|QUERY_STRING:!Diva|XML:/* …
    SecRule REQUEST_COOKIES|REQUEST_COOKIES_NAMES|REQUEST_FILENAME|ARGS_NAMES|ARGS|QUERY_STRING:page=Diva|XML:/* …
    SecRule REQUEST_COOKIES|REQUEST_COOKIES_NAMES|REQUEST_FILENAME|ARGS_NAMES|ARGS|QUERY_STRING:"page=Diva"|XML:/* …
    SecRule REQUEST_COOKIES|REQUEST_COOKIES_NAMES|REQUEST_FILENAME|ARGS_NAMES|ARGS|QUERY_STRING "page=Diva"|XML:/* …
    SecRule REQUEST_COOKIES|REQUEST_COOKIES_NAMES|REQUEST_FILENAME|ARGS_NAMES|ARGS|QUERY_STRING page=Diva|XML:/* …
    SecRule REQUEST_COOKIES|REQUEST_COOKIES_NAMES|REQUEST_FILENAME|ARGS_NAMES|ARGS|QUERY_STRING (page=Diva)|XML:/* …

    and many more. This all with a rule that is totally unmodified otherwise (as is the entire ruleset).

    Another attempt for an exception via:

    SecRule REQUEST_COOKIES|REQUEST_COOKIES_NAMES|REQUEST_FILENAME|ARGS_NAMES|ARGS|!ARGS:page|XML:/* …

    is syntactially accepted, but would be too loose in my view.

    I'm lost now and suspect i missed some fundamental point attempting to understand the syntactical needs…

    Could you please kick me into the right direction?

    Many thanks in advance

    (P.S.:I know it's wrong to customize the original rule and will drop this habit as soon i successfully found the right exception-code, i do this here just for ease…)

     
  • OSXBeta
    OSXBeta
    2011-11-01

    Dear list,

    i'd like to refine the problem announced yesterday:

    In the meantime  i created a custom rules-definition file under /activated-rules called "modsecurity_crs_99_custom.conf", and used the "SecRuleUpdateTargetById" method to manage exceptions in order to do it the proper way.

    Key point now is: the single and only target that i managed to facilitate for stating the exception rule still is ARGS ("!ARGS=Diva"), while any attempt to formulate the exception using other targets (e.g. REQUEST_FILENAME, REQUEST_URI) failed, among them:

    #SecRuleUpdateTargetById 981243 !QUERY_STRING "^page|^Diva$"
    #SecRuleUpdateTargetById 981244 !QUERY_STRING "^page|^Diva$"
    #SecRuleUpdateTargetById 981248 !QUERY_STRING "^page|^Diva$"

    #SecRuleUpdateTargetById 981243 !QUERY_STRING "^Diva$"
    #SecRuleUpdateTargetById 981244 !QUERY_STRING "^Diva$"
    #SecRuleUpdateTargetById 981248 !QUERY_STRING "^Diva$"

    #SecRuleUpdateTargetById 981243 !QUERY_STRING "Diva"
    #SecRuleUpdateTargetById 981244 !QUERY_STRING "Diva"
    #SecRuleUpdateTargetById 981248 !QUERY_STRING "Diva"

    #SecRuleUpdateTargetById 981243 REQUEST_URI "^/index.php$"
    #SecRuleUpdateTargetById 981244 REQUEST_URI "^/index.php$"
    #SecRuleUpdateTargetById 981248 REQUEST_URI "^/index.php$"

    #SecRuleUpdateTargetById 981243 !ARGS_NAMES:Diva
    #SecRuleUpdateTargetById 981244 !ARGS_NAMES:Diva
    #SecRuleUpdateTargetById 981248 !ARGS_NAMES:Diva

    where the original request still is "http://myserver/index.php?page=Diva".

    The example above are only some variations.

    I always startet with the syntax-recommendation as stated in the online Reference-Manual for 2.6.1, but they also failed…

    Hence i start wondering: is it thinkable, that the other targets may not be updateable like this?

    Still heavily appreciating any slightest hint:

    Best so far