engagement-mgr — Engagement Manager ist eine Webanwendung zur Verfolgung von Offensive-Security-Engagements. Sie bietet eine moderne Benutzeroberfläche, die mit Next.js, Prisma und PostgreSQL erstellt wurde. | Kitploit

Schreib-Workspace: Öffnen Sie den Link Write & review eines Findings für die Markdown-Bearbeitung und eine sichere Vorschau. Private Entwürfe werden nach 15 Sekunden Inaktivität oder auf Anfrage gespeichert; sie werden auf dem Server gespeichert, nicht im lokalen Speicher des Browsers. Stellen Sie einen Entwurf nach dem erneuten Öffnen explizit wieder her. Bei Speicherkonflikten bleibt der Text des Editors erhalten und es ist ein Vergleich mit der aktuellen Revision erforderlich. Textrevisionen können eingesehen und wiederhergestellt werden; die Wiederherstellung stellt gelöschte Nachweise nicht wieder her.
Wiederverwendbare Vorlagen: Durchsuchen Sie genehmigte Formulierungen nach Titel, Kategorie oder Schweregrad. Benutzer können Vorlagen vorschlagen; Administratoren kuratieren und genehmigen sie. Das Anwenden einer Vorlage erstellt ein unabhängiges Engagement-Finding mit leeren Beobachtungen, betroffenen Hosts und Nachweisen, wodurch eine versehentliche Wiederverwendung des Nachweises eines anderen Engagements verhindert wird.
Nachweise: Laden Sie bis zu vier PNG/JPEG-Bilder zusammen hoch oder fügen Sie sie ein, fügen Sie Bildunterschriften hinzu und bearbeiten Sie Bildunterschrift/Reihenfolge im Schreib-Workspace. Bilder werden dekodiert, von Metadaten befreit, auf höchstens 2000 × 2000 Pixel skaliert und als PNG gespeichert. Bewahren Sie forensische Originalnachweise separat auf, falls Originalbytes oder Metadaten erforderlich sind.
Review: Senden Sie vollständige Findings von Draft/Changes Requested an Ready. Ein zugewiesener Reviewer oder Administrator, der nicht der aktuelle Autor ist, kann genehmigen oder Änderungen anfordern. Administratoren weisen Reviewer zu. Änderungen an Text, Nachweisen und wiederhergestellten Revisionen heben die Genehmigung auf. Die Review-Warteschlange, Kommentare, Readiness-Checkliste und Revisionshistorie unterstützen die Übergabe.
PDF-Berichte: Wählen Sie ein Engagement in Reports, schreiben Sie dessen Executive Summary, wählen/ordnen Sie Findings und speichern Sie die Einstellungen. Entwurfs-PDFs sind sichtbar gekennzeichnet. Nur Administratoren können ein finales PDF ausstellen, und jedes ausgewählte Finding muss genehmigt sein und die Readiness-Prüfungen bestehen. Jede ausgestellte Version speichert ihr PDF, einen expliziten Inhalts-Snapshot und einen SHA-256-Digest; spätere Bearbeitungen regenerieren ihn nicht. Das Löschen des übergeordneten Engagements löscht weiterhin seine Berichte über den bestehenden Lebenszyklus.
Scanner-Importe: Zeigen Sie eine Vorschau eines Exports an, wählen Sie Findings aus und bestätigen Sie dann. Importe führen niemals Scans aus oder kontaktieren Ziele. Serverseitiges Fingerprinting überspringt übereinstimmende Findings im selben Engagement; alle neuen Datensätze beginnen als Draft und müssen von einem Operator geprüft werden.

Scanner-/Export-Familie	Akzeptierter Export
Burp Suite	Issues XML, einschließlich der inerten internen Schema-DTD
Nessus / Tenable	Nessus v2 XML (`.nessus`)
Nmap	XML; offene Ports und deren Skriptausgabe werden zu informativen Beobachtungen, nicht zu abgeleiteten Schwachstellen
OpenVAS / Greenbone	Nativer XML-Bericht oder GMP `get_reports_response`
OWASP ZAP	Traditioneller JSON-Bericht mit Sites und Alerts
Nuclei	JSON Lines (`-jsonl`)
Qualys	Scan-Ergebnis-XML (`SCAN/IP`-Struktur), nicht das separate Host-Detection-API-Format
Semgrep / CodeQL und andere SARIF-Produzenten	SARIF-JSON-Runs, Regeln und Ergebnisse

