N’utilisez pas de WAF (pare-feu d’application web)

xguru · 2023-11-15T11:00:02+09:00

Peu de gens s’opposent à l’usage des WAF, c’est pourquoi cet article a été écrit. La plupart des résultats de recherche sur les WAF sont rédigés par des fournisseurs de WAF Les WAF ont été créés aux débuts d’Internet et interceptent toutes les requêtes HTTP en évaluant des centaines d’expressions régulières afin de bloquer les requêtes ressemblant à du SQL, du shellcode, etc. Aux débuts de la cybersécurité, les WAF semblaient être une bonne idée, mais ce n’est plus le cas aujourd’hui En raison des problèmes de performance des WAF, de leur facilité de contournement, de leur danger en tant que vecteur d’attaque et de leur taux élevé de faux positifs, de meilleures technologies de sécurité existent désormais Les performances des WAF sont catastrophiques Les WAF exécutent des centaines d’expressions régulières sur chaque requête, ce qui entraîne une dégradation des performances L’utilisation d’un WAF nécessite une quantité supplémentaire importante de RAM et augmente en moyenne le temps d’upload, la vitesse de traitement des requêtes, l’utilisation CPU, tout en provoquant aussi des blocages erronés Les WAF se contournent facilement Dans la compétition permanente entre les WAF et les attaquants, ce sont les attaquants qui ont l’avantage Il est possible de contourner les règles des WAF à l’aide de syntaxes complexes et de techniques d’encodage Par exemple, l’attaque Log4shell ne peut pas être bloquée par une simple inspection de chaîne, et les attaquants peuvent utiliser diverses techniques de contournement (Log4J Lookup) De plus, si l’on remplit la chaîne d’attaque avec environ 8 Ko de caractères inutiles mais inoffensifs, le WAF devient inutile car il ne peut pas continuer à tout bufferiser en RAM et coupe avant la fin Les WAF constituent un vecteur d’attaque En 2019, Capital One a subi une fuite de 100 millions de demandes de crédit à cause d’une erreur de configuration du WAF L’attaquant aurait trompé le WAF pour qu’il envoie des requêtes au service de métadonnées EC2 et transmette des identifiants permettant de lire des fichiers sensibles sur S3 Autrement dit, une mauvaise configuration du WAF peut être à l’origine d’incidents de sécurité La plupart des WAF sont complexes et souvent développés en closed source, ce qui élargit la surface d’attaque Comme il s’agit de produits « d’entreprise » coûteux, les sociétés y ajoutent souvent des fonctions inutiles pour se démarquer de la concurrence Les principes de sécurité fondamentaux sont souvent négligés dans les produits de sécurité Taux élevé de faux positifs des WAF Au cours des vingt dernières années, les jeux de règles des WAF open source se sont fortement étendus pour détecter les types d’attaques les plus récents. Les WAF propriétaires font probablement la même chose Cela signifie que le nombre de chaînes susceptibles de déclencher un blocage de requête par un WAF augmente sans cesse Chaque nouvelle règle étend ainsi les règles du WAF et augmente le taux de faux positifs Les WAF « de nouvelle génération » affirment résoudre ce problème en vérifiant plusieurs requêtes ou en utilisant des systèmes de réputation IP Cela peut peut-être améliorer les taux de faux positifs (false positive rates), mais pas éliminer complètement le problème À cause des faux positifs, les utilisateurs et les équipes de support peuvent se retrouver sans procédure claire de résolution Alternatives aux WAF Isolation : technique consistant à faire en sorte qu’une partie du système compromise n’affecte pas les autres parties Les navigateurs y parviennent en exécutant tout le code dans des processus sandbox spécialisés, sans accès arbitraire aux cookies, aux mots de passe enregistrés ou aux autres onglets Les microservices ont été conçus avec l’isolation à l’esprit, mais on peut aussi obtenir cela dans un monolithe à l’aide de différentes bibliothèques et de différents langages Immutabilité : suppression de catégories d’attaques grâce à des systèmes de fichiers en lecture seule, des gestionnaires de paquets nécessitant un redémarrage, des sauvegardes en ajout uniquement, etc. Analyse statique : utilisation de requêtes préparées (prepared statements) pour empêcher l’injection SQL et inspection du code via l’analyse statique dans la pipeline CI Sécurité basée sur les capacités : tous les endpoints API n’ont pas besoin d’un accès illimité à la base de données et au système de fichiers ; il faut adopter une approche qui n’accorde que les permissions nécessaires

(macchaffee.com)

21 points par xguru 2023-11-15 | 5 commentaires | Partager sur WhatsApp

Peu de gens s’opposent à l’usage des WAF, c’est pourquoi cet article a été écrit. La plupart des résultats de recherche sur les WAF sont rédigés par des fournisseurs de WAF
Les WAF ont été créés aux débuts d’Internet et interceptent toutes les requêtes HTTP en évaluant des centaines d’expressions régulières afin de bloquer les requêtes ressemblant à du SQL, du shellcode, etc.
Aux débuts de la cybersécurité, les WAF semblaient être une bonne idée, mais ce n’est plus le cas aujourd’hui
En raison des problèmes de performance des WAF, de leur facilité de contournement, de leur danger en tant que vecteur d’attaque et de leur taux élevé de faux positifs, de meilleures technologies de sécurité existent désormais

Les performances des WAF sont catastrophiques

