Nous utilisons comme reverse proxy une Application Gateway Azure. Celle-ci propose la mise en place de règles de sécurité proposé par le WAF (Web Application Firewall) notamment des règles OWASP en version 3.2.
Ma question est la suivant : Simplicité fonctionne bien derrière ce genre de Firewall ? Puisqu’en l’activant nous avons des blocages liés à détections de potentielles injections SQL…
Si oui pouvez-vous nous fournir les exclusions à appliquer sur notre WAF pour assurer le bon fonctionnement de Simplicité ?
A ma connaissance nous avons au moins un client qui a mis en place un filtrage via WAF (il y a longtemps) donc il n’y a pas de problème théorique à le faire
Ensuite il faut effectivement regarder de près ce que ça bloque pour voir si c’est légitime dans le contexte et si ce n’est pas légitime mettre les exceptions qui vont bien.
Pouvez vous nous fournir les cas de suspicions d’injections SQL remontées ?
nous avons aussi rencontré quelques difficultés avec nos SecOps lorsqu’ils ont activé la couche WAF sur notre compte AWS.
Nous n’avons pas partagé cette expérience jusqu’à présent car nous avons pu isoler les cas identifiés et mettre en place des solutions spécifiquement liées à notre organisation / politique de sécurité sans mobiliser le support éditeur.
Les problèmes rencontrés concernaient surtout les usages DEV/designer impliquant les canaux /io et plus particulièrement DBAccess et ImportXML.
→ pour ces usages/contexte particuliers, nous avons décidé de désactiver le WAF et de contraindre les équipes DEV d’activer leur VPN.
Les autres usages considérés comme standards sont eux soumis aux contrôles WAF et remontent éventuellement des alertes sur des flux bloqués dans une console dédiée (je ne peux pas détailler plus).
Cependant, si le socle est prédisposé à ne pas déclencher ces cas de blocages et/ou à détecter ces blocages (dans notre confexte, en cas de blocage, le serveur ne reçoit rien du tout et le front UI reçoit un 403 sec sans contenu), ça m’intéresse!
Je ne suis pas sûr de comprendre ce que tu voudrais ici. Si la requête est filtrée en amont on ne peut pas faire grand chose en termes de “détection”.
Sinon les endpoints comme I/O ou Git et les outils dédiés au designer (type la page DBAcces ou ImportXML) sont des features techniques qu’il convient de fermer ou en tout cas de restreindre fortement en PROD (cf. nos guidelines de sécurité: training) => Un filtrage WAF n’a de sens que sur de la PROD, sinon en DEV le designer ne peut pas travailler dans de bonnes conditions…
Les choses qui sont en général détectées comme des cas “suspects” vulnérables à de l’injection SQL sont les filtrages “avancés” (cf. training) car ça ressemble à du SQL mais c’est, en fait, des syntaxes SQL-like qui sont pré-processées avant requêtage et qui ne permettent donc pas d’injecter du SQL (le cas particulier du filtrage sur WebNews avec like '%A%' indiqué par @ewencodes est typiquement un exemple de ce type) => Ce sont donc des faux positifs.
Y-a-t-il d’autres cas identifiés (hors outils de DEV et filtrages avancés) ?
Je ne souhaite pas vampiriser le thread (je n’en suis pas l’auteur) mais je répond juste pour confirmer que nous sommes en phase :
endpoints comme I/O ou Git et les outils dédiés au designer (type la page DBAcces ou ImportXML) sont des features techniques qu’il convient de fermer ou en tout cas de restreindre fortement en PROD
→ c’est bien le cas (usages non filtrés uniquement en DEV via VPN)
Si la requête est filtrée en amont on ne peut pas faire grand chose en termes de “détection”.
→ sur ce point, puisque le backend ne voit rien venir, je voyais plutôt un mécanisme de contrôle front qui alerterait sur un retour ne présentant pas les caractéristiques attendues (un 403 “sec” sans contenu qui n’est pas émis par le backend Simplicité doit pouvoir être identifié). C’est d’ailleurs l’une des précos auprès de nos DEV (sans réinventer quoi que ce soit ni demander au front Simplicité de gérer ce cas) : Le contrôleur, c’est le developpeur. Surveillez votre console et les codes retour réseau (F12). Ce qui nous handicape le plus c’est l’absence de raison invoquée pour le blocage WAF (retour 403 sec sans contenu).
OK je ne sais pas trop comment se comporte la UI en cas de 403 sur un search, on testera et on verra si ça peut être rendu plus informatif pour l’utilisateur.
Sur le cas particulier du seul filtre avancé (like '%A%') “en dur” dans le code de la UI pour les appels sur WebNews on l’a refactoré pour utiliser un filtre simple, il n’y aura donc plus d’alerte à ce niveau à partir de la prochaine révision (5.2.31).
Les cas d’usage de filtres avancés ne seront donc alors plus que ceux explicitement saisis par les users (qui finiront donc en 403 si un WAF les bloque).
Du coup je repose la question => @ewencodes avez vous détecté d’autres cas de suspicions d’injection SQL (ou autres cas de blocages WAF, hors outils de DEV et endpoints techniques comme I/O, Git, Maven, … qui sont sensés être fermés ou protégés en PROD) ?
Sur le 1er point on va regarder pour voir d’où vient ce double URL-encodage. Il s’agit de toute façon de la fonctionnalité d’affichage des news qui n’est peut être pas utilisée dans votre cas.
Sur le 2ème et 3ème point on parle de l’éditeur de templates (= éditeur du “layout” des formulaires). C’est un outil purement de DEV qui n’a strictement aucune raison d’être habilité/utilisé en PROD. Si vous avez plus de détails sur ce qui est considéré comme un XSS on peut malgré tout regarder ça de plus près mais c’est peut être un faux positif car dans cet écran on manipule/échange du HTML et potentiellement du JS inliné.
Sur le 3ème point nous serions intéressé d’en savoir plus sur ce qui ne passe pas la “validation stricte” au niveau de ce qui est passé dans la requête multipart. On est ici sur un mécanisme générique (le search) qui est utilisé partout… Cela dit en faisant une rapide recherche sur internet je vois qu’il pourrait s’agir d’un bug du WAF Microsoft : azure application gateway - WAF - 200003 Multipart Request Body Strict Validation - Stack Overflow
Est-ce que le blocage détecté sur le count sur WebNews correspond bien à l’appel qui valorise le compteur de news de la page d’accueil tel qu’indiqué sur les copies d’écran ci-dessus ?
Restricted SQL Character Anomaly Detection (args): # of special characters exceeded (12)
942440
SQL Comment Sequence Detected.
942130
SQL Injection Attack: SQL Tautology Detected.
Je ne préfère pas partager plus de détails ici, sur un ticket public, mais je peux vous les envoyer en direct si vous voulez investiguer plus en détail.
En tout cas, vu le nombre de blocages, nous sommes d’avis de désactiver le WAF pour l’UI Simplicité, plutot que de dépenser une énergie folle à mettre en place des exclusions une à une, pour arriver au final à un WAF quasiment sans aucun règle active.
Etant donné que l’accès à cette UI est limitée à un public restreint, et protégée par un filtrage IP, le risque nous parait acceptable.
Pour commencer, de quelle version de Simplicité parle-t-on précisément ?
Je pose la question car toutes les potentielles vulnérabilités (XSS, injection SQL, …) ou autre pb de sécurité sont corrigées en priorité maximale dès qu’elles nous sont signalées et qu’on a vérifié que ce n’est pas un faux positif (ce qui est fréquent avec certains outils qui essaient de rien laisser passer au risque de bloquer des choses qui ne sont pas problématiques)
Pouvez vous m’envoyer par message privé plus de détails sur ces détections afin qu’on regarde de plus près de quoi il retourne.
La bonne stratégie avec un WAF ce n’est pas d’inhiber totalement des règles mais plutôt de mettre des exceptions sur les cas clairement identifiés comme des faux positifs, sinon effectivement vous risquez de finir avec un WAF qui n’implémente plus aucune règle et qui ne sert donc plus à rien.
Les usages “designer” (= dev) sont forcément plus susceptibles de générer des faux positifs ou, en tout cas, d’avoir des vulnérabilités légitimes que des usages “normaux” par des utilisateurs finaux (ceux-ci n’accèdent pas à des outils purement de dev comme l’éditeur de code ou le browser de base de données qui sont des exemples d’outils légitimement vulnérables par construction et par destination) => Dans la pratique si vous devez mettre en place un WAF il faut le faire exclusivement sur la prod où strictement personne n’est sensé utiliser les outils “designer”.
Sauf erreur de ma part je n’ai pas reçu en message privé le détail de ces blocages WAF pour analyse.
Ni d’ailleurs d’information sur la version précise que vous utilisez (je pose la question car certains points me semblent correspondre, à priori, à des choses déjà traitées)
Même si vous décidez de désactiver ce WAF ces blocages nous intéressent pour analyse, ne serait-ce que pour s’assurer que c’est des faux positifs et/ou des cas d’usages d’outils pour “designer”
