The payload is not correct. The initial payload is something like "blurb=A 
stitch in time saves nine", but what comes through is just "ime saves nine", 
and mod security tries to interpret that as one of  the argnames instead of " 
blurb". I'm pretty sure this isn't by design.

from my phone

On May 13, 2016 2:14 PM, Christian Folini <christian.fol...@netnea.com> wrote:
Colin,

I thought I would give this a try.

Not sure, I understand you correctly though. I think your original
payload is:
Blurb=rc+is+knowledgeable%2C+experienced%2C+empathetic%2C+and+kind...

And then ModSec seems to strip Blurb in the request body and you
end up with a very long variable name starting with rc... and no value.

Then a 2nd variable named Control from the end of your payload.

Whatever happens with the payload, the CRS don't like it. The
score is between 45 and 53 depending of the version and the
variable name Blurb being present or not.

But in fact, I get the variable name and all is just fine
(Apache 2.4.18, ModSec 2.9.1 on Ubuntu 14.04)

SecRule &ARGS:Blurb ".*"        "id:1001,phase:2,pass,log,capture,msg:'# of 
variables named Blurb: %{MATCHED_VAR}'"
SecRule ARGS:Blurb ".*"         "id:1002,phase:2,pass,log,capture,msg:'Variable 
Blurb: %{MATCHED_VAR}'"

$> curl "$(cat payload)" localhost/index.html

-> results in
  1001 ARGS          # of variables named Blurb: 1
  1002 ARGS:Blurb    Variable Blurb: rc is knowledgeable, experienced...

Please confirm the payload is correct or submit the correct payload.

If you have a different behaviour on Windows/ModSec, then yes, this is
probably a bug.

Ahoj,

Christian





On Tue, May 10, 2016 at 05:37:51PM +0000, Colin MacAllister wrote:
> Resurrecting this. I’m sure the arg value is being passed from the browser 
> intact, because it show up in the database in one piece, and because Firefox 
> reports that it is being sent in the Developer/Network view.
>
> I’ve attempted switching back from anomaly scoring mode to 
> one-strike-you’re-out, and am still getting the problem. Should I being 
> having this conversation with whoever puts out the Windows port of 
> modsecurity?
>
> Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10
>
> From: Colin MacAllister<mailto:cmacallis...@probono.net>
> Sent: Thursday, May 5, 2016 2:39 PM
> To: OWASP List<mailto:owasp-modsecurity-core-rule-set@lists.owasp.org>
> Subject: [Owasp-modsecurity-core-rule-set] arg name not resolving for large 
> post value
>
> Hi, all,
>
> As I fine-tune my CMS not to bark at me for valid traffic, I’ve come upon the 
> following problem. When a rule matches (in anomaly scoring mode, haven’t 
> tested the other way) sometimes part of the value of the argument the will 
> come through as the argument name, not the name itself, in this case, “Blurb.”
>
> ARGS_NAMES:rc is knowledgeable, experienced, empathetic, and kind… [followed 
> by a chunk of the rest of the arg value]
>
> I checked it in the inspector, and indeed the ARG_NAME should be “Blurb”. As 
> it is coming through, of course, it is impossible to check for, as it is 
> variable. It might be possible to whitelist the last part of the URL path, 
> but I’d rather not.
>
> Have I found a bug? See the snippet from the audit log I attached to this 
> email.
>

> _______________________________________________
> 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


--
mailto:christian.fol...@netnea.com
http://www.christian-folini.ch
twitter: @ChrFolini
_______________________________________________
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

Reply via email to