corazawaf / coraza-caddy

OWASP Coraza middleware for Caddy. It provides Web Application Firewall capabilities
https://www.coraza.io/
Apache License 2.0
355 stars 41 forks source link

Caddy handle_errors not working with v2 #88

Closed skixmix closed 1 month ago

skixmix commented 1 year ago

Hello,

Whilst working with the most recent version (v2) of this module, I observed that the handle_errors directive is no longer functional with the 403 code initiated by the WAF. However, in the v1.2.2 version of the module, this feature operates correctly.

My configuration (the commented parts are used in v2):

    # Error handling
    handle_errors {
        reverse_proxy http://localhost:5001 {
            respond "Hello"
        }
    }

        coraza_waf {
            # load_owasp_crs
            # directives `
            include /waf/coraza/coraza.conf-recommended
            include /waf/coreruleset/crs-setup.conf.example
            include /waf/coreruleset/rules/*.conf
            # `
        }

In version 1.2.2, the activation of a rule prompts the display of the "Hello" message. However, in version 2, the standard browser's 403 page is presented instead.

Thank you, Simone

jptosso commented 1 year ago

@jcchavezs I can confirm it used to work, but something changed in how we handle errors. @jcchavezs @M4tteoP

M4tteoP commented 3 months ago

Am I wrong to say that this issue can be closed? https://github.com/corazawaf/coraza-caddy/pull/164 added handle_errors to the example and to the readme 🤔

BurningDog commented 3 months ago

I wasn't able to get handle_errors working following the example (tried both options). Caddy v2.8.4 and Coraza github.com/corazawaf/coraza-caddy@master

This may be because instead of putting coraza_waf and handle_errors inside :8080 { as per the example I'm using route { following an older version of the API Platform config - getting this error:

Error: adapting config using caddyfile: parsing caddyfile tokens for 'route': handle_errors directive returned something other than an HTTP route or subroute:

The newer version specifies {$SERVER_NAME:localhost} { instead of route {

Caddy accepts this, however when requesting /admin I get the expected 403 response but no expected HTML response body or X-Blocked header.

github-actions[bot] commented 2 months ago

This issue has been open 30 days waiting for feedback. Remove the stale label or comment, or this will be closed in 14 days.

github-actions[bot] commented 1 month ago

This issue was closed because it has been inactive for 14 days since being marked as stale.