| Forbidden patterns | ✅ |
| Injection SQL | ✅ |
| Auth/Authz | ✅ |
| Fuite données | ⚠️ |
| Validation | ❌ |
Barrières primaires identifiées : HSM (clé privée non exportable), trigger d’immutabilité PD-272 (INSERT-only/anti-UPDATE), scellement global envelopeSeal (intégrité payload). | |
| Effet defense-in-depth : plusieurs écarts sont en couche applicative (validation/OCSP/verif) mais S-01 compromet une barrière de confiance primaire (authenticité du signataire). | |
| Verdict : ❌ NON_CONFORME | |
| ## Audit des forbidden patterns | |
| Pattern interdit | Recherché |
| ------------------ | ----------- |
privateKey en clair dans payload | scan code + scan heuristique |
secretKey en clair dans payload | scan code + scan heuristique |
sessionToken en clair dans payload | scan code + scan heuristique |
hmacSecret en clair dans payload | scan code + scan heuristique |
dek en clair dans payload | scan code + scan heuristique |
| ## Tentatives de bypass | |
| Attaque | Résultat |
| --------- | ---------- |
Injection SQL ("'; DROP TABLE--") | Non applicable / non exploitable |
| Bypass auth (requête sans JWT) | Non testé (hors périmètre code fourni) |
| Cross-access JWT A/B | Non testé (hors périmètre code fourni) |
| Substitution de sceau inter-enveloppes | Échec attendu |
| Forged envelope avec certificat auto-signé | Bypass réussi (critique) |
| ## Vulnérabilités identifiées | |
| ID | Description |
| ---- | ------------- |
| S-01 | Bypass d’authenticité du signataire : OfflineVerificationService.verify() accepte des chaînes non ancrées par défaut (trustedRoots optionnel), et la validation de chaîne n’impose pas de trust anchor obligatoire. Un attaquant peut générer sa propre paire EC P-384, signer un faux payload, injecter son cert dans certificateChain, obtenir valid=true en MODE_A. |
| S-02 | Mode B non conforme / contournable : la “vérification online constitutive” n’effectue pas réellement de requêtes OCSP/CRL live ; elle se limite essentiellement à des checks locaux (période de validité cert). Cela permet d’accepter un certificat potentiellement révoqué si dates valides. |
| S-03 | Risque SSRF sur OCSP responder URL : fetch() sur ocspResponderUrl sans allowlist/denylist/contrôle schéma/réseau. Si la source d’URL provient d’un certificat/AIA non fiable, pivot possible vers endpoints internes. |
| S-04 | Parsing OCSP fragile (fail-open logique) : décodage ASN.1 “heuristique” par inspection d’octets (extractOcspStatus/extractCertStatus) au lieu d’un parseur strict. Réponse forgée peut influencer le statut (good/revoked/unknown). |
| ## Recommandations | |
- Imposer trustedRoots obligatoire en vérification (Mode A/B) et échouer si absent ; valider explicitement la chaîne complète jusqu’à ancre de confiance. | |
- En Mode B, implémenter une vraie vérification OCSP/CRL live (requêtes réseau + validation de signature de réponse OCSP + fraîcheur temporelle), sinon retourner valid=false. | |
- Ajouter une politique anti-SSRF OCSP : schéma https only, allowlist domaines OCSP, blocage IP privées/link-local, résolution DNS sécurisée. | |
- Remplacer le parsing OCSP artisanal par @peculiar/asn1-ocsp (ou équivalent strict) et rejeter toute réponse non conforme DER/ASN.1. | |
| - Ajouter tests adversariaux bloquants : “self-signed attacker cert should fail”, “MODE_B must fail if OCSP live unavailable/invalid”, “AIA internal URL blocked”. | |