[Owasp-modsecurity-core-rule-set] @within in crs_30 and similar (restricted extensions)

modsec at enosis.com modsec at enosis.com
Tue May 25 17:41:55 EDT 2010


I suspect your problem is related to the earlier-reported 

The @within operator is misnamed for modsec's semantics.
Or the documentation could be clearer. Or both.

@within is (essentially) a simple linear string search: 
your argument ".do" was found in "foo .dos bar" IOW, the
operation is what is more usually called "string match".
Perhaps it should be called "@sm".

Because modsec provides "set" semantics ("Collections") and
the appearance of tokenized input (such as your space-delimited
%{tx.restricted.extensions} it's sensible for you (and by
the evidence, the crs authors) to believe that @within will
understand the context and magically switch between strings 
and tokens. Maybe it c/should in some cases.

An operator like @containsWord does match on locale alphanum_ 
tokens, but on the reverse of match and target for the rule 
variable and operator argument.

@within is not, however, token based. So crs_30 rules like 
960035 and 960038 will unexpectedly match even when the 
operation appears 'obviously' token-based. (e.g., on 960038, 
the ordinary and acceptable "Connection" header will be found 
@within "Proxy-Connection ...").

One might think @pm would be a workable substitute for the 
rule 960038 case, but @pm apparently doesn't perform %{macro} 
substitution for its entire argument (@2.5.12). In the case 
of this rule, tho, the simple workaround is to use @pm and 
just put the restricted headers list directly into the rule.

But in your case, with the longer list for rule 960035, @pm is 
out. As a workaround, perhaps use @pmFromFile. Just move the 
list to a one-per-line file of your making.

Let us know, please.


> Date: Tue, 25 May 2010 11:25:47 -0400
> From: James Muse <jfmtopnettlc at gmail.com>
> Subject: [Owasp-modsecurity-core-rule-set] restricted extensions
> To: owasp-modsecurity-core-rule-set at lists.owasp.org
> Message-ID:
> 	<AANLkTinrJIIQl9xGXL9jlrdSbxvJZv693oshxbzS2n-r at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
> Moderator,
> I am having an issue with the restricted_extensions variable and core rule
> file modsecurity_crs_30_http_policy.conf line 87.  One of my applications
> uses the file extension .do and there appears to be a .dos in the
> restricted extensions list.. The audit log shows the extension as [data
> ".do"]  do is not in the restricted_extension list .dos is.  When I remove
> .dos from the restricted extensions I no longer have this issue.  May be I
> don't understand the within operator but do is no the same as dos.  Is there
> a bug here or am I doing something wrong?  I think I would like to keep dos
> and an extension I would like to block but it appears to be causing and
> issue with my application which uses .do
> James

More information about the Owasp-modsecurity-core-rule-set mailing list