search

envoyproxy / envoy

Cloud-native high-performance edge/middle/service proxy
https://www.envoyproxy.io
Apache License 2.0
24.92k stars 4.8k forks source link

Parsing args in URIs and request body and matching them in the Generic Matching Engine #24615

Open tzuryby opened 1 year ago

tzuryby commented 1 year ago

The Ability to Parse Args Is Essential for a WAF

We, Curiefense maintainers, willing to extend Generic Matching so it can act as de-facto Native WAF for Envoy users.

The vision is simple: Curiefense users will be able to activate the security policy in a given runnign environemtn, using generic-matching, since the rules will be renderd as such.

We have work on a PoC that already has the capabilitied to do so (attached yaml), yet, without the ability to parse and match entries in the queryString and request body, the WAF cannot be considered useful.

The table below describe the current capabilities and the missing ones, and tagged them with their priority (P1..P4)

Capabilities map

Function y/n Remarks
Match headers Yes
Match CIDR Yes
Query string args No P1
Body args No P1 form-url-encoded and multipart
JSON body No P2 nested structures
GraphQL body No P3
XML body No P4
Geo, ASN, IP INfo No Require MaxMind integration

So far, we have added support for the following Curiefense policy generation

Curiefense team involved:

wbpcode commented 1 year ago

cc @snowp

wbpcode commented 1 year ago

I am not sure if it's good choice to implement WAF by the generic matching. The generic matching is complex enough for now. Will it be better if we implement it as a independent filter?

But we are open to this question. A more detailed proposol would be welcome.

tzuryby commented 1 year ago

@wbpcode thanks for your feedback.

The suggestion to this path (basic WAF implemented on top of generic matching) was actually made by @mattklein123.

We will indeed come with a more detailed proposal soon. Meanwhile, this PR, which has some feedback, is in motion.

mattklein123 commented 1 year ago

I am not sure if it's good choice to implement WAF by the generic matching. The generic matching is complex enough for now. Will it be better if we implement it as a independent filter?

The idea is to build a WAF filter where the actions are WAF actions specific to that filter. But for matching I think it's fine to have matching on other types of things which is also relevant to other parts of Envoy?

aguinet commented 1 year ago

FYI https://github.com/envoyproxy/envoy/pull/24627 should be close to be merged for "Query string args"