`npm test` verwendet den nicht isolierten Testmodus von Node mit `tsx`, damit die einzelnen TypeScript-Testfälle ausgeführt werden, anstatt lediglich den Erfolg des Datei-Subprozesses zu melden. Halten Sie die expliziten Assertion-Gesamtzahlen in CI sichtbar.

Datenbank- und Browser-Regressionstests erfordern eine **dedizierte lokale Datenbank namens `reporting_tests`**, auf die Migrationen angewendet wurden. Sie erstellen und löschen ihre eigenen Fixture-Zeilen; richten Sie diese Tests niemals auf eine Anwendungsdatenbank. Setzen Sie `REPORTING_TEST_DATABASE_URL` auf diese Testdatenbank und führen Sie dann aus:```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` stellt `pg_dump`, `pg_restore` und `psql` bereit; `zip` erstellt Backup-Archive. Die Wiederherstellungsextraktion wird von der Anwendung mit strikter Validierung von Einträgen und Größe durchgeführt.

Die Installation der Pakete führt nicht immer dazu, dass PostgreSQL läuft. Starten und aktivieren Sie den Dienst, bevor Sie Rollen erstellen oder die App starten:```bash
sudo systemctl enable --now postgresql
sudo systemctl status postgresql --no-pager

| Variable | Erforderlich | Hinweise |
|----------|----------|-------|
| `DATABASE_URL` | Ja | PostgreSQL-Verbindungszeichenfolge. Prisma verwendet den Query-Parameter `schema=public`. Backup und Wiederherstellung verwenden eine temporäre pgpass-Datei, auf die nur der Eigentümer Zugriff hat, damit das Passwort nicht in Subprozess-Argumenten platziert wird. |
| `JWT_SECRET` | Ja in der Produktion | Muss mindestens **32 Zeichen** lang sein. Die App verweigert den Start in der Produktion ohne dieses. Eine Rotation dieses Werts macht alle bestehenden Sitzungen ungültig. |
| `TRUST_PROXY` | Nein | Auf `1` (oder `true`) setzen, nur wenn die App hinter einem Reverse-Proxy steht, der `X-Forwarded-For` / `X-Real-IP` und `X-Forwarded-Host` **überschreibt**. Login-Origin-Prüfungen verwenden `X-Forwarded-Host`, wenn in diesem Modus vorhanden; es muss einen öffentlichen Host enthalten, einschließlich eines nicht standardmäßigen Ports, falls verwendet. Andernfalls muss der Proxy den öffentlichen `Host`-Header beibehalten. Dies ist die erforderliche Produktionstopologie für genaue Login-Limits pro Quelle. Wenn nicht gesetzt, werden Header ignoriert, um Spoofing zu verhindern, und der Login verwendet ein höheres gemeinsames Ein-Minuten-Fallback-Budget, damit ein Client keine 15-minütige globale Sperre verhängen kann. |
| `ALLOWED_DEV_ORIGINS` | Nein | **Nur für die Entwicklung.** Zusätzliche Hostnamen, die `/_next`-Assets laden dürfen (kommagetrennt). Die aktuellen LAN-IPv4-Adressen des Servers sind automatisch erlaubt. Verwenden Sie dies für einen stabilen DNS-Namen. Produktions-Builds ignorieren dies. |

Ein starkes Secret generieren:```bash
openssl rand -base64 32

### Produktion

Verwenden Sie einen dedizierten Datenbankbenutzer mit **minimalen Rechten** — gewähren Sie keine `CREATEDB`- oder Superuser-Rechte:```bash
sudo -u postgres createuser --pwprompt em_app
sudo -u postgres createdb --owner=em_app engagement_manager

Das Skript installiert Voraussetzungen, startet und aktiviert den PostgreSQL-Dienst, fordert einen Datenbank-Benutzernamen und ein Passwort an, schreibt eine `chmod 600` `.env`, erstellt die PostgreSQL-Rolle und -Datenbank, wendet Migrationen an und legt das Standard-Admin-Konto an. Der Produktionsmodus führt zusätzlich `npm run build` aus und gibt nur den Produktionsstartbefehl aus. Es installiert Node.js nicht über ein Remote-Shell-Skript; installieren Sie zuerst eine unterstützte Node.js-Version.

Für Headless- oder CI-Nutzung:```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

