Stateful Attack Chains
Most security dimensions are single-request: mutate the request, send it, score the response. Some vulnerabilities only appear across two or more related requests — the payload is written first and read back later, or the same business operation is replayed. Aethrix calls these stateful attack chains.
Two dimensions use chains:
| Dimension | Chain shape |
|---|---|
| Stored XSS (Stateful Chain) | Write the script payload through one request, then read the resource back; if the payload comes back unescaped, the API stores and re-serves it |
| Business Flow Abuse (Replay) | Send a legitimate business request, then replay it several times; an API that accepts every replay has no idempotency or interaction control |
When you enable either dimension, the wizard grows a Stateful Chains (optional) step between Attack dimensions and Review.
Automatic vs Configured
- Automatic (default) — leave the chain list empty. The generator applies its built-in rules: stored XSS gets one chain per (field, payload) pair with an algorithmic read-back endpoint when it can find a matching parameter-free GET; business flow gets three replays.
- Configured — add explicit chains to control the read-back endpoint, the replay count, and the fields used to judge the outcome. This is useful when the read-back endpoint cannot be inferred, or when you want a specific field compared.
Adding a Chain
Click Add chain. Each chain card has the following controls.
| Control | Shown for | Meaning |
|---|---|---|
| Template | always | The chain shape (see below) |
| Read-back endpoint | every template except Replay | The operation that reads the stored resource back. Leave it to the automatic pairing to keep the default behavior |
| Replay count | Replay only | How many times the request is replayed (1–20, default 3) |
| Judge fields | always | Optional body fields used to judge the outcome. Empty means the verdict is based on status codes only |
Chain templates
The Template dropdown offers four shapes:
| Template | Behavior |
|---|---|
| SameEndpointReadBack | Read the same endpoint back with GET — the default stored-XSS shape |
| CrudPairing | Pair a parameter-free GET of the same resource (for example POST /pet → GET /pet) |
| ManualEndpointPair | Read back a specific operation you pick in Read-back endpoint |
| Replay | Business-flow replay: one initial request plus N replays |
Judge Fields
Judge fields turn a status-code verdict into a value-based one. They are JSON body field names (the leaf name is matched, so User.Email and Email are equivalent). Leaving them empty keeps the simple status-code behavior.
- Stored XSS — a judge field contains the staged payload → the payload was stored and returned.
- Replay — a judge field value equal to the initial response's value means the same resource was re-executed (the abuse signal). A different value means the resource advanced and the chain is considered secure.
The Judge fields list is populated from fields discovered in the template body, so pick your template request before adding judge fields.
How Chains Run
A chain executes as a group, in order:
- The write / initial request runs.
- The read-back / replay steps run.
- The chain is scored as a whole.
Because a chain's steps depend on each other, running a single chain step from the instance list only runs that leg — use Run all (or run the case) to execute a chain correctly.
How Chains Appear in the Report
Chain results are grouped under an Attack Chains section, one group per chain, so you can see every request in the sequence together. The individual steps also appear in the instance list and carry their own verdicts.
See Reviewing a Security Scan for the panel and report formats.