Cloudflare protège-t-il contre les attaques BREACH?
Je sais que l'activation de la compression http rendrait un serveur vulnérable aux attaques BREACH. Nous avons donc désactivé la compression côté serveur, testé et tout s'est bien passé.
Ensuite, nous avons implémenté CloudFlare pour l'instance. Nous avons effectué à nouveau l'analyse de sécurité SSL et avons constaté que l'application utilise gzip et qu'elle est donc vulnérable à la violation. À partir d'une inspection détaillée, nous avons identifié que la compression est activée par CloudFlare.
Même s'ils prétendent avoir intégré le mécanisme prévention des attaques BREACH , les gens de Security SE prétend que BREACH peut être exploité .
Ensuite, à l'étape suivante, nous avons désactivé la compression Brotli offerte par CloudFlare. Mais lors des tests, le scanner a de nouveau détecté une compression. Maintenant, nous sommes coincés. Je comprends que le trafic du navigateur vers CloudFlare est compressé avec Brotli et CloudFlare -> Le serveur restera non compressé (puisque nous avons désactivé gzip du côté serveur). Cela atténue-t-il réellement le problème d'attaque BREACH?
Sinon, quelle recommandation proposez-vous?
Citant la réponse du support de la communauté cloudflare:
Je ne sais pas pourquoi un outil de rapport tiers l'indiquerait, mais d'après mon expérience, il est beaucoup plus probable que l'outil soit mal conçu (vérifier la capacité de demander du contenu gzip par exemple plutôt que d'essayer d'exploiter la vulnérabilité) . Cependant, s'ils croient avoir un exploit réel, Cloudflare participe au programme HackerOne pour une divulgation responsable et ils peuvent le signaler là-bas.
La deuxième question est "Pourquoi mon contenu est-il compressé via Cloudflare?" La réponse à cela est Cloudflare supportera par défaut la compression lorsqu'un client le demandera. Nous prenons en charge gzip par défaut et éventuellement Brotli. Vous avez désactivé la compression Brotli, mais notre comportement par défaut reste en place sauf s'il est remplacé par des directives de contrôle de cache explicites. Vous pouvez inclure une directive no-transform dans vos en-têtes de cache pour empêcher Cloudflare d'appliquer la compression.
Donc, je conclus que la réponse du scanner était un faux positif et marquait le problème comme résolu.
Référence:
Les scanners de vulnérabilité peuvent être erronés. Ils détectent souvent uniquement les circonstances entourant une vulnérabilité, comme la compression, sans réellement tester pour voir si cette circonstance est vulnérable. A vous de vérifier la validité de chaque détection présentée par votre scanner. Pour ce faire, vous devez lancer une attaque BREACH contre CloudFlare. Veuillez ne pas le faire sans l'avoir préalablement autorisé avec leur équipe de sécurité. Vous seriez considéré comme une menace réelle si vous effectuiez des tests de pénétration sans autorisation. Ceci est illégal dans la plupart des juridictions.
Cette question ne peut être répondue que par leur équipe d'assistance. Dans ce cas, vous avez déjà leur réponse. Ils ont mis en place une atténuation et l'ont vérifiée en interne.
Cloudflare a corrigé tous les serveurs contre ces vulnérabilités. De plus, le Cloudflare WAF a des règles pour atténuer plusieurs de ces vulnérabilités, notamment Heartbleed et Shellshock.
Fermez cet élément dans votre scanner en tant que faux positif.