engagement-mgr — Engagement Manager è un'applicazione web per il monitoraggio delle attività di sicurezza offensiva. Presenta un'interfaccia utente moderna, realizzata con Next.js, Prisma e PostgreSQL. | Kitploit

Area di lavoro per la scrittura: apri il link Write & review di un risultato per la modifica Markdown e un'anteprima sicura. Le bozze private vengono salvate dopo 15 secondi di inattività o su richiesta; sono memorizzate sul server, non nella memoria locale del browser. Recupera esplicitamente una bozza dopo la riapertura. I salvataggi in conflitto preservano il testo dell'editor e richiedono il confronto con la revisione corrente. Le revisioni del testo possono essere ispezionate e ripristinate; il ripristino non ripristina le prove eliminate.
Template riutilizzabili: cerca la formulazione approvata per titolo, categoria o gravità. Gli utenti possono proporre template; gli amministratori li curano e li approvano. L'applicazione di un template crea un risultato di engagement indipendente con osservazioni vuote, host interessati e prove, prevenendo il riutilizzo accidentale delle prove di un altro engagement.
Prove: carica o incolla fino a quattro immagini PNG/JPEG insieme, aggiungi didascalie e modifica didascalia/ordine nell'area di lavoro per la scrittura. Le immagini vengono decodificate, private dei metadati, ridimensionate a un massimo di 2000 × 2000 pixel e salvate come PNG. Conserva separatamente le prove forensi originali se sono richiesti i byte o i metadati originali.
Revisione: invia i risultati completi da Draft/Changes Requested a Ready. Un revisore assegnato o un amministratore, diverso dall'autore corrente, può approvare o richiedere modifiche. Gli amministratori assegnano i revisori. Le modifiche a testo, prove e revisioni ripristinate annullano l'approvazione. La coda di revisione, i commenti, la checklist di preparazione e la cronologia delle revisioni supportano il passaggio di consegne.
Report PDF: scegli un engagement in Reports, scrivi il suo riepilogo esecutivo, seleziona/ordina i risultati e salva le impostazioni. Le bozze PDF sono contrassegnate visibilmente. Solo gli amministratori possono emettere un PDF finale, e ogni risultato selezionato deve essere approvato e superare i controlli di preparazione. Ogni versione emessa memorizza il suo PDF, uno snapshot esplicito del contenuto e un digest SHA-256; le modifiche successive non lo rigenerano. L'eliminazione dell'engagement padre elimina comunque i suoi report attraverso il ciclo di vita esistente.
Importazioni da scanner: visualizza in anteprima un export, seleziona i risultati, quindi conferma. Le importazioni non eseguono mai scansioni né contattano i target. Il fingerprinting lato server salta i risultati corrispondenti nello stesso engagement; tutti i nuovi record iniziano come Draft e devono essere verificati da un operatore.

Famiglia scanner/export	Export accettato
Burp Suite	Issues XML, incluso il DTD dello schema interno inerte
Nessus / Tenable	Nessus v2 XML (`.nessus`)
Nmap	XML; le porte aperte e il loro output degli script diventano osservazioni informative, non vulnerabilità dedotte
OpenVAS / Greenbone	Report XML nativo o GMP `get_reports_response`
OWASP ZAP	Report JSON tradizionale con siti e avvisi
Nuclei	JSON Lines (`-jsonl`)
Qualys	XML dei risultati di scansione (struttura `SCAN/IP`), non il formato separato dell'API di rilevamento host
Semgrep / CodeQL e altri produttori SARIF	Esecuzioni, regole e risultati SARIF JSON

`npm test` utilizza la modalità di test non isolata di Node con `tsx` in modo che i singoli casi di test TypeScript vengano eseguiti, invece di limitarsi a segnalare il successo del sottoprocesso del file. Mantieni visibili i totali espliciti delle asserzioni in CI.

Le regressioni del database e del browser richiedono un **database locale dedicato denominato `reporting_tests`**, con le migrazioni applicate. Creano ed eliminano le proprie righe di fixture; non puntare mai questi test a un database applicativo. Imposta `REPORTING_TEST_DATABASE_URL` su quel database di test, quindi esegui:```bash
DATABASE_URL="$REPORTING_TEST_DATABASE_URL" npx prisma migrate deploy
npm run test:reporting
npx playwright install chromium
npm run test:browser

`postgresql-client` fornisce `pg_dump`, `pg_restore` e `psql`; `zip` crea archivi di backup. L'estrazione del ripristino è gestita dall'applicazione con una rigorosa validazione delle voci e delle dimensioni.

L'installazione dei pacchetti non sempre lascia PostgreSQL in esecuzione. Avvia e abilita il servizio prima di creare i ruoli o avviare l'app:```bash
sudo systemctl enable --now postgresql
sudo systemctl status postgresql --no-pager

