Detection Architecture¶

How Kysira scores a request, what attack classes it covers, and how it handles encoding obfuscation.

Two-layer detection¶

Every request passes through two layers in sequence:

1. Heuristic layer — fast, deterministic pattern matching against a catalog of attack signatures. Runs first. If a high-confidence match is found, the ML layer is skipped entirely to keep latency low.

2. ML layer — purpose-trained classifiers for attack classes where heuristic patterns alone have insufficient recall (SQL injection and prompt injection). These run only when the heuristic layer does not already produce a kill-threshold score.

This ordering bounds inference latency: the vast majority of requests are decided by the heuristic layer in under 1 ms. The ML classifiers add 50–400 ms on CPU and are only invoked when needed.

Request normalization¶

Before any detection runs, the request text is normalized to a stable form. This means:

• Recursive URL-decoding to a fix point — double and triple encoding (%2527, %252527) collapse to plain text
• HTML entity decoding (<, ', <) — inline with URL decoding so mixed-encoding payloads are handled in one pass
• Form body splitting on both & and ; separators, including parameter names (not just values) — payloads hidden in parameter names are not missed

Detection always runs on the normalized form, making it caller-independent: a payload is detected regardless of whether the network layer, load balancer, or application framework decoded it before Kysira saw it.

Detector catalog¶

JWT / auth-token integrity (keyless)¶

Kysira inspects JWTs and bearer tokens in the Authorization header and cookies without any signing key — it does not cryptographically verify signatures (a stateless WAF holds no customer key). Instead it blocks the token-abuse primitives a correctly built client never produces, so an application that validates tokens poorly is still protected:

• alg: none / stripped (empty) signature — the classic unsigned-token acceptance bypass
• kid header injection — a kid carrying path-traversal, SQL, or shell metacharacters that a naive backend concatenates into a key lookup
• attacker-supplied verification keys — jku/x5u pointing at an external key source, or an embedded jwk/x5c (advisory)
• replayed tokens — exp in the past or nbf in the future (advisory)
• tokens signed with a notoriously weak/example HS* secret (e.g. secret, your-256-bit-secret) — trivially forgeable

A normal, well-formed signed token scores 0.0: this is an abuse detector, not a "JWT present" detector. Cryptographic verification against a configured key/JWKS is a separate, opt-in capability.

The insecure-deserialization detector likewise goes beyond prefix signatures: it base64/url-safe-decodes blobs in the request — including those riding in a Cookie — and matches serialization magic bytes (Java, .NET BinaryFormatter, Python pickle, Ruby Marshal), unwrapping one layer of gzip/zlib compression first.

Scoring tiers¶

Detectors return a score in [0.0, 1.0]. The default kill threshold is 0.95.

The advisory tier exists for classes where a generic WAF cannot distinguish attack from legitimate use without application context — open redirects (any external URL could be legitimate), private-host SSRF (internal health checks), and certain NoSQL operators used in filter APIs. These surface in the dashboard for review without risking false-positive blocks.

The /score/all endpoint returns the maximum score across all detectors along with a per-detector breakdown, so you can inspect which class fired and at what confidence.