Gin Framework doesn't work from Coraza V3

[Lexterl33t]

Hi you've removed the tx.ProcessRequest, which directly took the Request object from net/http as a parameter, which means that your library isn't adapted to gin. Would it be possible to add the possibility of adding a custom Request in order to remedy this problem?

[M4tteoP]

Hi, I don't know much about Gin, but wouldn't be possible consume Coraza as a http/middleware like in the http-server example?

Edit: it is not 😕

[anuraaga]

Unfortunately frameworks like Gin and others define their own handler / middleware interfaces and don't use http.Handler.

We currently have http middleware with this private method for handling an http.Request

https://github.com/corazawaf/coraza/blob/main/http/middleware.go#L26

It could be reasonable to expose that for processing a request, however the bigger challenge is processing a response, in that middleware we also wrap the response writer to be able to process it, which is significantly more complex

https://github.com/corazawaf/coraza/blob/main/http/interceptor.go

Since Gin has a custom response type, we couldn't provide a drop-in helper for that in the http package I think as it would require gin-specifics. I don't know if we would want to expose help with only the request side without the response side.

What does come to mind is exposing something like this

// Handle processes the HTTP request applying the WAF rules. We replace the http.ResponseWriter,
// and may need to replace the request in the future, so it is important to make sure next does not ignore 
// the parameters passed to it.
func Handle(waf coraza.WAF, w http.ResponseWriter, r *http.Request, next http.HandlerFunc) {

Then in gin middleware would still need to have its own custom gin.ResponseWriter but maybe it's not that complicated when using the http.ResponseWriter we pass into next. Would this be enough with the Gin usecase? I think it could be reasonable to expose.

[StephanSchmidt]

Wanted to use Coraza with Echo by adapting the Gin example. Stumbled across the same problem with missing request handle method.

On that topic of integration:

I'm new to the idea of WAFs, I understand why a WAF scans the Request input, why does it need to parse the response of my app?

[M4tteoP]

I understand why a WAF scans the Request input, why does it need to parse the response of my app?

It might be possible to prevent data leakages matching common patterns like common errors and warnings that are printed in the response when the database/application is not behaving as intended. So, even if for any reason the malicious payload went through, there is another enforcement point where it is possible to drop the response and effectively deny the attack.

In order to see some rules dealing with the response, you may go through the rule files starting with RESPONSE-* in the CRS repo or even just looking at files like sql-errors.data.

[StephanSchmidt]

Thanks that helped!

Now I hope even more that Coraza will expose an API so Gin/Echo/Fiber users on Go can use it in their applications as a middleware.