engagement-mgr — Engagement Manager est une application web pour le suivi des engagements en sécurité offensive. Elle dispose d'une interface moderne, construite avec Next.js, Prisma et PostgreSQL. | Kitploit

Espace de rédaction : ouvrez le lien Write & review d'un constat pour l'édition Markdown et un aperçu sécurisé. Les brouillons privés sont enregistrés après 15 secondes d'inactivité ou à la demande ; ils sont stockés sur le serveur, et non dans le stockage local du navigateur. Récupérez explicitement un brouillon après l'avoir rouvert. Les enregistrements en conflit préservent le texte de l'éditeur et nécessitent une comparaison avec la révision actuelle. Les révisions de texte peuvent être inspectées et restaurées ; la restauration ne restaure pas les preuves supprimées.
Modèles réutilisables : recherchez une formulation approuvée par titre, catégorie ou sévérité. Les utilisateurs peuvent proposer des modèles ; les administrateurs les sélectionnent et les approuvent. L'application d'un modèle crée un constat d'engagement indépendant avec des observations, des hôtes affectés et des preuves vides, ce qui évite la réutilisation accidentelle de la preuve d'un autre engagement.
Preuves : téléversez ou collez jusqu'à quatre images PNG/JPEG ensemble, ajoutez des légendes et modifiez la légende/l'ordre dans l'espace de rédaction. Les images sont décodées, dépouillées de leurs métadonnées, redimensionnées à au plus 2000 × 2000 pixels et enregistrées au format PNG. Conservez les preuves médico-légales originales séparément si les octets ou métadonnées d'origine sont nécessaires.
Révision : faites passer les constats complets de Draft/Changes Requested à Ready. Un réviseur assigné ou un administrateur, autre que l'auteur actuel, peut approuver ou demander des modifications. Les administrateurs assignent les réviseurs. Les modifications de texte, de preuves et de révisions restaurées annulent l'approbation. La file de révision, les commentaires, la liste de contrôle de préparation et l'historique des révisions facilitent la transmission.
Rapports PDF : choisissez un engagement dans Reports, rédigez son résumé exécutif, sélectionnez/ordonnez les constats et enregistrez les paramètres. Les brouillons de PDF sont visiblement marqués. Seuls les administrateurs peuvent émettre un PDF final, et chaque constat sélectionné doit être approuvé et passer les contrôles de préparation. Chaque version émise stocke son PDF, un instantané de contenu explicite et un condensé SHA-256 ; les modifications ultérieures ne le régénèrent pas. La suppression de l'engagement parent supprime toujours ses rapports via le cycle de vie existant.
Imports de scanners : prévisualisez un export, sélectionnez les constats, puis confirmez. Les imports n'exécutent jamais de scans ni ne contactent les cibles. L'empreinte côté serveur ignore les constats correspondants dans le même engagement ; tous les nouveaux enregistrements commencent en Draft et doivent être vérifiés par un opérateur.

Famille de scanner/export	Export accepté
Burp Suite	Issues XML, y compris la DTD de schéma interne inerte
Nessus / Tenable	Nessus v2 XML (`.nessus`)
Nmap	XML ; les ports ouverts et leur sortie de script deviennent des observations informatives, et non des vulnérabilités déduites
OpenVAS / Greenbone	Rapport XML natif ou GMP `get_reports_response`
OWASP ZAP	Rapport JSON traditionnel avec sites et alertes
Nuclei	JSON Lines (`-jsonl`)
Qualys	XML de résultat de scan (structure `SCAN/IP`), et non le format distinct de l'API de détection d'hôtes
Semgrep / CodeQL et autres producteurs SARIF	Exécutions, règles et résultats SARIF JSON

`npm test` utilise le mode de test non isolé de Node avec `tsx` afin que les cas de test TypeScript individuels s'exécutent, plutôt que de simplement signaler le succès du sous-processus de fichier. Gardez les totaux d'assertions explicites visibles dans la CI.

Les régressions de base de données et de navigateur nécessitent une **base de données locale dédiée nommée `reporting_tests`**, avec les migrations appliquées. Elles créent et suppriment leurs propres lignes de fixture ; ne pointez jamais ces tests vers une base de données d'application. Définissez `REPORTING_TEST_DATABASE_URL` vers cette base de données de test, puis exécutez :```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` fournit `pg_dump`, `pg_restore` et `psql` ; `zip` crée les archives de sauvegarde. L'extraction de restauration est gérée par l'application avec une validation stricte des entrées et de la taille.

L'installation des paquets ne garantit pas toujours que PostgreSQL soit en cours d'exécution. Démarrez et activez le service avant de créer des rôles ou de lancer l'application :```bash
sudo systemctl enable --now postgresql
sudo systemctl status postgresql --no-pager

