Waf challenge mode by sabban · Pull Request #162 · crowdsecurity/cs-haproxy-spoa-bouncer

sabban · 2026-06-03T09:21:11Z

Waf challenge mode

Mirrors the waf-challenge-mode feature from lua-cs-bouncer: - Add Challenge remediation type (between Captcha and Ban in severity) - internal/appsec: parse the JSON body on HTTP 403 responses; when action is "challenge" return AppSecChallengeData carrying body, status code, Content-Type, CSP, Cache-Control and cookies instead of discarding the body as before - pkg/spoa: update validateWithAppSec to return (Remediation, *AppSecChallengeData); on Challenge call injectChallengeVars which sets six SPOE transaction vars: challenge_body, challenge_status (int32), challenge_content_type, challenge_csp, challenge_cache_control, challenge_cookies (newline-joined) - lua/crowdsec.lua: handle remediation=="challenge" — reads those vars, sets status/body/Content-Type/CSP/Cache-Control/Set-Cookie and returns early, bypassing the ban/captcha content-negotiation block - config/crowdsec.cfg: raise max-frame-size to 262144 to accommodate the obfuscated JS payload (~150 KB) embedded in the challenge page - config/haproxy.cfg: add lua.crowdsec_handle rule for "challenge" Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

The SPOE frame size in dropmorepackets/haproxy-go is capped at 64 KB, but the challenge page (HTML + ~150 KB of obfuscated JS) exceeds that limit. Attempting to write the large body through the ActionWriter silently fills its buffer; subsequent writes (including the small remediation="challenge" update) also fail, leaving HAProxy with the stale "allow" value from the TCP-phase handler. Replace the SPOE-var approach with a dedicated challenge HTTP server: - pkg/spoa/challenge_server.go: new ChallengeServer that listens on a configurable TCP address (challenge_listen in the bouncer YAML). When HAProxy routes a challenge request to it, the server re-sends the original request to the AppSec engine (forwarding all headers + body, using X-Crowdsec-Real-Ip for the client IP), unwraps the JSON response, and writes the challenge page — HTML, JS, cookies, CSP — directly to HAProxy with no size restriction. - pkg/spoa/root.go: SPOE handler only writes remediation="challenge" (9 bytes, well within the frame limit); all challenge body logic is removed from the SPOE path. Challenge server is started as a goroutine inside Serve(). - pkg/cfg/config.go, cmd/root.go: expose challenge_listen config field and wire it through SpoaConfig.ChallengeAddr. - lua/crowdsec.lua: remove the challenge branch from crowdsec_handle (Lua no longer handles challenge; HAProxy routes to the dedicated backend instead). HAProxy config change: add a challenge_backend pointing to the bouncer's challenge HTTP server, and use_backend for remediation=="challenge". Tested end-to-end with CrowdSec waf-challenge-mode branch: - GET /challenge → 200 + CrowdSec challenge HTML (CSP + CT headers) - GET /pow-worker.js → 200 + PoW web worker JS (3.4 KB) - POST /submit (bad) → 200 + {"status":"failed"} - rem=challenge in HAProxy access log confirms SPOE var is set Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

…rver) internal/remediation/root_test.go (4 tests) - Challenge.String() returns "challenge" - FromString("challenge") round-trips back to Challenge - All Remediation values round-trip through String/FromString - Challenge is numerically between Captcha and Ban (ordering invariant that shouldRunAppSec and the take-the-max logic depend on) internal/appsec/root_test.go (15 tests) processAppSecResponse (white-box, same-package): - 200 → Allow, no challenge data - 403 with action=ban → Ban, no challenge data - 403 with empty body → Ban (safe default) - 403 with invalid JSON → Ban (safe default) - 403 with action=challenge, minimal payload → Challenge + data - 403 with action=challenge, full headers (CT/CSP/CC) + cookies → all fields - 401 → Allow + error - 500 → Allow + error - Unknown status → Allow + error ValidateRequest (httptest server): - AppSec returns 200 → Allow - AppSec returns 403 ban → Ban - AppSec returns 403 challenge → Challenge + all data fields - Client not configured → Allow, no error - Required CrowdSec headers are set on the upstream request - POST body is forwarded to AppSec pkg/spoa/challenge_server_test.go (10 tests, all via httptest.ResponseRecorder) - Challenge HTML page (CT, CSP, Cache-Control headers) - Single Set-Cookie forwarded from AppSec - Multiple Set-Cookie headers forwarded - AppSec returns allow → 200 empty body - X-Crowdsec-Real-Ip used as client IP - Falls back to RemoteAddr when header is absent - POST body forwarded to AppSec - X-Crowdsec-Real-Ip and X-Forwarded-For stripped before forwarding - PoW worker JS response (Content-Type: application/javascript) - Invalid submit response ({"status":"failed"}) Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

