New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ModSecurity 3.0 fails with ctl:requestBodyProcessor=URLENCODED #1797

Closed
dune73 opened this Issue Jun 5, 2018 · 10 comments

Comments

Projects
None yet
4 participants
@dune73

dune73 commented Jun 5, 2018

Enforcing URLENCODED body processor results in startup failure:

Expecting an action, got: ctl:requestBodyProcessor=URLENCODED"

Enforcing JSON body processor works alright.

CRS 3.1 is going to have a rule that enforces the URLENCODED body processor when there is a body, but no content-type. Eventually, we would like to have this rule in the recommended-rules, but for the time being, we plan to introduce it into CRS 3.1 as a bypass prevention.

With this bug / missing feature, modsec 3.0 fails to load the upcoming CRS 3.1.

@dune73 dune73 changed the title nginx 3.0 fails with ctl:requestBodyProcessor=URLENCODED ModSecurity 3.0 fails with ctl:requestBodyProcessor=URLENCODED Jun 5, 2018

@victorhora victorhora self-assigned this Jun 5, 2018

@victorhora victorhora added this to the v3.0.3 milestone Jun 6, 2018

@victorhora

This comment has been minimized.

Member

victorhora commented Aug 23, 2018

Solved as of f999f54 and aa158ce

@victorhora victorhora closed this Aug 23, 2018

@dune73

This comment has been minimized.

dune73 commented Aug 23, 2018

Thank you. Any plans when you will release?

@HazCod

This comment has been minimized.

HazCod commented Sep 11, 2018

Is there any workaround for this? I am running version 3.0.2.

@victorhora

This comment has been minimized.

Member

victorhora commented Sep 11, 2018

hey @HazCod,

This is already fixed as of f999f54 and aa158ce. You can merge these commits to your code to get the fix. It will be merged prior to 3.0.3 release.

EDIT: Sorry, these commits are actually already merged into the main branch! :P So yes, cloning from master should give you the fix :)

@victorhora

This comment has been minimized.

Member

victorhora commented Sep 11, 2018

Hey @dune73 we are working on some important issues to cook the release. Should be soon :)

Have a look at #1892 (comment).

Cheers

@dune73

This comment has been minimized.

dune73 commented Sep 11, 2018

So 3.0.3 is imminent? We would hate to release CRS 3.1 with ModSec3 listed under KNOWN_BUGS.

@victorhora

This comment has been minimized.

Member

victorhora commented Sep 11, 2018

So 3.0.3 is imminent?

No, not really imminent as @zimmerle pointed out at #1892 (comment) we would like to fix/close most (if not all) issues under https://github.com/SpiderLabs/ModSecurity/milestone/12 prior to 3.0.3 release, which can take a couple of weeks.

We would hate to release CRS 3.1 with ModSec3 listed under KNOWN_BUGS

This shouldn't be the case. From what I can tell, CRS 3.0, 3.1 and 3.2 should all be supported since commits f999f54 and 764a2e4. See #1876 (comment)

@zimmerle

This comment has been minimized.

Member

zimmerle commented Sep 11, 2018

So 3.0.3 is imminent? We would hate to release CRS 3.1 with ModSec3 listed under KNOWN_BUGS.

If the bugs are opened in the community and within the milestone tag, it is likely to be closed.

@dune73

This comment has been minimized.

dune73 commented Sep 12, 2018

You have merged the fix for this issue here. But the 3.0.3 release is pending.

CRS 3.1 is meant to come out in a couple of weeks. It depends on this fix when running ModSec3. So CRS 3.1 will not run with the latest stable release of ModSec3. It will depend on a fix in dev. And we will need to cover this under KNOWN_BUGS in CRS 3.1. And I would rather avoid this.

@HazCod

This comment has been minimized.

HazCod commented Sep 12, 2018

Just a heads up, I'm still encountering an issue with latest CRS and v3/master modsecurity in the DDOS ruleset: #1742 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment