Skip to content
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

Feature Request: WAF functionality leveraging OWASP CRS, implemented and enabled by default #8

Open
dune73 opened this issue Mar 18, 2024 · 6 comments
Labels
F-RequestPathCtl Functionality relating to the Request Path Control for modification and filtering
Milestone

Comments

@dune73
Copy link

dune73 commented Mar 18, 2024

Creating this feature request was recommended by @drcaramelsyrup at

cloudflare/pingora#31 (comment)

OWASP CRS currently runs on the following WAF engines:

  • OWASP ModSecurity v2
  • OWASP ModSecurity v3
  • OWASP Coraza

Commercial integrations are done via custom implementations of the rule language. This includes the Cloudflare setup.

If a new open source Reverse Proxy is created, then giving it WAF functionality based on the de facto standard rule set from the beginning would be useful.

@mcpherrinm
Copy link

I think WAF type functionality will be a great use of the wasm extensibility planned for River: Rule sets could be compiled into wasm to reject requests.

@fzipi
Copy link

fzipi commented Mar 18, 2024

This should basically alter the proposed design. Adding a new Filters between Listeners and Connectors should do the trick. Then a WAF is just another filter in the chain.

@jamesmunns jamesmunns added the F-RequestPathCtl Functionality relating to the Request Path Control for modification and filtering label Mar 25, 2024
@jamesmunns jamesmunns added this to the Backlog milestone Mar 25, 2024
@jamesmunns
Copy link
Collaborator

Hey @dune73, thanks for opening this issue! There was definitely interest in supporting WAF functionality in River during the initial planning discussions, and I agree it would be great to have.

I think @mcpherrinm makes a reasonable point, this might be easier to iterate on once we have the WASM-based scripting environment setup working, though that will come a little later after we have basic operation working.

@fzipi I'm not sure if I totally follow. I see this as falling under the Request Path Control stage, providing filtering and state tracking.

I expect to come back to this later, but I believe we'd need to:

  • Look at the CRS to ensure that we have the ability to check the criteria on the ruleset
  • Ensure that we have suitable "hooks" at appropriate stages to provide filtering
  • If we want to add this BEFORE WASM is available: add configuration options for this, implemented as an optional compiled-in feature
  • If we want to add this AFTER WASM is available: ensure that the WASM interface has access to all necessary observation and filtering features identified above

Thanks all for the feedback!

@dune73
Copy link
Author

dune73 commented Mar 25, 2024

Thank you @jamesmunns. I do not really have spare time to contribute here in my volunteer time capacity, but if you have any questions about CRS or especially input on how to provide a successful integration, then please get in touch.

@jamesmunns
Copy link
Collaborator

Will do, thanks!

@fzipi
Copy link

fzipi commented Mar 25, 2024

Got it now, I see that it is totally under that stage. Awesome. Ping me if you need anything.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
F-RequestPathCtl Functionality relating to the Request Path Control for modification and filtering
Projects
None yet
Development

No branches or pull requests

4 participants