blotus

The approach with the 2nd HTTP server seems really fragile. This will cause multiple requests to the challenge page for the same initial request, which might trigger false positives because we have scenarios that track how many times a challenge page is requested.

If we absolutely have to keep this 2nd server because of the SPOA frame limitation, then we should find a way to make sure we only query the appsec only once.

blotus · 2026-06-09T10:10:01Z


    option      var-prefix      crowdsec
    option      set-on-error    error
+    option      max-frame-size  262144


This option does not seem to exist according to haproxy doc ?

blotus · 2026-06-09T10:10:46Z

-#appsec_url: ${APPSEC_URL}
-#appsec_timeout: ${APPSEC_TIMEOUT}
+## Global AppSec configuration
+appsec_url: ${APPSEC_URL}


Don't set an optional config here. Unset env vars are not replaced, so this will prevent the bouncer from starting.

blotus · 2026-06-09T10:10:50Z

-#appsec_timeout: ${APPSEC_TIMEOUT}
+## Global AppSec configuration
+appsec_url: ${APPSEC_URL}
+appsec_timeout: ${APPSEC_TIMEOUT}


blotus · 2026-06-09T10:10:54Z

+
+## Challenge HTTP listener
+## HAProxy routes remediation=challenge requests to this listener.
+challenge_listen: ${CHALLENGE_LISTEN}


blotus · 2026-06-09T10:13:00Z

+			Body:       parsed.UserBodyContent,
+			Cookies:    parsed.UserCookies,
+		}
+		if vals := parsed.UserHeaders["Content-Type"]; len(vals) > 0 {


Why single out specific headers ? The appsec can return any number of custom headers, just set everything that was returned by crowdsec

blotus · 2026-06-09T10:13:29Z

    end

+    -- Always disable cache for ban/captcha pages
+    reply:add_header("cache-control", "no-cache")


Those 2 calls are already done just before

blotus · 2026-06-09T10:13:52Z

+		Body:      body,
+	}
+
+	appSecCtx, cancel := context.WithTimeout(r.Context(), 5*time.Second)


Why hardcode to 5s ?
Timeout from the config should be reused here.

blotus · 2026-06-09T10:16:22Z

+		return
+	}
+
+	if rem != remediation.Challenge || challengeData == nil {


Because the request is actually forwarded twice to crowdsec, there's a chance the 2nd call returns a different remediation (eg, ban). In this case, we would just return a 200 to haproxy, which would just let the request passthrough (it would be blocked again afterwards, but we would still process it multiple times)

blotus · 2026-06-09T10:16:51Z

+	}
+
+	// Write response headers from AppSec
+	if challengeData.ContentType != "" {


Again, we shouldn't single out specific headers, everything that was returned by crowdsec should be set.

sabban and others added 8 commits June 2, 2026 17:14

add some default configuration

5d21e0b

Merge branch 'main' into waf-challenge-mode

43e09b5

lint

d532b8a

add some doc

02c2f92

improve doc

f0c0a7b

blotus requested changes Jun 9, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Waf challenge mode#162

Waf challenge mode#162
sabban wants to merge 8 commits into
mainfrom
waf-challenge-mode

sabban commented Jun 3, 2026

Uh oh!

blotus left a comment

Uh oh!

blotus Jun 9, 2026

Uh oh!

blotus Jun 9, 2026

Uh oh!

blotus Jun 9, 2026

Uh oh!

blotus Jun 9, 2026

Uh oh!

blotus Jun 9, 2026

Uh oh!

blotus Jun 9, 2026

Uh oh!

blotus Jun 9, 2026

Uh oh!

blotus Jun 9, 2026

Uh oh!

blotus Jun 9, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

sabban commented Jun 3, 2026

Uh oh!

blotus left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants