Que faut-il corriger après un incident lié à un format de fichier ou à un parseur ?
D’après Sécurité informatique
Suivi des incidents et retours d’expérience
Journalisation : Conserver des logs détaillés sur les erreurs de parsing, les plantages liés à la désérialisation, ou les messages d’alerte cryptographiques.
Post-mortem : Après un incident, analyser précisément le vecteur d’attaque.
- Était-ce un parseur vulnérable ?
- Un protocole chiffré mal configuré ?
- Une ZIP bomb ?
Plan d’amélioration continue : Mettre en place des règles de codage sécurisées, adopter des librairies robustes, interdire certaines fonctions jugées risquées.
Shift vers l’“Application-level” Security
Dans les architectures modernes (microservices, API REST, etc. ), la frontière entre couche Présentation et couche Application est parfois floue.
Cependant, on assiste à une consolidation des principes de sécurité :
Chiffrement par défaut : La quasi-totalité des communications se fait sur HTTPS/TLS ou des VPN chiffrés.
JSON Web Tokens (JWT) : Des tokens signés (HMAC ou RSA/ECDSA) pour l’authentification et l’autorisation.
C’est un exemple typique de “présentation” (format, signature) géré souvent au niveau app.
Schemas et validations : Les API REST ou GraphQL imposent parfois des schémas stricts (JSON Schema, etc.) pour empêcher l’injection.