| Variable | Requis | Notes |
|----------|----------|-------|
| `DATABASE_URL` | Oui | Chaîne de connexion PostgreSQL. Prisma utilise le paramètre de requête `schema=public`. La sauvegarde et la restauration utilisent un fichier pgpass temporaire accessible uniquement au propriétaire afin que le mot de passe ne soit pas placé dans les arguments du sous-processus. |
| `JWT_SECRET` | Oui en production | Doit comporter au moins **32 caractères**. L'application refuse de démarrer en production sans celui-ci. Sa rotation invalide toutes les sessions existantes. |
| `TRUST_PROXY` | Non | Définir à `1` (ou `true`) uniquement lorsque l'application se trouve derrière un reverse proxy qui **écrase** `X-Forwarded-For` / `X-Real-IP` et `X-Forwarded-Host`. Les vérifications d'origine de connexion utilisent `X-Forwarded-Host` lorsqu'il est présent dans ce mode ; il doit contenir un seul hôte public, y compris un port non par défaut le cas échéant. Sinon, le proxy doit préserver l'en-tête `Host` public. C'est la topologie de production requise pour des limites de connexion précises par source. Lorsque cette variable n'est pas définie, les en-têtes sont ignorés pour empêcher l'usurpation et la connexion utilise un budget de repli partagé d'une minute plus élevé afin qu'un client ne puisse pas imposer un verrouillage global de 15 minutes. |
| `ALLOWED_DEV_ORIGINS` | Non | **Développement uniquement.** Noms d'hôtes supplémentaires autorisés à charger les ressources `/_next` (séparés par des virgules). Les adresses IPv4 actuelles du réseau local du serveur sont autorisées automatiquement. Utilisez ceci pour un nom DNS stable. Les builds de production ignorent ceci. |

Générez un secret fort :```bash
openssl rand -base64 32

### Production

Utilisez un utilisateur de base de données dédié avec le **principe du moindre privilège** — n'accordez pas les droits `CREATEDB` ni les droits de superutilisateur :```bash
sudo -u postgres createuser --pwprompt em_app
sudo -u postgres createdb --owner=em_app engagement_manager

Le script installe les prérequis, démarre et active le service PostgreSQL, demande un nom d'utilisateur et un mot de passe de base de données, écrit un `.env` en `chmod 600`, crée le rôle et la base de données PostgreSQL, applique les migrations et initialise le compte administrateur par défaut. Le mode production exécute également `npm run build` et n'affiche que la commande de démarrage en production. Il n'installe pas Node.js à partir d'un script shell distant ; installez d'abord une version prise en charge de Node.js.

Pour une utilisation sans interface graphique ou en 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

Installez les dépendances Node.js : ```bash npm ci
Exécutez les migrations de base de données pour créer les tables : ```bash npx prisma migrate dev
Initialisez la base de données pour créer le compte Admin par défaut : ```bash npx prisma db seed

Laissez cette fenêtre ouverte. Utilisez l'adresse locale ou réseau qu'elle affiche.

Pour le démarrer vous-même à la place : PostgreSQL doit être en cours d'exécution (`sudo systemctl start postgresql` si nécessaire). Ensuite, démarrez le serveur de développement :```bash
npm run dev

`npm run dev` et `npm start` se lient à `0.0.0.0` afin que l'URL réseau fonctionne sur le LAN. Considérez l'accès LAN comme réservé au laboratoire sur un réseau de confiance. Le mode dev n'est pas durci pour l'internet public.

Si vous ouvrez l'application par **nom d'hôte** (et non par IP) et que le navigateur distant affiche une page blanche, ajoutez ce nom dans `.env` et redémarrez :```bash
ALLOWED_DEV_ORIGINS=dev.office.example

Cloner le dépôt et installer les dépendances : ```bash npm ci
Créez .env avec les valeurs de production (DATABASE_URL, JWT_SECRET ≥ 32 caractères).
Appliquez les migrations de base de données : ```bash npm run db:migrate
Exécutez les vérifications avant déploiement : ```bash npm run audit npm run typecheck npm run build
Démarrez l'application avec NODE_ENV=production : ```bash NODE_ENV=production npm run start

Chemin	Contenu
`engagement-manager-backup/database.dump`	Dump complet PostgreSQL au format personnalisé (schéma, tables, données, énumérations, relations) issu de `pg_dump`
`engagement-manager-backup/uploads/`	Fichiers de capture d'écran de constatations référencés dans la base de données

Connectez-vous en tant qu'utilisateur Admin.
Ouvrez Admin et cliquez sur Backup (sous Database).
Enregistrez le fichier .zip et copiez-le sur le nouveau serveur (par exemple avec scp ou rsync) : ```bash scp em-backup-2026-06-02-1430.zip user@new-server:/path/to/

Installez les Prérequis et clonez le dépôt.
Créez .env avec DATABASE_URL et JWT_SECRET (voir Configuration de l'environnement).
Créez une base de données PostgreSQL vide et un utilisateur (voir Configuration de la base de données).
Installez les dépendances : npm ci.
Exécutez les migrations et le seed une fois afin qu'un Admin puisse se connecter. La restauration remplace ces données d'amorçage par la sauvegarde.
Compilez et démarrez l'application en mode production (voir Déploiement en production) : ```bash npm run build NODE_ENV=production npm run start
Connectez-vous en tant que admin à l'aide du fichier initial-admin-credentials.txt réservé au propriétaire, changez le mot de passe temporaire et supprimez le fichier d'identifiants.
Ouvrez Admin (/dashboard/users), cliquez sur Restore (sous Database), sélectionnez le .zip de l'ancien serveur, saisissez votre mot de passe administrateur et confirmez.
Redémarrez l'application si elle était déjà en cours d'exécution afin qu'elle prenne en compte les données restaurées.