Installieren Sie die Node.js-Abhängigkeiten: ```bash npm ci
Datenbankmigrationen ausführen, um die Tabellen zu erstellen: ```bash npx prisma migrate dev
Befülle die Datenbank, um das Standard-Admin-Konto zu erstellen: ```bash npx prisma db seed

Lass dieses Fenster geöffnet. Verwende die Local- oder Network-Adresse, die es ausgibt.

Um es stattdessen selbst zu starten: PostgreSQL muss laufen (`sudo systemctl start postgresql`, falls nötig). Starte dann den Entwicklungsserver:```bash
npm run dev

`npm run dev` und `npm start` binden `0.0.0.0`, damit die Network-URL im LAN funktioniert. Behandle den LAN-Zugriff als reine Laborumgebung in einem vertrauenswürdigen Netzwerk. Der Dev-Modus ist nicht für das öffentliche Internet gehärtet.

Wenn du die App über den **Hostnamen** (nicht die IP) öffnest und der entfernte Browser eine leere weiße Seite anzeigt, füge diesen Namen zu `.env` hinzu und starte neu:```bash
ALLOWED_DEV_ORIGINS=dev.office.example

Repository klonen und Abhängigkeiten installieren: ```bash npm ci
Erstellen Sie .env mit Produktionswerten (DATABASE_URL, JWT_SECRET ≥ 32 Zeichen).
Wenden Sie Datenbankmigrationen an: ```bash npm run db:migrate
Führen Sie Pre-Deploy-Prüfungen durch: ```bash npm run audit npm run typecheck npm run build
Starten Sie die Anwendung mit NODE_ENV=production: ```bash NODE_ENV=production npm run start

Pfad	Inhalt
`engagement-manager-backup/database.dump`	Vollständiger PostgreSQL-Dump im Custom-Format (Schema, Tabellen, Daten, Enums, Beziehungen) von `pg_dump`
`engagement-manager-backup/uploads/`	In der Datenbank referenzierte Screenshot-Dateien von Findings

Melden Sie sich als Admin-Benutzer an.
Öffnen Sie Admin und klicken Sie auf Backup (unter Database).
Speichern Sie die .zip-Datei und kopieren Sie sie auf den neuen Server (zum Beispiel mit scp oder rsync): ```bash scp em-backup-2026-06-02-1430.zip user@new-server:/path/to/

