Sorry, you need to enable JavaScript to visit this website.

Image CAPTCHA
Saisir les caractères affichés dans l'image.

WAF WAF WAF

WAF WAF WAF
2009-04-032013-02-11bonnes pratiquesfr
Non, ce n'est pas mon chien qui vous parle, rappelez vous, lui, c'est un expert en sécurité physique. Or de physique, nous n'en parlerons pas ce jour. Peut être demain...
Publié le 3 Avril 2009 par Philippe Maltere dans bonnes pratiques
Non, ce n'est pas mon chien qui vous parle, rappelez vous, lui, c'est un expert en sécurité physique. Or de physique, nous n'en parlerons pas ce jour. Peut être demain ?

Nous allons nous élever, non pas par la méditation transcendantale, mais dans les couches ISO, et aller tutoyer les sommets de la sécurité applicative. Enfin, me direz vous, la sécurité des applications est fondamentale, et tout ce que l'on peut faire par ailleurs ne sert pas à grand-chose si l'application comporte quelques failles exploitables. Je vous le rappelle l'application est la dernière couche du modèle ISO, et est, par conséquent, la plupart des cas, la seule couche perçue par l'utilisateur ou le pirate, c'est selon. D'où la nécessité de protéger l'application. Or, il existe une méthode pour sécuriser celle-ci : la programmation sécurisée. Et c'est la seule méthode, connue de tout le monde, mais que personne n'applique réellement. Alors que faire, se taper la tête contre les murs, et attendre que cela passe... C'est une méthode qui peut faire un peu mal... Une autre existe, un peu plus indolore, le WAF, ou plutôt le Web Application Firewall, puisque maintenant la plupart des applications sont en mode WEB ou en passe de l'être.

Mais, il faut se méfier, il y a WAF et WAF. Il y deux chemins, jeune scarabée pour atteindre la sécurité des applications. Le premier d'apparition relativement récente, est simple, et plein de lumières pour attirer la chaland, consiste à prendre la technologie des IPS (Intrusion Prevention System), et d'y rajouter quelques règles (enfin pas mal) pour « gérer » la couche applicative, type attaque buffer overflow, cross script scripting, SQL injection, et autres joyeusetés. A écouter les disciples de cette voie, cette technologie est simple à mettre en œuvre et presque exhaustive grâce à l'analyse comportementale. Pour le premier point, ils ont raison. Pour le second, c'est un peu plus nuancé, en fait non... Ils ne doivent pas savoir comment on attaque une application grâce aux différentes techniques citées plus haut. Jamais une technologie à base de signatures (et on l'a vu pour les anti virus, je vous le rappelle) ne peut vous protéger efficacement. Pour quoi, simplement, parce que les signatures ont toujours un bus de retard (dans le meilleur des cas). Il faudrait des dizaines de milliers de signatures, et encore, pour éviter des attaques simples, mais canonicalisées (c'est-à-dire que l'on modifie la signature de l'attaque en utilisant des combinaisons de code hexadécimal, octal, ASCII, ...avec cette méthode, il existe des centaines de façons d'écrire SCRIPT, donc des centaines de signatures d'attaques éventuelles qui n'existent bien sûr pas). Mais ces disciples sûrs d'eux, diront qu'ils ont l'arme : l'analyse comportementale. C'est vrai, une attaque de type deni de service sera vue (fantastique exploit !), mais certainement pas une attaque ciblée qui saura resté sous le radar, et ne pourra être vue que par corrélation d'événements (et encore !). Ce type de voie facile pour accéder à la sécurité applicative (que l'on atteindra ni verra jamais par cette méthode) peut en tenter plus d'un. Et c'est peut être une solution à mettre en œuvre pour des applications non critiques.

La seconde voie est longue et obscure, mais permet de s'approcher du Nirvana sans toutefois l'atteindre (rappelons que la sécurité absolue n'existe pas), elle est à base de technologie de reverse proxy, c'est-à-dire que l'on contrôle la plupart des saisies et écrans. Dura Securitax sed Securitax. La route est longue et tortueuse vers la sécurité suprême, mais elle permet, sans trop réécrire l'applicatif, d'obtenir une bonne sécurité convenant à des applications critiques.

Alors faites votre choix. Je n'ai pas cité d'éditeurs, et c'est normal... n'ayant pas touché de chèques suffisamment importants sur mon compte dont vous trouverez les références dans des articles précédents.

4 Commentaires

  • 10 Avril 2009
    2009-04-10
    par
    Florent
    D'ailleurs la prochaine révolution commerciale est en cours. Avec par exemple Imperva qui fait un double combo avec un WAF devant le site web et un database firewall devant la base de données.

    Ce marché a l'air sérieusement de se développer avec l'apparition de projets opensource aboutis sur le sujet.

    Encore une fois c'est un palliatif à une mauvaise configuration des droits sur la base de données pour le compte utilisé par le site web... Mais quand on voit les compétences énormes à avoir pour brider Oracle au niveau des droits, des modules, etc.
  • 9 Avril 2009
    2009-04-10
    par
    Je vous informe que l'OWASP dispose d'un document sur les bonnes pratiques autour des WAF

    https://www.owasp.org/index.php/Category:OWASP_Best_Practices:_Use_of_We...


    J'effectuerai pour les personnes présentes une présentation de ses bonnes pratiques (entre autres) lors du Forum CERT-IST du 9/06/2009
  • 6 Avril 2009
    2009-04-10
    par
    Non, tu n'es pas naïf, un reverse proxy fait le job... Seulement voilà, le marketing aidant, d'autres choses sont maintenant étiquetés WAF.... Et ces appareils ne sont ni plus ni moins que des IPS... Je dis danger de considérer ce type d'appareils comme des firewalls d'applications en tant que tel... On achète une fausse sécurité... Très dangereux...
  • 3 Avril 2009
    2009-04-10
    par
    Florent
    C'est vrai que les WAF sont un vrai sujet d'actualité.

    De ma vision naïve je croyais qu'un reverse-proxy devait déjà fournir cette protection. C'est juste le petit côté commercial des vendeurs de sécurité pour dire que c'est mieux qu'avant... Disons que c'est un peu plus axé "reporting" avec des camemberts montrant les attaques bloquées... C'est très important de pouvoir surveiller ce qu'il se passe. Dans l'idée si on reçoit plein d'attaques foireuses (détectées par le WAF) on passe en mode vigilant. Ca ne veut pas dire que rien n'est passé !

    Le vrai problème c'est qu'on pose un WAF devant une application et qu'il faut que ça marche. C'est le même problème que les black-lists. Toujours un temps de retard... Et le pseudo-mode apprentissage :-/

    Pour moi la solution idéale s'approche plus du développement sécurisé. En gros filtrer les données en fonction de ce que doit recevoir la page. On commence à voir les "prepared statement" en SQL qui indique quelle est la structure stricte d'une requête et quel type doit avoir le paramètre.

    = new mysqli("localhost", "user", "pass", "database");
    = -> prepare("SELECT priv FROM testUsers WHERE username=? AND password=?");
    -> bind_param("ss", , );
    -> execute();

    Ici le "ss" indique que les deux variables sont des strings.

    Il manque quasiment un formalisme de plus haut niveau pour indiquer les paramètres nécessaires à toute requête (pas seulement SQL) ainsi que leur type, voire leur longueur et qui pourrait être transmis à un WAF. Là on aurait un vrai filtrage des données reçues !!

    Je m'en vais de ce pas déposer un brevet :)

Ajouter un commentaire

comments

  • Les adresses de pages web et de courriels sont transformées en liens automatiquement.
  • Les lignes et les paragraphes vont à la ligne automatiquement.
  • Tags HTML autorisés : <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd> <br>

Plain text

  • Aucune balise HTML autorisée.
  • Les adresses de pages web et de courriels sont transformées en liens automatiquement.
  • Les lignes et les paragraphes vont à la ligne automatiquement.

Email HTML

  • Les lignes et les paragraphes vont à la ligne automatiquement.
  • Les adresses de pages web et de courriels sont transformées en liens automatiquement.
Image CAPTCHA
Saisir les caractères affichés dans l'image.
Changer d'affichage