Ouvrez prisma/schema.prisma et ajoutez le champ au modèle souhaité : ```prisma model Engagement { id String @id @default(uuid()) codeName String focus String? // new field ... }
Chaque modification de prisma/schema.prisma doit être suivie de : ```bash npx prisma migrate dev --name describe_your_change

Authentification et comptes : Le compte admin par défaut est généré via le seed Prisma. Les rôles Admin disposent d'un accès complet en création/modification/suppression sur tous les enregistrements. Les rôles User peuvent créer, modifier et supprimer des findings et des captures d'écran ; toutes les autres entités (engagements, clients, contacts, opérateurs) sont en lecture seule pour les utilisateurs. Chaque page du tableau de bord actualise la session auprès de la base de données avant de lire des données confidentielles. Seuls les admins peuvent accéder à la page Admin (/dashboard/users), gérer les comptes, modifier la couleur de surbrillance globale de l'application, et sauvegarder, restaurer ou réinitialiser la base de données. La sauvegarde, la restauration et la réinitialisation nécessitent une re-confirmation du mot de passe. La création d'une sauvegarde est une Server Action ; le téléchargement depuis le navigateur utilise GET /api/db/backup?file=… avec la session Admin et une autorisation signée de cinq minutes dans un cookie HttpOnly.
Gestion des sessions : Les sessions utilisent des JWT jose stockés dans des cookies HttpOnly, SameSite=Lax, avec une ligne Session correspondante côté serveur que la déconnexion révoque. L'expiration du cookie est volontairement omise pour conserver le comportement de session du navigateur ; le jeton signé et l'enregistrement en base expirent tous deux après un jour. L'admission transactionnelle conserve au maximum dix sessions actives par compte.
Sécurité applicative :
- Le proxy Edge de Next.js (src/proxy.ts) applique les vérifications de session et la rotation des mots de passe tous les 90 jours sur toutes les routes protégées.
- Les Server Actions de Next.js réduisent le risque de CSRF grâce aux protections same-origin intégrées.
- Prisma atténue automatiquement les injections SQL en paramétrant toutes les requêtes.
- React atténue les XSS en échappant automatiquement les éléments HTML au rendu.
- Les captures d'écran sont stockées avec des permissions réservées au propriétaire et des quotas agrégés/par finding limités. La suppression utilise des marqueurs en attente récupérables ; au démarrage du tableau de bord, lors des uploads et des sauvegardes, les fichiers sur disque sont réconciliés avec les références en base, les échecs de nettoyage étant consignés dans la sortie d'audit, les erreurs détaillées dans les logs serveur, et un avertissement affiché aux administrateurs. Une réconciliation de tableau de bord échouée est retentée au maximum une fois par minute et par processus ; les uploads et les sauvegardes valident toujours le stockage immédiatement. La route authentifiée /api/uploads empêche les IDOR et renvoie des réponses no-store.

endReporting

outbrief

objectives

targets

exclusions

notes

operators

contacts

trustedAgents

findings

findingContexts

createdAt

updatedAt

engagement-mgr

Populaires

Rédaction des constats et production de rapports PDF

Sécurité du reporting et déploiement

Vérification```bash

Prérequis

Configuration de l'environnement

Configuration de la base de données

Développement

Installation

Configuration automatisée (Ubuntu)

Notes de mise à niveau pour la configuration renforcée et les sauvegardes

Configuration manuelle

Exécution de l'application

Déploiement en production

Prérequis

Étapes de déploiement

Liste de vérification pour la production

Identifiants par défaut

Migration de serveur (Backup / Restore / Reset)

Plan d'implémentation et architecture

Stack technologique

Schéma de base de données

Ajout de nouveaux champs

Architecture de sécurité

engagement-mgr

Populaires

Engagement Manager

Captures d'écran

Table des matières

Rédaction des constats et production de rapports PDF

Sécurité du reporting et déploiement

Vérification```bash

Prérequis

Configuration de l'environnement

Configuration de la base de données

Développement

Installation

Configuration automatisée (Ubuntu)

Notes de mise à niveau pour la configuration renforcée et les sauvegardes

Configuration manuelle

Exécution de l'application

Déploiement en production

Prérequis

Étapes de déploiement

Liste de vérification pour la production

Identifiants par défaut

Migration de serveur (Backup / Restore / Reset)

Plan d'implémentation et architecture

Stack technologique

Schéma de base de données

Ajout de nouveaux champs

Architecture de sécurité