SecAuditLogFormat JSON seems to be ignored

[superstes]

Summary

The documentation shows an option that allows us to format the Audit-Logs in JSON: https://coraza.io/docs/seclang/directives/#secauditlogformat

But when put into coraza.conf and restating the service - nothing changes. The logs are still formatted the same.

Basic example

I am using corazawaf/coraza-spoa with HAProxy.

Logs look like this: {"level":"warn","time":"2024-09-20T23:18:55+02:00","message":"[client \"::ffff:95.214.55.x\"] Coraza: Warning. Host header is a numeric IP address [file \"/etc/coraza-spoa/coreruleset/rules/@owasp_crs/REQUEST-920-PROTOCOL-ENFORCEMENT.conf\"] [line \"1772\"] [id \"920350\"] [rev \"\"] [msg \"Host header is a numeric IP address\"] [data \"159.69.187.x\"] [severity \"warning\"] [ver \"OWASP_CRS/4.0.0-rc2\"] [maturity \"0\"] [accuracy \"0\"] [tag \"application-multi\"] [tag \"language-multi\"] [tag \"platform-multi\"] [tag \"attack-protocol\"] [tag \"paranoia-level/1\"] [tag \"OWASP_CRS\"] [tag \"capec/1000/210/272\"] [tag \"PCI/6.5.10\"] [hostname \"::ffff:159.69.187.x\"] [uri \"/\"] [unique_id \"FMPGEMUVBOHBCEMH\"]"}

This way the coraza-spoa 'wrapper' uses JSON format, but the core log is still a string :(

I would expect all the fields inside message being separate json key-value pairs.

Used versions:

• coraza 3.2.1
• coraza-spoa https://github.com/corazawaf/coraza-spoa/tree/rewrite

Log callback: https://github.com/corazawaf/coraza-spoa/blob/rewrite/internal%2Fapplication.go#L330

Motivation

JSON is much easier to parse than the legacy ModSecurity format.
Log systems like Graylog can parse JSON natively & easily. That is very convenient - especially as such security-logs are very important to process.

From what I've read into the source - this is where the logs are written: https://github.com/corazawaf/coraza/blob/main/internal/corazarules/rule_match.go#L238

I've found a proxy-wasm issue/pr that referenced it: corazawaf/coraza-proxy-wasm#255, corazawaf/coraza-proxy-wasm#263

Also related to this coraza-caddy issue: corazawaf/coraza-caddy#20

Related: corazawaf/coraza-spoa#91

Maybe it's just a user-error. Please correct me if I got something wrong.

[superstes]

BTW: I'm open to contribute to the project.

[superstes]

Nevermind - with the vanilla source it works.
Example:
{"transaction":{"timestamp":"2024/09/21 06:04:14","unix_timestamp":1726891454675671458,"id":"GbVAToHGyTBJhdMgnas","client_ip":"[::1]","client_port":41912,"host_ip":"","host_port":0,"server_id":"localhost:8090","request":{"method":"GET","protocol":"HTTP/1.1","uri":"/q=%3Cscript%3Ealert(1)%3C/script%3E","http_version":"","headers":{"accept":["text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7"],"accept-encoding":["gzip, deflate, br, zstd"],"accept-language":["en-US,en;q=0.9"],"cache-control":["no-cache"],"connection":["keep-alive"],"cookie":["csrftoken=Aj6G8hjhmmicBDUhNqOxdEu6NS7mRE4G; sessionid=kgpp4dxzc1ciagz9u1u3ndgbp91m62qt"],"host":["localhost:8090"],"pragma":["no-cache"],"sec-ch-ua":["\"Not;A=Brand\";v=\"24\", \"Chromium\";v=\"128\""],"sec-ch-ua-mobile":["?0"],"sec-ch-ua-platform":["\"Linux\""],"sec-fetch-dest":["document"],"sec-fetch-mode":["navigate"],"sec-fetch-site":["none"],"sec-fetch-user":["?1"],"upgrade-insecure-requests":["1"],"user-agent":["Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36"]},"body":"","files":null},"response":{"protocol":"","status":0,"headers":{},"body":""},"producer":{"connector":"","version":"","server":"","rule_engine":"On","stopwatch":"1726891454675671458 3042842; combined=2717908, p1=155163, p2=2552161, p3=0, p4=0, p5=10584","rulesets":null}}}

Looks like the error-callback inside the haproxy-spoa is seponsible.

[superstes]

Also - seems I've mixed-up error and audit logs as there is no mention of changing config/format for error logs (aka basic block-logs)
Related to: #856