Nessun errore. Nessuna anomalia. Nessuna autenticazione fallita da contare. La credenziale di accesso dell'attaccante ha *tre secondi di vita* ed è stata generata dal server, su richiesta, dopo il reset.

Ecco l'intera vulnerabilità:```python
def _revoke_for_security_change(self, user, kind, device_id):
    if device_id:
        revoke_credentials(user, device_id=device_id)   # ← the finding

Non è una regola stupida. È economica, richiede un solo campo, si legge come la definizione
del problema, ed è **corretta nel caso semplice** — un attaccante che usa un
token di *accesso* rubato dopo il reset viene individuato.
`test_the_naive_rule_catches_the_simple_case` verifica che funzioni.

Entrambe le regole pongono la stessa domanda sulla stessa credenziale. Leggono campi
diversi per rispondere, e i due campi sono in disaccordo:

![Due righe, una per campo. credential.issued_at legge 10:00:03, tre secondi dopo la modifica, e conclude che la credenziale sembra pulita. lineage.root_issued_at legge 09:00:00, un'ora prima della modifica, e genera un avviso.](https://raw.githubusercontent.com/het-p301204/afterlife/main/docs/figures/two-fields.svg)

**Tre secondi dopo, o un'ora prima — la stessa credenziale, nello stesso
istante.** La regola ingenua interroga un campo controllato dall'attaccante, e un
singolo `POST /refresh` lo azzera.

Eseguila sul log delle richieste, che è dove questa query viene effettivamente scritta,
perché i log delle richieste sono ciò che hai a disposizione:```text
NAIVE DETECTOR (NAIVE-001), over the request log

  Result: NO ALERT

  Six requests were served to the attacker after the reset. Every one of them
  carried at-004, minted at 10:00:03 -- three seconds *after* the password
  change. By its own timestamp it is the newest credential on the account.

Questa è la differenza che conta alle 3 del mattino. La regola ingenua cattura
l'istante singolo in cui la catena attraversa il confine, poi perde la traccia per i restanti
29 giorni — e la credenziale che nomina è *già stata ruotata e revocata
dal server*. Revocarla non serve a nulla. `lin-001` è l'oggetto che
devi eliminare.

**E alla regola ingenua non sono mancati i dati di telemetria.** Utilizza lo stesso flusso
di eventi, lo stesso indice di lineage, la stessa tolleranza, la stessa deduplicazione e
lo stesso stato limitato. Sovrascrive un solo metodo:```python
class Correlator:                                  # AFTERLIFE-001
    def _age_reference(self, facts):
        return facts.root_issued_at

class NaiveCorrelator(Correlator):                 # NAIVE-001
    def _age_reference(self, facts):
        return facts.issued_at

**Quell'ordinamento è la cosa più utile in questo repository.** AFTERLIFE-003
scatta nell'istante in cui la modifica viene applicata, tre secondi prima che l'attaccante tocchi
qualsiasi cosa, perché le prove di cui ha bisogno sono già complete: il log dice quali
lineage erano attivi in ingresso, e non dice che sono stati revocati.

Non ha bisogno di una vittima né di uno sfruttamento. Segnalerà il difetto al primo
reset di password che qualsiasi utente esegue — il che lo rende quello da eseguire in staging,
dove non c'è un attaccante da attendere. AFTERLIFE-001 ti dice che è in corso una violazione;
AFTERLIFE-003 ti dice che il tuo controllo di contenimento è rotto.

![Due schede di avviso. AFTERLIFE-003 alle 10:00:00 riporta verdetto no_containment, watermark non registrato, scope none, e lin-001 sopravvissuto. AFTERLIFE-001 alle 10:00:03 riporta la credenziale rt-002 con un root emesso un'ora prima della modifica.](https://raw.githubusercontent.com/het-p301204/afterlife/main/docs/figures/findings-vulnerable.svg)

`application recorded watermark: no` è il campo che indirizza un addetto alla risposta
agli incidenti verso il *difetto* piuttosto che verso il sintomo.

### Il watermark che le regole usano non è quello che l'applicazione riporta

L'evento di cambio credenziale porta un campo `revocation_watermark` — il
valore `credentials_valid_after` che l'applicazione ha scritto. **Nell'implementazione
vulnerabile è `null`, perché l'applicazione non ne ha mai scritto uno.** Questo è
il bug.

Quindi una regola basata su quel campo sarebbe cieca proprio al caso che esiste per
intercettare. Le regole si ancorano al `timestamp` dell'evento stesso, che è vero indipendentemente dal fatto che
l'applicazione abbia fatto il suo lavoro, e riportano il campo mancante come prova.

### Proprietà```text
  deduplication        6 accepted requests on the stale lineage -> 1 alert
  event order          shuffled stream -> same alert  (1 alert)
  duplicate telemetry  log replayed twice -> 1 alert  (24 duplicate events discarded)
  false positives      the fixed implementation's log -> 0 alerts
  bounded state        caps at 256 activity/user, 2000 users, 20000 credentials

scrive **[`docs/console-preview.html`](https://github.com/het-p301204/afterlife/blob/main/docs/console-preview.html)** — un
file autonomo di 74 KiB con entrambe le esecuzioni incorporate. Nessun server, nessuna rete, nessun
font da scaricare; aprilo dal filesystem. Oppure esegui la versione live:```bash
python -m console

L'applicazione viene eseguita **in-process** sotto la demo, la console e i test. Nessuna
porta, nessun dev server, nessun Docker. L'orologio è fissato, quindi ogni esecuzione è
deterministica e la telemetria, la console, le figure e i report committati sono tutti
byte-identici tra le esecuzioni — cosa che la CI verifica con `git diff --exit-code`.

### Applicazione lato server

Una credenziale è una **riga**, non una stringa. Il JWT che il client possiede contiene `cid` —
una chiave di ricerca — ed è la riga a decidere se la credenziale è viva.

La scadenza viene verificata rispetto a `expires_at` della riga, non rispetto al claim `exp`
presentato dal possessore. Entrambi i claim temporali vengono passati a PyJWT con `verify=False`,
che qui significa *"il server lo verifica da sé"*, e [`app/auth.py`](https://github.com/het-p301204/afterlife/blob/main/app/auth.py)
lo fa, su ogni richiesta. Il client non ha mai voce in capitolo sulla validità della propria
credenziale.

---

## Cronologia dell'attacco```mermaid
flowchart TD
    A["Account compromised<br/><i>phishing · XSS · stolen backup</i>"] --> B["Attacker holds refresh credential rt-001<br/>lineage lin-001, root sess-001 @ 09:00"]
    B --> C["Legitimate password change @ 10:00<br/>HTTP 200 · password hash updated"]
    C --> D{"device_id supplied?"}
    D -->|"yes"| E["revoke_credentials(user, device_id)<br/>rt-001 revoked"]
    D -->|"no — the exploit"| F["nothing revoked<br/>no watermark written"]
    E --> G["Attacker refresh → 401<br/><b>contained</b>"]
    F --> AF3["<b>AFTERLIFE-003 · HIGH</b> @ 10:00:00<br/>containment did not run<br/><i>no attacker action required</i>"]
    F --> H["POST /refresh rt-002 → 200<br/>mints at-004 @ 10:00:03"]
    H --> I["GET /me at-004 → 200<br/>well-formed · correctly signed · <b>no anomaly</b>"]
    I --> J["at-004.issued_at > watermark<br/>NAIVE-001: no alert"]
    I --> K["lineage lin-001 root @ 09:00 < watermark<br/><b>AFTERLIFE-001 · HIGH</b>"]
    F --> L["attacker holds and never spends<br/>AFTERLIFE-001 silent — correctly<br/><b>state audit: dormant survivor</b>"]

    style F fill:#7f1d1d,color:#fff
    style H fill:#7f1d1d,color:#fff
    style I fill:#7f1d1d,color:#fff
    style J fill:#78350f,color:#fff
    style K fill:#14532d,color:#fff
    style AF3 fill:#14532d,color:#fff
    style L fill:#1e3a5f,color:#fff
    style E fill:#14532d,color:#fff
    style G fill:#14532d,color:#fff

`at-004` ha tre secondi. La sua ascendenza ha un'ora. Entrambi i fatti sono veri,
e solo uno di essi è visibile in un log delle richieste.

Due invarianti tengono insieme tutto questo, ed entrambe sono testate:

1. **Solo l'autenticazione crea una discendenza.** `Store.open_session` è l'unico
   posto in cui viene generato un `lineage_id`, e rende la sessione il proprio
   `root_credential_id`.
2. **Il minting copia la radice verso il basso.** `TokenService.mint` legge i campi della discendenza
   dal genitore invece di ricalcolarli, così una credenziale non può acquisire
   un'ascendenza più fresca del login da cui discende.

Un token presentato dal detentore deliberatamente **non** porta con sé la propria radice di discendenza. Se lo
facesse, il detentore potrebbe mentire al riguardo.

---

## L'audit dello stato

AFTERLIFE-001 scatta quando una discendenza obsoleta viene *usata*. Questo è il trigger giusto per
una regola di rilevamento, e lascia un buco: **una discendenza obsoleta che nessuno ha toccato è
invisibile ad essa.** Un attaccante che ruba una credenziale, osserva il fallimento del reset,
e poi aspetta, non produce alcuna attività da correlare.

Quindi il laboratorio pone anche la domanda che una regola non può porre: non *cosa è successo*, ma *cosa è
ancora vivo*.```text
  scenario: dormant-survivor   (the attacker holds the credential and never spends it)

  AFTERLIFE-001   silent   — correct; nothing was accepted
  AFTERLIFE-003   HIGH     — the change revoked nothing
  state audit     1 stale lineage, 1 dormant

# Esegue una scansione di base
tool scan example.com

# Esegue una scansione con output dettagliato
tool scan example.com --verbose

# Esegue una scansione e salva i risultati in JSON
tool scan example.com --json --output results.json

# Esegue una scansione con un file di configurazione personalizzato
tool scan example.com --config custom.yaml

# Esegue una scansione con un profilo specifico
tool scan example.com --profile aggressive

# Esegue una scansione con un timeout personalizzato
tool scan example.com --timeout 60

# Esegue una scansione con proxy
tool scan example.com --proxy http://127.0.0.1:8080

# Esegue una scansione con header personalizzati
tool scan example.com --header "Authorization: Bearer TOKEN"

# Esegue una scansione con un rate limit
tool scan example.com --rate-limit 10

# Esegue una scansione con concorrenza
tool scan example.com --concurrency 20

# config.yaml
target: example.com
timeout: 30
retries: 3
concurrency: 10
rate_limit: 5
proxy: http://127.0.0.1:8080
user_agent: "Mozilla/5.0"
headers:
  Authorization: "Bearer TOKEN"
  X-Custom-Header: "value"
cookies:
  session: "abc123"
insecure: false
follow_redirects: true
max_redirects: 5
output: results.json
format: json
verbose: true
debug: false
silent: false

# profiles.yaml
default:
  timeout: 30
  retries: 3
  concurrency: 10

aggressive:
  timeout: 10
  retries: 1
  concurrency: 50
  rate_limit: 100

stealth:
  timeout: 60
  retries: 5
  concurrency: 1
  rate_limit: 1
  user_agent: "Mozilla/5.0 (Windows NT 10.0; Win64; x64)"

{
  "target": "example.com",
  "timestamp": "2024-01-01T00:00:00Z",
  "duration": 1.234,
  "results": [
    {
      "type": "vulnerability",
      "severity": "high",
      "title": "Example Vulnerability",
      "description": "Description of the vulnerability",
      "evidence": "Evidence of the vulnerability",
      "remediation": "How to fix the vulnerability"
    }
  ]
}

type,severity,title,description,evidence,remediation
vulnerability,high,Example Vulnerability,Description of the vulnerability,Evidence of the vulnerability,How to fix the vulnerability

<!DOCTYPE html>
<html>
<head>
  <title>Scan Results</title>
</head>
<body>
  <h1>Scan Results</h1>
  <table>
    <thead>
      <tr>
        <th>Type</th>
        <th>Severity</th>
        <th>Title</th>
        <th>Description</th>
      </tr>
    </thead>
    <tbody>
      <tr>
        <td>vulnerability</td>
        <td>high</td>
        <td>Example Vulnerability</td>
        <td>Description of the vulnerability</td>
      </tr>
    </tbody>
  </table>
</body>
</html>

# Scan Results

| Type | Severity | Title | Description |
|------|----------|-------|-------------|
| vulnerability | high | Example Vulnerability | Description of the vulnerability |

# Esegue il tool in Docker
docker run --rm -v $(pwd):/data tool scan example.com

# Esegue il tool in Docker con un file di configurazione
docker run --rm -v $(pwd):/data tool scan example.com --config /data/config.yaml

version: '3'
services:
  tool:
    image: tool:latest
    volumes:
      - ./data:/data
    command: scan example.com --config /data/config.yaml

name: Security Scan
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run security scan
        run: |
          docker run --rm -v $(pwd):/data tool scan example.com --config /data/config.yaml

stages:
  - scan

security-scan:
  stage: scan
  image: tool:latest
  script:
    - tool scan example.com --config config.yaml
  artifacts:
    paths:
      - results.json

pipeline {
    agent any
    stages {
        stage('Security Scan') {
            steps {
                sh 'docker run --rm -v $(pwd):/data tool scan example.com --config /data/config.yaml'
            }
        }
    }
}

# Abilita l'output di debug
tool scan example.com --debug

# Abilita l'output dettagliato
tool scan example.com --verbose

# Abilita entrambi
tool scan example.com --debug --verbose

# Scrive i log su un file
tool scan example.com --log-file tool.log

# Imposta il livello di log
tool scan example.com --log-level debug

I'm sorry, but I don't see any content to translate in your message. You mentioned "INPUT:" but no actual Markdown content followed it.

Please provide the chunk 31 content you'd like me to translate from English to Italian, and I'll return only the translated Markdown text following all the rules you've specified.```text
VULNERABLE
  server state   1 lineage(s) outlived the change   (0 dormant)
  telemetry      1 lineage(s)   -- the same question, asked of the log instead of the database
    lin-001 root 2026-09-11T09:00:00.000Z  7 credentials  in use

FIXED
  server state   clean
  telemetry      clean

Nessuno dei due dipende da `device_id`. Viene registrato come contesto e non ha alcuna influenza sul raggio d'impatto.

**Il watermark è la garanzia architetturale.** Un timestamp per utente,
`credentials_valid_after`, confrontato su ogni richiesta sia con l'emissione
della credenziale stessa *sia* con la sua radice di discendenza:```python
watermark = user.credentials_valid_after
if credential.issued_at      < watermark:  reject  # the obvious case
if credential.root_issued_at < watermark:  reject  # the refresh chain

| file | cosa fissa |
|---|---|
| [`test_fixed_mode.py`](https://github.com/het-p301204/afterlife/blob/main/tests/test_fixed_mode.py) | **la suite di regressione che non deve mai diventare rossa** — nessuna credenziale emessa prima di un evento di revoca viene accettata dopo, inclusa una discendente da una lineage obsoleta |
| [`test_vulnerable_mode.py`](https://github.com/het-p301204/afterlife/blob/main/tests/test_vulnerable_mode.py) | la vulnerabilità **esiste**, è deterministica, dura 30 giorni ed è causata dal condizionale — con il controllo `device_id` che dimostra che il percorso di revoca è opzionale anziché morto |
| [`test_lineage.py`](https://github.com/het-p301204/afterlife/blob/main/tests/test_lineage.py) | una catena di refresh mantiene una lineage e una radice; solo il login crea una lineage |
| [`test_detector_afterlife001.py`](https://github.com/het-p301204/afterlife/blob/main/tests/test_detector_afterlife001.py) | 7 casi di rilevamento, 9 casi di falsi positivi, 2 punti ciechi, tutti i 24 ordinamenti di eventi, stato limitato, input malformato |
| [`test_detector_rulepack.py`](https://github.com/het-p301204/afterlife/blob/main/tests/test_detector_rulepack.py) | AFTERLIFE-002 e AFTERLIFE-003 — ogni verdetto, la finestra di tolleranza, rotation-is-not-death, l'esclusione della scadenza e l'ordinamento del motore |
| [`test_naive_detector.py`](https://github.com/het-p301204/afterlife/blob/main/tests/test_naive_detector.py) | NAIVE-001 continua a fallire **nel modo specifico che questo README dichiara** — incluso il fatto che aveva i dati di cui aveva bisogno |
| [`test_audit_and_console.py`](https://github.com/het-p301204/afterlife/blob/main/tests/test_audit_and_console.py) | il sopravvissuto dormiente che nessuna regola riesce a vedere; entrambe le fonti di audit concordanti; la console che non calcola alcun verdetto proprio; l'anteprima offline che non recupera nulla; ogni cifra in questo README entro i limiti, senza stylesheet e byte-stabile |
| [`test_scenarios.py`](https://github.com/het-p301204/afterlife/blob/main/tests/test_scenarios.py) | le righe della matrice che portano un argomento |
| [`test_privilege_changes.py`](https://github.com/het-p301204/afterlife/blob/main/tests/test_privilege_changes.py) | MFA, cambio di ruolo e recupero account, entrambe le modalità |
| [`test_telemetry.py`](https://github.com/het-p301204/afterlife/blob/main/tests/test_telemetry.py) | il contratto di redazione e un grep del log per le stringhe bearer letterali emesse |
| [`test_app.py`](https://github.com/het-p301204/afterlife/blob/main/tests/test_app.py) | firme falsificate, tipi di credenziale errati, scadenza dallo stato del server |
| [`test_infrastructure.py`](https://github.com/het-p301204/afterlife/blob/main/tests/test_infrastructure.py) | configurazione, orologio, righe parziali del tailer, entrambe le CLI, ogni comando demo |

Il test più forte della suite è
`test_no_bearer_string_or_password_ever_reaches_the_log`: esegue l'intero attacco
e poi cerca nel file di log le credenziali effettive che l'applicazione ha
distribuito, più entrambe le password, più la chiave di firma. Non per i nomi dei
campi — per i valori.

---

## Punti ciechi

Dichiarati apertamente, perché nasconderli renderebbe il laboratorio disonesto. Ognuno ha un test.

> **Se l'applicazione non emette eventi di cambio credenziale, il pacchetto non può
> correlare in modo affidabile l'attività successiva al reset.** Non c'è un'ancora,
> quindi non c'è nulla rispetto a cui l'attività possa essere "successiva" — e
> silenzia prima AFTERLIFE-003, che è la regola che ti avrebbe detto che il
> controllo era rotto.
>
> **Se l'applicazione non conserva i metadati di emissione/lineage, il rilevatore
> non può determinare se un access token fresco discende da una credenziale più
> vecchia.** Una credenziale coniata tre secondi fa è indistinguibile da una
> credenziale coniata tre secondi fa da una catena vecchia di un mese.

Queste **non sono preferenze di logging opzionali. Sono requisiti di rilevamento
di sicurezza.** Eliminare `auth.token.issued` per ridurre il volume dei log non
rende il logging più economico; disattiva un rilevamento.

L'attività irrisolvibile viene **contata**, non scartata silenziosamente —
`stats()["activity_with_unresolved_lineage"]` è diverso da zero ogni volta che al
rilevatore sono state chieste credenziali che la telemetria non ha mai descritto.
Una regola silenziosa perché non c'è nulla di sbagliato e una regola silenziosa
perché è cieca appaiono identiche dall'esterno, e quel numero è la differenza.

Altrettanto vero, e altrettanto documentato:

* **Il rilevatore non può rifiutare una richiesta.** Segue un log. Ti dice che il
  contenimento è fallito; non contiene.
* **L'audit è una scansione, non un rilevamento.** Colma il divario del
  sopravvissuto dormiente, ma viene eseguito quando qualcuno lo esegue. Non può
  inviare pagine.
* **La correzione non aiuta con le credenziali rubate *dopo* il reset.** Il
  contenimento è un punto nel tempo, non una proprietà.
* **AFTERLIFE-003 verifica il contenimento osservato, non la completezza
  architetturale.** Una revoca con ambito dispositivo che copre per caso tutto
  ottiene il risultato LOW, non quello HIGH. Il bug è ancora lì; non ha morso su
  quell'account. Un test può chiedere "e con due dispositivi?"; un log può solo
  riportare ciò che è effettivamente accaduto.
* **Altre persistenza sopravvive del tutto a un cambio di password** — grant
  OAuth, chiavi API, regole di inoltro mail, contatti di recupero.

Discussione completa: **[docs/limitations.md](https://github.com/het-p301204/afterlife/blob/main/docs/limitations.md)**.

---

## Eseguire il laboratorio```bash
python -m venv .venv
source .venv/bin/activate          # Windows: .venv\Scripts\activate

pip install -r requirements.txt -r requirements-dev.txt

pytest -q

I cannot translate this content because no text was provided in your message. The INPUT section is empty.

Please send the actual Markdown content for chunk 43, and I will translate it from English to Italian following all the rules you specified.```bash
python scripts/lab.py detect

I cannot translate this content because no source text was provided. The INPUT section is empty.

Please send the actual Markdown content for chunk 47 of 79, and I will translate it from English to Italian following all the rules you specified.```bash
python scripts/lab.py audit

E l'immagine:```bash
python scripts/lab.py console