| Variabile | Obbligatoria | Note |
|----------|----------|-------|
| `DATABASE_URL` | Sì | Stringa di connessione PostgreSQL. Prisma utilizza il parametro di query `schema=public`. Il backup e il ripristino utilizzano un file pgpass temporaneo accessibile solo al proprietario, in modo che la password non venga inserita negli argomenti del sottoprocesso. |
| `JWT_SECRET` | Sì in produzione | Deve contenere almeno **32 caratteri**. L'app rifiuta di avviarsi in produzione senza di esso. La rotazione di questo valore invalida tutte le sessioni esistenti. |
| `TRUST_PROXY` | No | Impostare a `1` (o `true`) solo quando l'app si trova dietro un reverse proxy che **sovrascrive** `X-Forwarded-For` / `X-Real-IP` e `X-Forwarded-Host`. I controlli dell'origine di login utilizzano `X-Forwarded-Host` quando presente in questa modalità; deve contenere un host pubblico, incluso un numero di porta non predefinito quando utilizzato. In caso contrario, il proxy deve preservare l'header `Host` pubblico. Questa è la topologia di produzione richiesta per limiti di login accurati per origine. Quando non impostato, gli header vengono ignorati per prevenire lo spoofing e il login utilizza un budget di fallback condiviso di un minuto più elevato, in modo che un client non possa imporre un blocco globale di 15 minuti. |
| `ALLOWED_DEV_ORIGINS` | No | **Solo sviluppo.** Nomi host aggiuntivi autorizzati a caricare le risorse `/_next` (separati da virgola). Gli indirizzi IPv4 LAN correnti del server sono autorizzati automaticamente. Utilizzare questo per un nome DNS stabile. Le build di produzione ignorano questa impostazione. |

Genera un secret robusto:```bash
openssl rand -base64 32

### Produzione

Utilizza un utente database dedicato con **privilegi minimi** — non concedere `CREATEDB` o diritti di superutente:```bash
sudo -u postgres createuser --pwprompt em_app
sudo -u postgres createdb --owner=em_app engagement_manager

Lo script installa i prerequisiti, avvia e abilita il servizio PostgreSQL, richiede un nome utente e una password per il database, scrive un file `.env` con `chmod 600`, crea il ruolo e il database PostgreSQL, applica le migrazioni e inizializza l'account amministratore predefinito. La modalità produzione completa anche `npm run build` e stampa solo il comando di avvio della produzione. Non installa Node.js da uno script shell remoto; installa prima una release supportata di Node.js.

Per uso headless o CI:```bash
sudo install -d -m 700 -o "$USER" /secure
openssl rand -base64 24 > /secure/db-password
chmod 600 /secure/db-password
./setup.sh -y --db-user=em_admin --db-pass-file=/secure/db-password

Installa le dipendenze di Node.js: ```bash npm ci
Eseguire le migrazioni del database per creare le tabelle: ```bash npx prisma migrate dev
Popolare il database per creare l'account Admin predefinito: ```bash npx prisma db seed

Lascia quella finestra aperta. Usa l'indirizzo Local o Network che stampa.

Per avviarlo manualmente invece: PostgreSQL deve essere in esecuzione (`sudo systemctl start postgresql` se necessario). Poi avvia il server di sviluppo:```bash
npm run dev

`npm run dev` e `npm start` si legano a `0.0.0.0` in modo che l'URL di rete funzioni sulla LAN. Considera l'accesso LAN come solo per laboratorio su una rete attendibile. La modalità dev non è rafforzata per l'internet pubblico.

Se apri l'app tramite **hostname** (non IP) e il browser remoto mostra una pagina bianca vuota, aggiungi quel nome a `.env` e riavvia:```bash
ALLOWED_DEV_ORIGINS=dev.office.example

Clona il repository e installa le dipendenze: ```bash npm ci
Creare .env con valori di produzione (DATABASE_URL, JWT_SECRET ≥ 32 caratteri).
Applicare le migrazioni del database: ```bash npm run db:migrate
Esegui i controlli pre-deploy: ```bash npm run audit npm run typecheck npm run build
Avvia l'applicazione con NODE_ENV=production: ```bash NODE_ENV=production npm run start

Percorso	Contenuto
`engagement-manager-backup/database.dump`	Dump completo PostgreSQL in formato custom (schema, tabelle, dati, enum, relazioni) da `pg_dump`
`engagement-manager-backup/uploads/`	File screenshot dei finding referenziati nel database