Les WAF exécutent des centaines d’expressions régulières sur chaque requête, ce qui entraîne une dégradation des performances
L’utilisation d’un WAF nécessite une quantité supplémentaire importante de RAM et augmente en moyenne le temps d’upload, la vitesse de traitement des requêtes, l’utilisation CPU, tout en provoquant aussi des blocages erronés

Les WAF se contournent facilement

Dans la compétition permanente entre les WAF et les attaquants, ce sont les attaquants qui ont l’avantage
Il est possible de contourner les règles des WAF à l’aide de syntaxes complexes et de techniques d’encodage
Par exemple, l’attaque Log4shell ne peut pas être bloquée par une simple inspection de chaîne, et les attaquants peuvent utiliser diverses techniques de contournement (Log4J Lookup)
De plus, si l’on remplit la chaîne d’attaque avec environ 8 Ko de caractères inutiles mais inoffensifs, le WAF devient inutile car il ne peut pas continuer à tout bufferiser en RAM et coupe avant la fin

Les WAF constituent un vecteur d’attaque

En 2019, Capital One a subi une fuite de 100 millions de demandes de crédit à cause d’une erreur de configuration du WAF
- L’attaquant aurait trompé le WAF pour qu’il envoie des requêtes au service de métadonnées EC2 et transmette des identifiants permettant de lire des fichiers sensibles sur S3
Autrement dit, une mauvaise configuration du WAF peut être à l’origine d’incidents de sécurité
La plupart des WAF sont complexes et souvent développés en closed source, ce qui élargit la surface d’attaque
- Comme il s’agit de produits « d’entreprise » coûteux, les sociétés y ajoutent souvent des fonctions inutiles pour se démarquer de la concurrence
Les principes de sécurité fondamentaux sont souvent négligés dans les produits de sécurité

Taux élevé de faux positifs des WAF

Au cours des vingt dernières années, les jeux de règles des WAF open source se sont fortement étendus pour détecter les types d’attaques les plus récents. Les WAF propriétaires font probablement la même chose
Cela signifie que le nombre de chaînes susceptibles de déclencher un blocage de requête par un WAF augmente sans cesse
Chaque nouvelle règle étend ainsi les règles du WAF et augmente le taux de faux positifs
Les WAF « de nouvelle génération » affirment résoudre ce problème en vérifiant plusieurs requêtes ou en utilisant des systèmes de réputation IP
- Cela peut peut-être améliorer les taux de faux positifs (false positive rates), mais pas éliminer complètement le problème
À cause des faux positifs, les utilisateurs et les équipes de support peuvent se retrouver sans procédure claire de résolution

Alternatives aux WAF

Isolation : technique consistant à faire en sorte qu’une partie du système compromise n’affecte pas les autres parties
- Les navigateurs y parviennent en exécutant tout le code dans des processus sandbox spécialisés, sans accès arbitraire aux cookies, aux mots de passe enregistrés ou aux autres onglets
- Les microservices ont été conçus avec l’isolation à l’esprit, mais on peut aussi obtenir cela dans un monolithe à l’aide de différentes bibliothèques et de différents langages
Immutabilité : suppression de catégories d’attaques grâce à des systèmes de fichiers en lecture seule, des gestionnaires de paquets nécessitant un redémarrage, des sauvegardes en ajout uniquement, etc.
Analyse statique : utilisation de requêtes préparées (prepared statements) pour empêcher l’injection SQL et inspection du code via l’analyse statique dans la pipeline CI
Sécurité basée sur les capacités : tous les endpoints API n’ont pas besoin d’un accès illimité à la base de données et au système de fichiers ; il faut adopter une approche qui n’accorde que les permissions nécessaires

5 commentaires

2023-11-16

[Ce commentaire a été masqué.]

roxie 2023-11-18

:+1:

devpain 2023-11-16

Avec une combinaison nginx + naxsi, il semble qu’aucun des quelques points ci-dessus ne s’applique.
La gestion du jeu de règles du WAF doit être prise en charge par les développeurs du service.
Sans compréhension du service, les experts en sécurité finissent par appliquer une configuration générique, ce qui entraîne un taux élevé de faux positifs, puis, en supprimant les règles une à une en fonction des demandes, le WAF perd sa fonction d’origine.

nosookja 2023-11-15

Je suis globalement d’accord sur certains points concernant les contournements et les faux positifs, mais j’ai surtout l’impression qu’on aligne des informations peu fiables comme s’il s’agissait de faits. Si j’ai le temps, il faudra aussi que j’aille lire le texte original. En particulier, prendre le cas de CapitalOne comme un problème de WAF montre, à mon avis, que l’auteur du billet comprend assez mal ce qu’est un WAF. Un WAF n’est pas une solution qui corrige fondamentalement une vulnérabilité. Une vulnérabilité introduite dans le code doit être corrigée dans le code, c’est la bonne manière de la résoudre. Mais en pratique, ce n’est pas toujours possible, et c’est pourquoi on a besoin de quelque chose d’approprié en amont pour examiner les entrées suspectes ou malveillantes. Si c’est bien exploité, cela peut devenir un outil vraiment très utile ; si c’est mal exploité, cela peut devenir une lame qui vous blesse vous-même. Cette ambivalence existe toujours avec les outils, mais ici on a l’impression qu’on ne met en avant que leurs mauvais côtés.

xguru 2023-11-15

Les commentaires sur Hacker News contiennent divers avis et contre-arguments à ce sujet. Consultez-les également
https://news.ycombinator.com/item?id=38255004