coraza icon indicating copy to clipboard operation
coraza copied to clipboard

Make phases first-class citizens

Open fzipi opened this issue 3 years ago • 2 comments

Summary

Phases should be extendable. The initial setup could be the "classic modsecurity" with the 5 well-known phases, but we are restricting integrators to add their own phases.

Additionally, the algorithm for getting the next phase should be changeable. This allows us again more flexibility for handling requests/responses.

Requirements*

  • move phases to a top level directory, like operators, transformations, etc.
  • ParseRulePhase should be extendable.
  • implement a NextPhase or similar that receives a phase and returns the next phase that must be run. Or maybe an action and a phase (e.g. allow?)?
  • the implementation can be a simple ordered collection of some type that is easy to alter. We can add methods for executing before or after some known phase.
  • add all the scaffolding to make the classic 1-5 phases the default
  • rewrite tests to match changes

Motivation

  • Why are we doing this? This will get things more flexible for everyone.
  • What use cases does it support? Integrators might want to add their own logic before regular phases, to match their own use cases.
  • What is the expected outcome? Phases are first-class citizens in coraza.

fzipi avatar Sep 04 '22 12:09 fzipi

While I think it makes sense the proposal I would like to know more about the use cases

Integrators might want to add their own logic before regular phases, to match their own use cases.

Sounds too broad, is there any integrator willing to do this ATM? What are their use cases? Any example?

I think concrete use cases would help us to model the requirements and the implementation in a better way.

jcchavezs avatar Sep 04 '22 19:09 jcchavezs

I don't know of any integrator wanting to do this.

But I think we should provide reasonable defaults and a way for extending that is not there now.

Possible use cases:

  • As an integrator, I would like to block as soon as possible, early in the phase chain. The earlier we can block is after evaluating Phase 1, but we could block as soon as IPs for the client are known after ProcessConnection for example. There is no particular phase to do this. It will help prevent DoS at layer 4, for example.
  • As an integrator, I would like to add a new phase between phases 2 and 3 that executes my local methods. This might include extensions to prevent:
    • compromised passwords are being used on a login page
    • credential stuffing is repeatedly used for users created on my site
    • (insert other uses)

If you let me I can just create use cases all day 🤣

fzipi avatar Sep 05 '22 12:09 fzipi

This issue is stale because it has been open for 30 days with no activity.

github-actions[bot] avatar Oct 08 '22 03:10 github-actions[bot]

This issue was closed because it has been inactive for 14 days since being marked as stale.

github-actions[bot] avatar Oct 22 '22 03:10 github-actions[bot]