Giters

memorysafety / river

This repository is the home of the River reverse proxy application, based on the pingora library from Cloudflare.

Home Page:https://www.memorysafety.org/initiative/reverse-proxy/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

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

dune73 opened this issue · comments

commented

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.

commented

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.

commented

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.

commented

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!

commented

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.

commented

Will do, thanks!

commented

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