Installiere die Voraussetzungen und klone das Repository.
Erstelle .env mit DATABASE_URL und JWT_SECRET (siehe Umgebungskonfiguration).
Erstelle eine leere PostgreSQL-Datenbank und einen Benutzer (siehe Datenbankeinrichtung).
Installiere die Abhängigkeiten: npm ci.
Führe Migrationen und das Seeding einmalig aus, damit sich ein Admin anmelden kann. Die Wiederherstellung ersetzt diese Bootstrap-Daten durch das Backup.
Baue und starte die App im Produktionsmodus (siehe Produktionsbereitstellung): ```bash npm run build NODE_ENV=production npm run start
Melden Sie sich als admin mit den nur für den Eigentümer bestimmten initial-admin-credentials.txt an, ändern Sie das temporäre Passwort und löschen Sie die Datei mit den Anmeldedaten.
Öffnen Sie Admin (/dashboard/users), klicken Sie auf Restore (unter Database), wählen Sie die .zip-Datei vom alten Server aus, geben Sie Ihr Admin-Passwort ein und bestätigen Sie.
Starten Sie die App neu, falls sie bereits lief, damit sie die wiederhergestellten Daten übernimmt.

Öffnen Sie prisma/schema.prisma und fügen Sie das Feld zum gewünschten Modell hinzu: ```prisma model Engagement { id String @id @default(uuid()) codeName String focus String? // new field ... }
Jede Änderung an prisma/schema.prisma muss gefolgt werden von: ```bash npx prisma migrate dev --name describe_your_change

Authentifizierung & Konten: Das Standard-admin-Konto wird über den Prisma-Seed generiert. Admin-Rollen haben vollständigen Lese-, Bearbeitungs- und Löschzugriff auf alle Datensätze. User-Rollen können Findings und Screenshots erstellen, bearbeiten und löschen; alle anderen Entitäten (Engagements, Clients, Kontakte, Operatoren) sind für Benutzer schreibgeschützt. Jede Dashboard-Seite aktualisiert die Sitzung gegen die Datenbank, bevor vertrauliche Daten gelesen werden. Nur Administratoren können auf die Admin-Seite (/dashboard/users) zugreifen, Konten verwalten, die anwendungsweite Hervorhebungsfarbe ändern sowie die Datenbank sichern, wiederherstellen oder zurücksetzen. Sicherung, Wiederherstellung und Zurücksetzen erfordern eine erneute Passwortbestätigung. Das Erstellen einer Sicherung ist eine Server Action; der Browser-Download verwendet GET /api/db/backup?file=… mit der Admin-Sitzung und einer fünfminütigen signierten Berechtigung in einem HttpOnly-Cookie.
Sitzungsverwaltung: Sitzungen verwenden jose-JWTs, die in HttpOnly-, SameSite=Lax-Cookies gespeichert werden, sowie eine übereinstimmende serverseitige Session-Zeile, die beim Logout widerrufen wird. Der Cookie-Ablauf wird absichtlich weggelassen, um das Browser-Sitzungsverhalten beizubehalten; sowohl das signierte Token als auch der Datenbankeintrag laufen nach einem Tag ab. Die transaktionale Zulassung behält höchstens zehn aktive Sitzungen pro Konto bei.
Anwendungssicherheit:
- Der Next.js Edge Proxy (src/proxy.ts) erzwingt Sitzungsprüfungen und eine 90-tägige Passwortrotation über alle geschützten Routen.
- Next.js Server Actions reduzieren das CSRF-Risiko durch integrierte Same-Origin-Schutzmaßnahmen.
- Prisma mindert SQL-Injection automatisch, indem alle Abfragen parametrisiert werden.
- React mindert XSS, indem HTML-Elemente beim Rendern automatisch escaped werden.
- Screenshots werden mit Nur-Eigentümer-Berechtigungen und begrenzten aggregierten/Pro-Finding-Kontingenten gespeichert. Das Löschen verwendet wiederherstellbare Pending-Marker; Dashboard-Start, Uploads und Backups gleichen Disk-Dateien mit Datenbankreferenzen ab, wobei Bereinigungsfehler in der Audit-Ausgabe aufgezeichnet, detaillierte Fehler in den Server-Logs protokolliert und Administratoren eine Warnung angezeigt wird. Fehlgeschlagene Dashboard-Abgleiche werden höchstens einmal pro Minute pro Prozess wiederholt; Uploads und Backups validieren den Speicher weiterhin sofort. Die authentifizierte Route /api/uploads verhindert IDOR und gibt no-store-Antworten zurück.

endReporting

outbrief

objectives

targets

exclusions

notes

operators

contacts

trustedAgents

findings

findingContexts

createdAt

updatedAt

engagement-mgr

Beliebteste

Findings schreiben und PDF-Berichte erstellen

Sicherheit und Deployment für das Reporting

Verifikation```bash

Voraussetzungen

Umgebungskonfiguration

Datenbank-Einrichtung

Entwicklung

Installation

Automatisiertes Setup (Ubuntu)

Upgrade-Hinweise für gehärtetes Setup und Backups

Manuelles Setup

Ausführen der Anwendung

Produktionsbereitstellung

Anforderungen

Bereitstellungsschritte

Produktions-Checkliste

Standard-Anmeldedaten

Server-Migration (Backup / Restore / Reset)

Implementierungsplan & Architektur

Technologie-Stack

Datenbankschema

Hinzufügen neuer Felder

Sicherheitsarchitektur