Application Gateway Azure | WAF Rules

Bonjour,

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é ?

Merci d’avance.

Cordialement,
ROULOIS Ewen

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 ?

Bonjour David,

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! :slight_smile:

Voici un exemple de blocage :

Endpoint :

/ui/json/obj?action=count&object=WebNews&inst=web_WebNews&_=5_2_25_20230126150349&_ajaxkey=WvV99JMXFwzAq1OavCaN

Erreur :

SQL Injection Attack Detected via libinjection.
Detect Sql Injection  at ARGS.
Matched Data: sos found within ARGS:nws_display: like '%A%'

Merci @bmo pour ce retour d’expérience, juste:

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é: Simplicité® documentation/security) => 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. Simplicité® documentation/04-ui/search-syntax) 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) ?

Bonjour,

Pour la partie I/O, Git et Maven on est bon.

Pour ce qui est des blocages sur les endpoints HTTP nous avons cela :

  • Multiple URL Encoding Detected (Rule Id: 920230) → /ui/json/obj?action=count\u0026object=WebNews\u0026inst=web_WebNews\u0026_=5_2_27_20230208161659\u0026_ajaxkey=ApDh3Vgt27MbK0jKgAtk
  • IE XSS Filters - Attack Detected (Rule Id : 941330) → /ui/edittmpl
  • Possible XSS Attack Detected - HTML Tag Handler (Rule Id : 941320) → /ui/edittmpl
  • Multipart request body failed strict validation (200003) → /ui/json/obj?action=search

OK merci pour ce retour

  • 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

Sur le 1er point je ne vois pas de double URL-encodage dans la console du navigateur…

Ni sur Chrome:

Ni sur Firefox:

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 ?

Bonjour @david

J’ai repris le sujet à la suite de mon collègue @ewencodes , et il y a de nouveaux blocages par dizaines par le WAF sur Simplicité.

ruleId_s Message
920230 Multiple URL Encoding Detected
200003 Multipart request body failed strict validation
942450 SQL Hex Encoding Identified
931130 Possible Remote File Inclusion (RFI) Attack: Off-Domain Reference/Link
942100 SQL Injection Attack Detected via libinjection
942260 Detects basic SQL authentication bypass attempts 2/3
942110 SQL Injection Attack: Common Injection Testing Detected
941320 Possible XSS Attack Detected - HTML Tag Handler
941130 XSS Filter - Category 3: Attribute Vector
941180 Node-Validator Blacklist Keywords
941340 IE XSS Filters - Attack Detected.
941140 XSS Filter - Category 4: Javascript URI Vector
941100 XSS Attack Detected via libinjection
932110 Remote Command Execution: Windows Command Injection
941330 IE XSS Filters - Attack Detected.
942200 Detects MySQL comment-/space-obfuscated injections and backtick termination
942330 Detects classic SQL injection probings 1/3
942340 Detects basic SQL authentication bypass attempts 3/3
942370 Detects classic SQL injection probings 2/3
942430 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.

Cordialement,

Bonjour,

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”

Merci d’avance

Bonjour

Pouvez vous nous envoyer les éléments demandés ?

Il n’est pas logique de solliciter notre support et de ne pas donner suite à nos demandes destinée à nous permettre d’assurer ce support.

Merci

Bonjour,

Nouvelle relance : merci de nous envoyer les éléments demandés afin de pouvoir nous positionner sur votre demande de support.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.