Aller au contenu

BREACH Attack on HTTP Compression

Attaque BREACH sur la compression HTTP

Description

Cette vulnérabilité indique que le serveur est vulnérable aux attaques BREACH, qui exploitent la compression HTTP pour extraire des informations sensibles à partir de réponses HTTPS chiffrées en mesurant la taille des réponses compressées.

L'attaque BREACH (Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext) se produit lorsque des secrets (jetons CSRF, données de session) et des entrées utilisateur apparaissent dans la même réponse HTTP compressée. Les algorithmes de compression créent des modèles détectables qui révèlent des informations sur le secret.

Comment ça marche :

  1. Un JavaScript malveillant effectue des requêtes vers le site cible en utilisant les cookies de la victime
  2. L'attaquant injecte des suppositions via des paramètres d'URL ou des données de formulaire
  3. Lorsque la supposition correspond à une partie d'un secret, la réponse se compresse mieux (taille plus petite)
  4. En mesurant les tailles des réponses, l'attaquant extrait les secrets de manière incrémentielle

Prérequis :

  • Compression HTTP activée (gzip/deflate)
  • Entrée utilisateur reflétée dans le corps des réponses HTTP
  • Des secrets présents dans les mêmes réponses que les entrées utilisateur
  • Requêtes multiples autorisées

Scénario d'exemple : Une application web inclut un jeton CSRF dans une réponse JSON avec des termes de recherche fournis par l'utilisateur. Un attaquant crée des requêtes avec différents termes de recherche qui correspondent partiellement au modèle du jeton CSRF, en observant les tailles des réponses compressées pour extraire progressivement l'intégralité du jeton.

L'attaque peut extraire des secrets avec des milliers de requêtes en moins d'une minute, ce qui conduit au détournement de session, au contournement CSRF et à l'exposition de données sensibles.

Recommandation

Pour atténuer les attaques BREACH, mettez en œuvre les stratégies suivantes :

Atténuations principales :

  1. Désactiver la compression HTTP pour les pages sensibles - Désactivez gzip/deflate pour les réponses contenant des secrets et ne compressez que les ressources statiques, et non le contenu dynamique contenant des secrets.

  2. Séparer les secrets de l'entrée utilisateur - Assurez-vous que les données sensibles n'apparaissent jamais dans la même réponse HTTP que les entrées contrôlées par l'utilisateur. Utilisez des points de terminaison distincts pour les opérations sensibles qui ne répercutent pas les entrées de l'utilisateur.

  3. Rendez les secrets aléatoires à chaque requête - Générez fréquemment de nouveaux jetons CSRF et effectuez une rotation régulière des identifiants de session pour limiter la fenêtre d'opportunité des attaquants.

Exemples d'implémentation :

# Désactiver la compression pour les points de terminaison sensibles
location /api/csrf { gzip off; }
location /user/ { gzip off; }

# Flask : Désactiver le middleware de compression
app.config['COMPRESS_MIMETYPES'] = []

# Django : Supprimez GZipMiddleware du paramètre MIDDLEWARE
MIDDLEWARE = [
    # ... d'autres middleware, mais PAS :
    # 'django.middleware.gzip.GZipMiddleware',
]

Défenses supplémentaires :

  • Ajoutez un remplissage (padding) aléatoire aux réponses contenant des secrets.
  • Implémentez la limitation de débit (10 requêtes par minute pour les points de terminaison d'entrée utilisateur).
  • Surveillez les modèles de requêtes suspects indiquant des attaques potentielles.
  • Utilisez les méthodes de protection CSRF de cookie à double soumission (double-submit cookie).

Liens

Normes

  • SOC2_CONTROLS:
    • CC_6_7
    • CC_7_1
  • CCPA:
    • CCPA_1798_150
  • GDPR:
    • ART_32
  • PCI_STANDARDS:
    • REQ_4_1
    • REQ_6_5
    • REQ_11_3
  • HIPAA_CONTROLS:
    • SECURITY252
    • SECURITY212
    • SECURITY213