updates to CRS v4.0.0-rc2, sets equal BodyLimits in default configs

[M4tteoP]

This PR:

• Updates to CRS v4.0.0-rc2
  • Updates accordingly ftw tests. Notably two new tests will require extra care: 934131-5, 934131-7.
• Deprecates @crs-setup-demo-conf in favour of @crs-setup-conf. @crs-setup-conf is already meant to be specifically edited for coraza-proxy-wasm (early_blocking enabled), two config files providing the same configuration would just be confusing.
  • @demo-conf has some differences compared to the original coraza.conf (first of all enabling the Engine and not keeping it in DetectionOnly mode). This PR does not deprecate it.
• Sets RequestBodyLimit equal to BodyInMemoryLimit. As stated in Coraza itself: TinyGo MemoryLimit should be equal to Limit

[M4tteoP]

I think SecRequestBodyNoFilesLimit is not implemented Coraza side, we should at least comment it out, not letting users think that it is enforced.

[jcchavezs]

Is this change connected to the 1gb?

[M4tteoP]

No, it is about:

• Sets RequestBodyLimit equal to BodyInMemoryLimit. As stated in Coraza itself: TinyGo MemoryLimit should be equal to Limit

Not being able to split the request between memory and then into a file after a certain limit, for coraza-proxy-wasm the two limits should be the same

[M4tteoP]

Elaborating better the following point:

• Sets RequestBodyLimit equal to BodyInMemoryLimit. As stated in Coraza itself: TinyGo MemoryLimit should be equal to Limit

The issue currently is that in the default configuration, we provide:

• BodyLimit: 13107200 (12,5Mib)
• Memorylimit: 131072 (128 Kib)

Sending a request >Memorylimit leads to reaching the memoryLimit reached while writing error followed by Failed to write request body. It ends up with return types.ActionContinue. Therefore, lots of logs are generated, but no action is enforced even if by default we have SecRequestBodyLimitAction Reject.

I think that:

• It is something that we could also address upstream by enforcing the two values to be the same if no FS can be used, but first of all, we should stick with the recommendations that are about setting TinyGo MemoryLimit equal to BodyLimit.
• We have to find a proper value to be set for coraza-proxy-wasm in the default configuration. If expanding Memorylimit up to the body limit 13107200 (12,5Mib) is too much, I think that also vice-versa (with the default config Reject any request bigger than 128Kib) is too low

[M4tteoP]

I aligned the limits to the lower threshold: both BodyLimit and Memorylimit are now 131072 (this is effectively the level we are already enforcing). I also moved the body process policy to ProcessPartial. It should allow to avoid service degradation during the initial integration of Coraza. About it, I extended the Readme warning the users to be fully aware of the configurations they are using and pointing to the CRS resources about tuning a CRS deployment.

[M4tteoP]

PTAL @jcchavezs @anuraaga. Also, because the default config and embedded rules changed, I would release 0.4 once this PR gets merged. Are you okay with it?

[M4tteoP]

Just reworded the two failing tests linking to the broader discussion in the Coraza repo. I'm going to merge and tag! 🚀