Accedi come utente Admin.
Apri Admin e clicca Backup (sotto Database).
Salva il file .zip e copialo sul nuovo server (ad esempio con scp o rsync): ```bash scp em-backup-2026-06-02-1430.zip user@new-server:/path/to/

Installa i Prerequisiti e clona il repository.
Crea .env con DATABASE_URL e JWT_SECRET (vedi Configurazione dell'ambiente).
Crea un database PostgreSQL vuoto e un utente (vedi Configurazione del database).
Installa le dipendenze: npm ci.
Esegui le migrazioni e il seed una volta in modo che un Admin possa accedere. Il ripristino sostituisce questi dati di bootstrap con il backup.
Compila e avvia l'app in modalità produzione (vedi Distribuzione in produzione): ```bash npm run build NODE_ENV=production npm run start
Accedi come admin utilizzando il file initial-admin-credentials.txt riservato al proprietario, cambia la password temporanea ed elimina il file delle credenziali.
Apri Admin (/dashboard/users), fai clic su Restore (sotto Database), seleziona il file .zip dal vecchio server, inserisci la tua password di amministratore e conferma.
Riavvia l'applicazione se era già in esecuzione, in modo che rilevi i dati ripristinati.

Apri prisma/schema.prisma e aggiungi il campo al modello desiderato: ```prisma model Engagement { id String @id @default(uuid()) codeName String focus String? // new field ... }
Ogni modifica a prisma/schema.prisma deve essere seguita da: ```bash npx prisma migrate dev --name describe_your_change

Autenticazione e Account: L'account predefinito admin viene generato tramite il seed di Prisma. I ruoli Admin hanno accesso completo in creazione/modifica/eliminazione a tutti i record. I ruoli User possono creare, modificare ed eliminare findings e screenshot; tutte le altre entità (engagements, clients, contacts, operators) sono di sola lettura per gli utenti. Ogni pagina della dashboard aggiorna la sessione rispetto al database prima di leggere dati riservati. Solo gli admin possono accedere alla pagina Admin (/dashboard/users), gestire gli account, modificare il colore di evidenziazione a livello di applicazione ed eseguire backup, ripristino o reset del database. Backup, ripristino e reset richiedono una riconferma della password. La creazione di un backup è una Server Action; il download dal browser utilizza GET /api/db/backup?file=… con la sessione Admin e una concessione firmata di cinque minuti in un cookie HttpOnly.
Gestione delle Sessioni: Le sessioni utilizzano JWT jose memorizzati in cookie HttpOnly, SameSite=Lax e una riga Session corrispondente lato server che il logout revoca. La scadenza del cookie è intenzionalmente omessa per mantenere il comportamento di sessione del browser; sia il token firmato che il record nel database scadono dopo un giorno. L'ammissione transazionale mantiene al massimo dieci sessioni attive per account.
Sicurezza dell'Applicazione:
- Il Next.js Edge Proxy (src/proxy.ts) applica i controlli di sessione e la rotazione della password ogni 90 giorni su tutte le route protette.
- Le Next.js Server Actions riducono il rischio di CSRF grazie alle protezioni same-origin integrate.
- Prisma mitiga automaticamente l'SQL injection parametrizzando tutte le query.
- React mitiga l'XSS eseguendo automaticamente l'escape degli elementi HTML al render.
- Gli screenshot sono memorizzati con permessi di solo proprietario e quote aggregate/per-finding limitate. L'eliminazione utilizza marker pendenti recuperabili; all'avvio della dashboard, durante gli upload e i backup, i file su disco vengono riconciliati con i riferimenti nel database, con i fallimenti di pulizia registrati nell'output di audit, errori dettagliati nei log del server e un avviso mostrato agli amministratori. La riconciliazione fallita della dashboard ritenta al massimo una volta al minuto per processo; upload e backup validano comunque immediatamente lo storage. La route autenticata /api/uploads previene l'IDOR e restituisce risposte no-store.

endReporting

outbrief

objectives

targets

exclusions

notes

operators

contacts

trustedAgents

findings

findingContexts

createdAt

updatedAt

engagement-mgr

Più Popolari

Scrittura dei risultati e produzione di report PDF

Sicurezza del reporting e deployment

Verifica```bash

Prerequisiti

Configurazione dell'ambiente

Configurazione del Database

Sviluppo

Installazione

Configurazione automatizzata (Ubuntu)

Note di aggiornamento per la configurazione rafforzata e i backup

Configurazione manuale

Esecuzione dell'Applicazione

Deployment in produzione

Requisiti

Passaggi di deployment

Checklist di produzione

Credenziali predefinite

Migrazione del server (Backup / Restore / Reset)

Piano di implementazione e architettura

Stack tecnologico

Schema del database

Aggiunta di nuovi campi

Architettura di Sicurezza