Major security fix: The proof-of-work challenge was previously
just trusting the client, allowing bots to bypass it by submitting
random nonces without doing any work.
Changes:
- Added proper server-side SHA-256 verification using resty.sha256
- Server now verifies that sha256(challenge + nonce) has the
required number of leading zeros based on pow_difficulty
- Bots must now actually compute the proof-of-work
Updated tests:
- Added computeValidNonce() helper that actually computes valid
nonces by brute force (for testing purposes)
- testValidPowPassesChallenge now uses a real computed nonce
Updated README to explicitly mention server-side verification.
The issue was that ngx.re.match in the test environment uses
rex_pcre2.match which has a different API than OpenResty's
ngx.re.match. The rex library returns captures differently.
Changed getCookieValue() to use Lua's built-in string.match()
with Lua patterns instead. This is simpler, more portable, and
works correctly in both test and production environments.
Also removed debug logging since the issue is now identified.
Added debug logging to see what's happening with cookie header
parsing in the failing token validation tests. This will help
identify whether:
- ngx.req.get_headers() is returning the expected headers
- The Cookie header is being found (case sensitivity check)
- The token is being extracted correctly
- The token is found in the shared dict
Also added ngx log level constants (DEBUG, INFO, WARN, ERR) to
the test framework since the module uses them.
Allow users to experiment with different DDoS mitigation strategies by
choosing between three challenge types:
1. Button Challenge (default): Simple click-to-verify, best UX
2. Question Challenge: Multiple-choice questions, better bot filtering
3. Proof-of-Work Challenge: SHA-256 computation, strongest protection
Features:
- Three distinct challenge page generators with unique HTML/CSS/JS
- Question pool with 7 simple multiple-choice questions
- JavaScript-based PoW using Web Crypto API (SHA-256)
- Configurable PoW difficulty (3-6 leading zeros)
- Verification logic for each challenge type
- Automatic challenge cleanup after verification
- 10 new comprehensive tests covering all challenge types
Configuration:
- challenge_type: 'button' (default), 'question', or 'pow'
- pow_difficulty: 3=fast, 4=moderate (default), 5=slow, 6=very slow
The PoW challenge creates real computational cost for attackers. With
difficulty 4, each request requires ~65,000 hash computations (~1-3s).
This makes volumetric attacks expensive while remaining transparent to
legitimate users.
Files modified:
- scripts/ddos_protection_challenge.lua: +346 lines (challenge generators, verification)
- tests/ddos_protection_challenge.lua: +198 lines (10 new tests)
- scripts/ddos_protection_challenge.README.md: +93 lines (detailed docs)
- conf.example.ddos_protection.lua: Updated with challenge_type option
- conf.example.ddos_protection_challenge_types.lua: New file with 4 config examples
Allow users to specify which paths should be protected by the challenge
system, enabling selective protection of expensive endpoints while
leaving static assets and other paths unrestricted.
Changes:
- Add protected_paths config option (list of PCRE regex patterns)
- Only apply challenge/ban logic to paths matching protected patterns
- If protected_paths is empty/unset, protect all paths (default behavior)
- Special endpoints (verify/trap) always function regardless of config
- Add 8 new tests for path-based filtering scenarios
- Update documentation with examples and best practices
- Update example config to show protected_paths usage
This allows more granular control - for example, protecting only /api/*
and /search while allowing free access to static assets, reducing UX
friction while still protecting expensive operations.
Implements a Cloudflare-style "Under Attack" mode that protects against
DDoS attacks, scraping, and automated bots.
Features:
- Challenge-response system requiring human interaction
- Honeypot link that automatically bans IPs of bots that click it
- Cookie-based token system for validated users (24h default)
- Temporary IP banning (1h default)
- Comprehensive test suite
The module intercepts requests before they hit the backend, reducing
computational cost from scraping and DDoS attempts. It's particularly
effective against simple scrapers and volumetric attacks.
Files added:
- scripts/ddos_protection_challenge.lua - Main module implementation
- tests/ddos_protection_challenge.lua - Comprehensive test suite
- scripts/ddos_protection_challenge.README.md - Full documentation
- conf.example.ddos_protection.lua - Example configuration
- test.lua - Added test import
