SlideShare une entreprise Scribd logo

Sécurité des applications Web

Présentation des techniques classiques d'attaque sur des sites web

1  sur  49
Télécharger pour lire hors ligne
Prez Flash :: Sécurité des
                          applications Web




                                                       Auteur : Julien Bourdin
© Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin       1   1
Agenda



                                                                   Introduction
                                                                   Le concept de sécurité
                                                                   Les protections indispensables
                                                                   Les attaques typiques




© Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin                          2
Objectif de la présentation


       Cette présentation a pour but de présenter un large ensemble de problèmes de
       sécurité à prendre en compte dans un projet web.


       La présentation précisera en premier ce que le terme « sécurité » signifie au sens
       large, son périmètre et le discours qui doit l’accompagner.


       Ensuite, la présentation passera en revu un certain nombre des attaques possibles
       contre une application web en expliquant comment elles procèdent et surtout comment
       s’en prémunir




© Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin                  3
Agenda



                                                                   Introduction
                                                                   Le concept de sécurité
                                                                   Les protections indispensables
                                                                   Les attaques typiques




© Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin                          4
Le concept de sécurité




                                    La sécurité est une gestion des risques.




© Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin     5
La gestion des risques



       Lister les évènements qui peuvent survenir

       Estimer la probabilité de les voir arriver

       Estimer le coût lorsqu’un évènement se
       produit

       Estimer le coût pour réduire la chance que
       l’évènement en question se produise




                                                                             Méthodologie EBIOS

© Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin                        6
La gestion des risques


       Le coût du risque
           Probabilité du risque que multiplie le coût de l’évènement : P x C
           À comparer avec le coût pour réduire le risque et au coût des autres risques.


       Conséquences
           Tout risque identifié n’est pas un risque à corriger, on compare le coût de chacun des risques
           Tout comme il existe de la surqualité, il existe des abus de sécurité




                      Il n’est pas possible de réduire à 0
                            l’ensemble des risques !
© Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin                               7
Les différents domaines de la sécurité



       Intégrité des données




       Confidentialité des données




       Disponibilité des services




       Responsabilité des personnes




© Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin      8
Les différents domaines de la sécurité



       Intégrité des données

           Transactions, Détection des incohérences, Sauvegarde


       Confidentialité des données

           Authentification, Droits d’accès, Détection d’intrusion


       Disponibilité des services

           Redondance, Récupération après incident, DOS, Supervision


       Responsabilité des personnes

           Usage indu, Traçabilité, Maintenance



© Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin      9
La sécurité est une chaîne


       Chaque composant et chaque acteur apportent des risques


       Sur un type de menace donné, l’application à la sécurité de son maillon le plus faible


        La solution la plus efficace pour réduire le risque n’est pas nécessairement une
       solution technique



       Inutile de mettre une porte blindée si les murs sont en papier
       Inutile d’avoir une serrure 5 points si on laisse les clefs sous le paillasson
       Inutile d’avoir un SSO complexe si votre mot de passe est « 1234 » ou « password »




© Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin                      10
La sécurité est un investissement




    Les bonnes pratiques, une fois acquises,
   permettent un niveau de sécurité correcte
               à moindre coût.




© Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin   11
Agenda



                                                                   Introduction
                                                                   Le concept de sécurité
                                                                   Les protections indispensables
                                                                   Les attaques typiques




© Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin                          12
la première faille de sécurité




© Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin   13
la première faille de sécurité




© Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin   14
L’être humain est la première faille de sécurité



       Tout collaborateur n’est pas aussi bienveillant qu’on le souhaiterait :

           la majorité des sabotages sont le fait de collaborateurs dans les entreprises

       Les relations hiérarchiques sont plus fortes que les règles de sécurité :

           une secrétaire donne à son patron le mot de passe par téléphone s’il lui demande.

       La vigilance n’est pas une culture

           On ne vérifie pas l’identité de la personne qui arrose les plantes

           On prête son compte à son collègue pour ses congés

       On n’aime pas les contraintes pesantes !




© Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin                      15
Il est important de former et d’informer



       Ce qui est vécu comme une contrainte est souvent contourné


       Ce qui semble anodin n’est pas source d’attention


       Seule la formation de chaque personne permet de limiter le « piratage social »


       Il faut donc responsabiliser

           les utilisateurs
           les décideurs
           les concepteurs
           les développeurs
           les exploitants




© Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin              16
Sécurité : la valeur des procédures


       Toute intervention sur un système apporte le risque d’introduire de nouveaux
       problèmes
           Cela est encore plus vrai dans le cas de systèmes complexes comme les systèmes
               d’informations
       La disponibilité, la confidentialité et la cohérence des systèmes sont menacées lors de
       chaque intervention
           Chaque intervention doit déclencher des contrôles précis sous une responsabilité précise
           Un journal des interventions doit être tenu
           L’état antérieur à l’intervention doit pouvoir être restauré
       Il est indispensable de formaliser les interventions récurrentes (livraisons,
       maintenances préventives…)
       Il est indispensable de tracer toutes les interventions sur un support consulté par les
       exploitants




© Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin                             17
Les failles évidentes




                      Essayez donc /typo3/install
© Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin   18
Les failles évidentes



       Changer les mots de passe par défaut

       Supprimer les dossiers et fichiers inutiles (MISC, .bak, .sql)

       Utilisez du HTTPS si votre application transmet des mots de passe en clair

       Ayez des certificats valides pour votre HTTPS

       Limitez l'accès au back-office / à l’application aux personnes pertinentes par une
       technique forte (LAN ou VPN)

       Mettez à jour les logiciels supports et les bibliothèques

       Choisissez vos bibliothèques (en évitant les versions obsolètes ou expérimentales)

       Désactivez l'option "indexes" d'APACHE




© Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin                  19
Gestion des comptes



       Un compte utilisateur doit être attaché à une unique personne

       L’accès doit être restreint par des mots de passe non triviaux

           Interdiction d’utiliser le login ou un mot de passe par défaut !

           Interdiction d’utiliser le prénom de sa fille ou son année de naissance !

           Interdiction d’utiliser les mots de passe type de l’entreprise !

       Les droits doivent appartenir à des groupes

       Les droits donnés sont ceux nécessaires et suffisants pour les tâches confiées

       La délégation se fait en donnant des droits au compte du responsable par délégation

       Un mot de passe ne doit jamais être transmis, encore moins pas courriel




© Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin                   20
Limiter la portée des intrusions




                 Une brèche ne doit pas emporter tout le système !




© Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin   21
Limiter la portée des intrusions



     Limitez les privilèges : les comptes administrateurs

       Limitez les comptes superadmin le plus possible
           Un administrateur KLEE, un chez le client s’il a la compétence




       Activez un envoi de mail avertissant de la connexion d’un compte superadmin




       N’utilisez ce type de compte que pour les actions le nécessitant !




© Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin           22
Limiter la portée des intrusions



     Limitez les privilèges : les droits d’écritures

       Les droits d’écriture sur les fichiers ne sont pas donnés à Apache / TomCat / … en
       dehors de de quelques répertoires bien choisis
           les livraisons sont faites avec un compte distinct


       Ne laissez pas en production d‘outils donnant accès à la base de données ou au
       système de fichiers (phpmyadmin, terminal virtuel, etc.)


       Interdisez la livraison de contenus exécutables par l’interface Web (cas des produits à
       modules)




© Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin                   23
Limiter la portée des intrusions



     Assurez-vous de la conservation des données

       Sauvegardez

           vos environnements

           vos données

       Vérifiez le bon fonctionnement de ces sauvegardes

       Validez les processus de restauration

       Cryptez les données confidentielles (mot de passe) et ne laissez pas de dumps
       accessibles




© Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin             24
Limiter la portée des intrusions




                       N’accordez qu’un crédit limité
                         à une protection donnée




© Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin   25
Surveillez les indicateurs de votre site




       Vérifiez dans les logs si des URL inconnues existent



       Cherchez si des variations de bande passante/nombre de hit apparaissent



       Vérifiez que l’espace disque, la mémoire occupée ou la charge CPU




       Réagissez en cas de doute !



© Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin        26
Agenda



                                                                   Introduction
                                                                   Le concept de sécurité
                                                                   Les protections indispensables
                                                                   Les attaques typiques




© Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin                          27
Le déni de service




© Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin   28
Qu’est-ce que le déni de service ?


       Une attaque en déni de service vise à rendre impossible le bon fonctionnement d’un
       service en saturant un composant de l’architecture rendant ces services.


       Il peut donc s’agir de saturer de requête la plateforme, mais cela peut aussi prendre
       des tours plus particuliers
           Saturation de la base de données
           Appel répété sur le moteur de recherche ou sur certaines pages vulnérables
           Ajout de scripts infinis dans un contenu


       L’objet peut être simplement le déni de service, mais cela peut aussi avoir comme but
       de faire disparaître le serveur pour usurper ensuite son identité (spoofing)




© Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin                     29
Se protéger contre le déni de service :
                                       attaque frontale


       Dimensionnez votre plateforme pour une pointe de trafique pertinente


       Activez les caches applicatifs et empêcher les contournements de ces derniers

       Mettez un reverse proxy avec un timeout : Il faut pouvoir délester en retournant un
       message d’erreur

       Limitez les pools de connexions à la BDD et les processus Apache


       Supervisez et alertez en cas de montée en charge non anticipée




© Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin                   30
Se protéger contre le déni de service :
                                       écritures


       Limitez les possibilités d’écriture sur le serveur : pas de dépôt de fichiers ni d’écriture
       en base non régulés


       N'écrivez pas en base de données depuis un accès anonyme sauf avec protection
       anti-robot (livre d'or, commentaire, etc.)


       Supervisez l'espace sur file system et dans la BDD : alerte lors de franchissement de
       seuils !




© Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin                           31
Se protéger contre le déni de service :
                                       un exemple sur TYPO3


       Le cache de TYPO3 est en base de données ! Une URL n’est acceptée que si elle
       répond à un certain nombre de critères comme la validité des paramètres soumis.


       Sont acceptées par défaut les variables « id » et « type »


       Les autres variables ne sont valables que si elles ont été signées par la génération
       d’une URL depuis TYPO3. La signature, le cHash, est le résultat d’un MD5 des
       données concaténées et d’une clef privée du serveur


 http://monsite.com/index.php?id=2&L=3&tx_ttnews[tt_news]=23&cHash=a7024cb7




© Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin                    32
Le spam depuis votre serveur




                   Votre serveur peut devenir une source de spam !




© Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin   33
Le spam depuis votre serveur



 Un serveur capable d’envoyer des mails doit être maîtrisé !

       Le risque est de voir un écran exploité par un robot pour diffuser largement des
       publicités
       Un écran pouvant provoquer l’envoi d’un mail doit respecter au moins une des règles
       ci-dessous :
           Le courriel est destiné à une unique boîte à lettres (contact)
           Le formulaire ne peut être soumis qu’après un test identifiant un humain plutôt qu’un robot
           Le courriel aura un contenu fixe, dépendant de paramètre non modifiable sur l’écran
           Les courriels ne peuvent être envoyés que sur un domaine interne (intranet)
       La quantité de courriels envoyés par l’application doit être supervisée
       Vous risquez, en cas de souci, de voir votre serveur d’envoi de courriel dans les listes
       noires




© Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin                                34
L’injection SQL




      Une injection SQL est l’utilisation d’instruction du langage SQL au sein d’un paramètre
      sensé ne contenir que de la donnée.




© Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin                  35
Exemple : la connexion par login et
                                       mot de passe



 SELECT * FROM USERS WHERE LOGIN = '$_GET['login']' AND PASSWORD =
 '$_GET['password']';
 Il lui suffit donc de saisir Monlogin';# pour que la requête devienne :
 SELECT * FROM USERS WHERE LOGIN = 'Monlogin';#' AND PASSWORD = '';



 La bonne méthode consiste à considérer la saisie comme des caractères non
 susceptibles de déclencher des commandes MySQL (voir mysql_real_escape_string)
 SELECT * FROM USERS WHERE LOGIN = 'Monlogin'; #' AND PASSWORD = '';



 Note : en aucun cas, la requête présentée n’est la bonne façon de
 gérer une authentification !



© Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin        36
Se prémunir de l’injection SQL



       Si possible, préférez les requêtes préparées (prepared statement) qui n’attendent que
       des données et qui ne sont donc pas sensibles à l’injection

       Vérifiez toujours la nature des données insérées dans les requêtes

       Ne donnez à l’utilisateur SQL de l’application que le minimum de droits nécessaires
       (pas de DROP, TRUNCATE…)

       Ne stockez pas en base de mots de passe lisibles

       Ayez des sauvegardes régulières des données

       Utilisez les mécanismes du Framework / de l’API / du Langage pour générer le SQL




© Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin                   37
L’injection SQL au quotidien




© Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin   38
L’injection de script (XSS)




© Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin   39
L’injection de script (XSS)



       Le principe de cette stratégie d’attaque est de profiter de l’affichage de données
       envoyées par l’utilisateur pour inclure des éléments de HTML ou de script non prévu



       Le moyen d’en faire une agression est d’inclure du script qui va soumettre à l’extérieur
       la saisie de données confidentielles



       Pour arriver à créer ce contexte, il faut fournir par un moyen ou un autre, une URL
       portant ces données. Ce sera typiquement par l’envoi de mails malicieux ou par une
       mise en ligne d’un lien sur un autre site




© Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin                   40
Le Cross Site Scripting : cas concret


       Un moteur de recherche propose un champ de saisie et passe les données sous la
       forme : http://www.monsite.fr/index.php?wsearch=mot_recherche


       Les résultats sont présentés avec un rappel « votre recherche : mot_recherche »


       Si on remplace dans l’URL par wsearch=<script type="text/JavaScript">…</script>
       (moyennant un encodage de l’URL)


       On obtient une page dans laquelle, selon le traitement, on a un script inclus et
       interprété là où l’on croyait avoir un simple mot




© Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin                41
Le XSS : vérifier le type de vos sorties !



       Normalement, une donnée utilisateur est d’un type simple :

           Nombre

           Texte

           choix dans un menu déroulant…

       Ce ne sont pas des typages techniques !

           Une chaîne de caractère et un texte simple ne sont pas la même chose

       Le cas simple : prendre la donnée à afficher et s’assurer que tous les caractères ne
       sont pas interprétés en HTML : htmlspecialchars en PHP

       Les cas complexes : autorisations de certaines balises par une analyse spécifique




© Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin                    42
Bonne pratique : la programmation par contrat


       Chaque méthode définit le format de ses entrées et de ses sorties
       Les variables sont vérifiées par des assertions qui, en cas de non-respect, stoppent
       l’exécution


     function mafonction($a,$b){
       assertion(type1,$a);
       assertion(type2,$b);
       $retour = corpsdemethode();
       assertion(typesortie,$retour);
       return $retour;
     }




       Ce motif est à appliquer le plus souvent possible
       Il est impératif chaque fois que l’on définit un service recevant des données
       utilisateurs, proposant des données pour affichage ou devant agir sur les contenus

© Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin                    43
Le Cross Site Request Forgery (CSRF)




© Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin    44
Le Cross Site Request Forgery (CSRF)


       La plupart des outils utilisent, avec raison, des URLs explicites:
           http://www.monsite.fr/index.php?action=supprimer&id=35


       Ces URL sont donc prévisibles même pour un utilisateur n’ayant pas le droit
       d’exécuter celle-ci


       Une personne va donc tenter de faire jouer cette URL à une personne ayant les droits
       à son insu
           En proposant le lien dans le href d’une balise image sur une page susceptible d’être
               consultée
           En proposant un JavaScript de la même façon




© Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin                         45
Le Cross Site Request Forgery (CSRF)


       L’agression est difficile à détecter : c’est une personne ayant les droits qui fait les
       actions


       La faiblesse est accrue par les contextes de type SSO : la personne peut ne pas
       encore s’être authentifié à l’application et faire toutefois l’action


       L’attaque est d’autant plus facile à mener que les URL d’écriture passent leur
       paramètre en GET (possibilité d’utiliser des liens simple)




© Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin                       46
Le Cross Site Request Forgery (CSRF)


       Il faut ajouter un élément non prévisible dans les URL


       Il faut que les URL ne soient pas rejouable


       Exemple de solution : ajouter une date et une signature du serveur


 http://www.monsite.fr/index.php
 ?action=supprimer&id=35&date=timestamp&cHash=jgs37829DE


       Il faut évidemment également privilégier l’usage de POST au lieu de GET pour toute
       action de modification de données !




© Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin                  47
Questions ?




© Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin   48
Questions ?




                                       Retrouvez-nous sur le blog technique de KLEE


                                                      http://blog.kleegroup.com/teknics




            teKnics@kleegroup.com
                                                                             @teKnics_Klee

© Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin                   49

Recommandé

Securite des Applications dans le Cloud
Securite des Applications dans le CloudSecurite des Applications dans le Cloud
Securite des Applications dans le CloudSebastien Gioria
 
Sécurité des Développements Webs et Mobiles
Sécurité des Développements Webs et MobilesSécurité des Développements Webs et Mobiles
Sécurité des Développements Webs et MobilesPhonesec
 
Securite applicative et SDLC - OWASP Quebec - 15 avril 2014
Securite applicative et SDLC - OWASP Quebec - 15 avril 2014 Securite applicative et SDLC - OWASP Quebec - 15 avril 2014
Securite applicative et SDLC - OWASP Quebec - 15 avril 2014 Patrick Leclerc
 
OWASP Mobile Top10 - Les 10 risques sur les mobiles
OWASP Mobile Top10 -  Les 10 risques sur les mobilesOWASP Mobile Top10 -  Les 10 risques sur les mobiles
OWASP Mobile Top10 - Les 10 risques sur les mobilesSébastien GIORIA
 
Les 5 risques les plus critiques des applications Web selon l'OWASP
Les 5 risques les plus critiques des applications Web selon l'OWASPLes 5 risques les plus critiques des applications Web selon l'OWASP
Les 5 risques les plus critiques des applications Web selon l'OWASPyaboukir
 
Les menaces applicatives
Les menaces applicativesLes menaces applicatives
Les menaces applicativesBee_Ware
 
Sécurité des applications mobiles
Sécurité des applications mobilesSécurité des applications mobiles
Sécurité des applications mobilesSebastien Gioria
 

Contenu connexe

Tendances

Wavestone - IAM of Things / Identité des objets connectés
Wavestone - IAM of Things / Identité des objets connectésWavestone - IAM of Things / Identité des objets connectés
Wavestone - IAM of Things / Identité des objets connectésKévin Guérin
 
Présentation Top10 CEGID Lyon
Présentation Top10 CEGID LyonPrésentation Top10 CEGID Lyon
Présentation Top10 CEGID LyonSébastien GIORIA
 
Wavestone benchmark securite site web 2016 2017
Wavestone benchmark securite site web 2016 2017Wavestone benchmark securite site web 2016 2017
Wavestone benchmark securite site web 2016 2017Gaudefroy Ariane
 
Comment protéger les applications mobiles?
Comment protéger les applications mobiles?Comment protéger les applications mobiles?
Comment protéger les applications mobiles?Marie-Claire Willig
 
Les principales failles de sécurité des applications Web actuelles
Les principales failles de sécurité des applications Web actuellesLes principales failles de sécurité des applications Web actuelles
Les principales failles de sécurité des applications Web actuellesXavier Kress
 
ASFWS 2012 - Les utilités d’un pare-feu applicatif Web (WAF) par Jonathan Marcil
ASFWS 2012 - Les utilités d’un pare-feu applicatif Web (WAF) par Jonathan MarcilASFWS 2012 - Les utilités d’un pare-feu applicatif Web (WAF) par Jonathan Marcil
ASFWS 2012 - Les utilités d’un pare-feu applicatif Web (WAF) par Jonathan MarcilCyber Security Alliance
 
La Quete du code source fiable et sécurisé - GSDAYS 2015
La Quete du code source fiable et sécurisé - GSDAYS 2015La Quete du code source fiable et sécurisé - GSDAYS 2015
La Quete du code source fiable et sécurisé - GSDAYS 2015Sebastien Gioria
 
Owasp top 10 2010 Resist toulouse
Owasp top 10   2010  Resist toulouseOwasp top 10   2010  Resist toulouse
Owasp top 10 2010 Resist toulouseSébastien GIORIA
 
OWASP Quebec: "Security Stories" par Guillaume Croteau
OWASP Quebec: "Security Stories" par Guillaume CroteauOWASP Quebec: "Security Stories" par Guillaume Croteau
OWASP Quebec: "Security Stories" par Guillaume CroteauPatrick Leclerc
 
Securing your API and mobile application - API Connection FR
Securing your API and mobile application - API Connection FRSecuring your API and mobile application - API Connection FR
Securing your API and mobile application - API Connection FRSebastien Gioria
 
Durcissement de code - Sécurité Applicative Web
Durcissement de code - Sécurité Applicative WebDurcissement de code - Sécurité Applicative Web
Durcissement de code - Sécurité Applicative WebCyrille Grandval
 
ASFWS 2011 - Evaluation de la sécurité des applications mobiles
ASFWS 2011 - Evaluation de la sécurité des applications mobilesASFWS 2011 - Evaluation de la sécurité des applications mobiles
ASFWS 2011 - Evaluation de la sécurité des applications mobilesCyber Security Alliance
 
Les principales failles de sécurité des applications web actuelles
Les principales failles de sécurité des applications web actuellesLes principales failles de sécurité des applications web actuelles
Les principales failles de sécurité des applications web actuellesBee_Ware
 
Sécurité des applications web: attaque et défense
Sécurité des applications web: attaque et défenseSécurité des applications web: attaque et défense
Sécurité des applications web: attaque et défenseAntonio Fontes
 
Les firewalls applicatifs HTTP / WAF
Les firewalls applicatifs HTTP / WAFLes firewalls applicatifs HTTP / WAF
Les firewalls applicatifs HTTP / WAFSylvain Maret
 
Waf, le bon outil, la bonne administration
Waf, le bon outil, la bonne administration Waf, le bon outil, la bonne administration
Waf, le bon outil, la bonne administration Bee_Ware
 
White paper - La sécurisation des web services
White paper - La sécurisation des web servicesWhite paper - La sécurisation des web services
White paper - La sécurisation des web servicesBee_Ware
 
Sécurité des Applications WEB -LEVEL1
 Sécurité des Applications WEB-LEVEL1 Sécurité des Applications WEB-LEVEL1
Sécurité des Applications WEB -LEVEL1Tarek MOHAMED
 

Tendances (20)

Wavestone - IAM of Things / Identité des objets connectés
Wavestone - IAM of Things / Identité des objets connectésWavestone - IAM of Things / Identité des objets connectés
Wavestone - IAM of Things / Identité des objets connectés
 
Présentation Top10 CEGID Lyon
Présentation Top10 CEGID LyonPrésentation Top10 CEGID Lyon
Présentation Top10 CEGID Lyon
 
Wavestone benchmark securite site web 2016 2017
Wavestone benchmark securite site web 2016 2017Wavestone benchmark securite site web 2016 2017
Wavestone benchmark securite site web 2016 2017
 
Comment protéger les applications mobiles?
Comment protéger les applications mobiles?Comment protéger les applications mobiles?
Comment protéger les applications mobiles?
 
Les principales failles de sécurité des applications Web actuelles
Les principales failles de sécurité des applications Web actuellesLes principales failles de sécurité des applications Web actuelles
Les principales failles de sécurité des applications Web actuelles
 
ASFWS 2012 - Les utilités d’un pare-feu applicatif Web (WAF) par Jonathan Marcil
ASFWS 2012 - Les utilités d’un pare-feu applicatif Web (WAF) par Jonathan MarcilASFWS 2012 - Les utilités d’un pare-feu applicatif Web (WAF) par Jonathan Marcil
ASFWS 2012 - Les utilités d’un pare-feu applicatif Web (WAF) par Jonathan Marcil
 
La Quete du code source fiable et sécurisé - GSDAYS 2015
La Quete du code source fiable et sécurisé - GSDAYS 2015La Quete du code source fiable et sécurisé - GSDAYS 2015
La Quete du code source fiable et sécurisé - GSDAYS 2015
 
Owasp top 10 2010 Resist toulouse
Owasp top 10   2010  Resist toulouseOwasp top 10   2010  Resist toulouse
Owasp top 10 2010 Resist toulouse
 
OWASP Quebec: "Security Stories" par Guillaume Croteau
OWASP Quebec: "Security Stories" par Guillaume CroteauOWASP Quebec: "Security Stories" par Guillaume Croteau
OWASP Quebec: "Security Stories" par Guillaume Croteau
 
Securing your API and mobile application - API Connection FR
Securing your API and mobile application - API Connection FRSecuring your API and mobile application - API Connection FR
Securing your API and mobile application - API Connection FR
 
Durcissement de code - Sécurité Applicative Web
Durcissement de code - Sécurité Applicative WebDurcissement de code - Sécurité Applicative Web
Durcissement de code - Sécurité Applicative Web
 
ASFWS 2011 - Evaluation de la sécurité des applications mobiles
ASFWS 2011 - Evaluation de la sécurité des applications mobilesASFWS 2011 - Evaluation de la sécurité des applications mobiles
ASFWS 2011 - Evaluation de la sécurité des applications mobiles
 
Les principales failles de sécurité des applications web actuelles
Les principales failles de sécurité des applications web actuellesLes principales failles de sécurité des applications web actuelles
Les principales failles de sécurité des applications web actuelles
 
Sécurité des applications web: attaque et défense
Sécurité des applications web: attaque et défenseSécurité des applications web: attaque et défense
Sécurité des applications web: attaque et défense
 
Sécurité des réseaux
Sécurité des réseauxSécurité des réseaux
Sécurité des réseaux
 
Les firewalls applicatifs HTTP / WAF
Les firewalls applicatifs HTTP / WAFLes firewalls applicatifs HTTP / WAF
Les firewalls applicatifs HTTP / WAF
 
Waf, le bon outil, la bonne administration
Waf, le bon outil, la bonne administration Waf, le bon outil, la bonne administration
Waf, le bon outil, la bonne administration
 
White paper - La sécurisation des web services
White paper - La sécurisation des web servicesWhite paper - La sécurisation des web services
White paper - La sécurisation des web services
 
20100114 Waf V0.7
20100114 Waf V0.720100114 Waf V0.7
20100114 Waf V0.7
 
Sécurité des Applications WEB -LEVEL1
 Sécurité des Applications WEB-LEVEL1 Sécurité des Applications WEB-LEVEL1
Sécurité des Applications WEB -LEVEL1
 

En vedette

ASFWS 2011 : Les exigences PCI-DSS en terme de développement logiciel
ASFWS 2011 : Les exigences PCI-DSS en terme de développement logicielASFWS 2011 : Les exigences PCI-DSS en terme de développement logiciel
ASFWS 2011 : Les exigences PCI-DSS en terme de développement logicielCyber Security Alliance
 
Les 10 principales menaces de sécurité des bases de données
Les 10 principales menaces de sécurité des bases de donnéesLes 10 principales menaces de sécurité des bases de données
Les 10 principales menaces de sécurité des bases de donnéesImperva
 
Architecture orientée service (SOA)
Architecture orientée service (SOA)Architecture orientée service (SOA)
Architecture orientée service (SOA)Klee Group
 
Plan de reprise d’activité
Plan de reprise d’activitéPlan de reprise d’activité
Plan de reprise d’activitéExam PM
 
AngularJS - Présentation (french)
AngularJS - Présentation (french)AngularJS - Présentation (french)
AngularJS - Présentation (french)Yacine Rezgui
 
Sécurité des systèmes d'information
Sécurité des systèmes d'informationSécurité des systèmes d'information
Sécurité des systèmes d'informationFranck Franchin
 
PRA et PCA : plans de reprise et de continuité d'activité
 PRA et PCA : plans de reprise et de continuité d'activité PRA et PCA : plans de reprise et de continuité d'activité
PRA et PCA : plans de reprise et de continuité d'activitéChristophe Casalegno
 
Presentation des failles_de_securite
Presentation des failles_de_securitePresentation des failles_de_securite
Presentation des failles_de_securiteBorni Dhifi
 
comprendre angularJS en 10 minutes
comprendre angularJS en 10 minutescomprendre angularJS en 10 minutes
comprendre angularJS en 10 minutesDavid Bo
 
Les 10 risques liés aux applications mobiles
Les 10 risques liés aux applications mobilesLes 10 risques liés aux applications mobiles
Les 10 risques liés aux applications mobilesBee_Ware
 
Découverte d'aeSecure, sécurisation et optimisation sites Apache
Découverte d'aeSecure, sécurisation et optimisation sites ApacheDécouverte d'aeSecure, sécurisation et optimisation sites Apache
Découverte d'aeSecure, sécurisation et optimisation sites ApacheChristophe Avonture
 
Débuter avec Rails::API & AngularJS
Débuter avec Rails::API & AngularJSDébuter avec Rails::API & AngularJS
Débuter avec Rails::API & AngularJSFrédéric DUPERIER
 
Ces outils qui vous font gagner du temps
Ces outils qui vous font gagner du tempsCes outils qui vous font gagner du temps
Ces outils qui vous font gagner du tempsAntoine Rey
 
Tester unitairement une application java
Tester unitairement une application javaTester unitairement une application java
Tester unitairement une application javaAntoine Rey
 

En vedette (18)

Applications mobiles et sécurité
Applications mobiles et sécuritéApplications mobiles et sécurité
Applications mobiles et sécurité
 
Attques web
Attques webAttques web
Attques web
 
Apache Open SSL
Apache Open SSLApache Open SSL
Apache Open SSL
 
ASFWS 2011 : Les exigences PCI-DSS en terme de développement logiciel
ASFWS 2011 : Les exigences PCI-DSS en terme de développement logicielASFWS 2011 : Les exigences PCI-DSS en terme de développement logiciel
ASFWS 2011 : Les exigences PCI-DSS en terme de développement logiciel
 
Les 10 principales menaces de sécurité des bases de données
Les 10 principales menaces de sécurité des bases de donnéesLes 10 principales menaces de sécurité des bases de données
Les 10 principales menaces de sécurité des bases de données
 
Architecture orientée service (SOA)
Architecture orientée service (SOA)Architecture orientée service (SOA)
Architecture orientée service (SOA)
 
Plan de reprise d’activité
Plan de reprise d’activitéPlan de reprise d’activité
Plan de reprise d’activité
 
AngularJS - Présentation (french)
AngularJS - Présentation (french)AngularJS - Présentation (french)
AngularJS - Présentation (french)
 
Sécurité des systèmes d'information
Sécurité des systèmes d'informationSécurité des systèmes d'information
Sécurité des systèmes d'information
 
PRA et PCA : plans de reprise et de continuité d'activité
 PRA et PCA : plans de reprise et de continuité d'activité PRA et PCA : plans de reprise et de continuité d'activité
PRA et PCA : plans de reprise et de continuité d'activité
 
Presentation des failles_de_securite
Presentation des failles_de_securitePresentation des failles_de_securite
Presentation des failles_de_securite
 
comprendre angularJS en 10 minutes
comprendre angularJS en 10 minutescomprendre angularJS en 10 minutes
comprendre angularJS en 10 minutes
 
Les 10 risques liés aux applications mobiles
Les 10 risques liés aux applications mobilesLes 10 risques liés aux applications mobiles
Les 10 risques liés aux applications mobiles
 
Découverte d'aeSecure, sécurisation et optimisation sites Apache
Découverte d'aeSecure, sécurisation et optimisation sites ApacheDécouverte d'aeSecure, sécurisation et optimisation sites Apache
Découverte d'aeSecure, sécurisation et optimisation sites Apache
 
Support Java Avancé Troisième Partie
Support Java Avancé Troisième PartieSupport Java Avancé Troisième Partie
Support Java Avancé Troisième Partie
 
Débuter avec Rails::API & AngularJS
Débuter avec Rails::API & AngularJSDébuter avec Rails::API & AngularJS
Débuter avec Rails::API & AngularJS
 
Ces outils qui vous font gagner du temps
Ces outils qui vous font gagner du tempsCes outils qui vous font gagner du temps
Ces outils qui vous font gagner du temps
 
Tester unitairement une application java
Tester unitairement une application javaTester unitairement une application java
Tester unitairement une application java
 

Similaire à Sécurité des applications Web

La gestion du risque et de la sécurité en mode Agile
La gestion du risque et de la sécurité en mode AgileLa gestion du risque et de la sécurité en mode Agile
La gestion du risque et de la sécurité en mode AgileAgile Montréal
 
Logiciel libre et sécurité
Logiciel libre et sécuritéLogiciel libre et sécurité
Logiciel libre et sécuritéPatrick Genoud
 
F-Secure Protection Services for Business
F-Secure Protection Services for BusinessF-Secure Protection Services for Business
F-Secure Protection Services for BusinessNRC
 
Security Day "Définitions, Risques et Droits" par Fouad Guenane
Security Day "Définitions, Risques et Droits" par  Fouad Guenane Security Day "Définitions, Risques et Droits" par  Fouad Guenane
Security Day "Définitions, Risques et Droits" par Fouad Guenane WEBDAYS
 
Cybersécurité - Comment protéger ses activités ?
Cybersécurité - Comment protéger ses activités ?Cybersécurité - Comment protéger ses activités ?
Cybersécurité - Comment protéger ses activités ?Alain EJZYN
 
Cap sur la cyberrésilience : anticiper, résister, réagir
Cap sur la cyberrésilience : anticiper, résister, réagirCap sur la cyberrésilience : anticiper, résister, réagir
Cap sur la cyberrésilience : anticiper, résister, réagirEY
 
Nomadisme, Sécurité & Expérience utilisateur
Nomadisme, Sécurité & Expérience utilisateurNomadisme, Sécurité & Expérience utilisateur
Nomadisme, Sécurité & Expérience utilisateurMathieu Isaia | TheGreeBow
 
Ch_1 - Généralités sur la sécurité informatique.pdf
Ch_1 - Généralités sur la sécurité informatique.pdfCh_1 - Généralités sur la sécurité informatique.pdf
Ch_1 - Généralités sur la sécurité informatique.pdfNafissa11
 
2014 09-25-club-27001 iso 27034-presentation-v2.2
2014 09-25-club-27001 iso 27034-presentation-v2.22014 09-25-club-27001 iso 27034-presentation-v2.2
2014 09-25-club-27001 iso 27034-presentation-v2.2Sébastien GIORIA
 
ANSSI D2IE Formation à la cybersécurité des TPE / PME
ANSSI D2IE Formation à la cybersécurité des TPE / PMEANSSI D2IE Formation à la cybersécurité des TPE / PME
ANSSI D2IE Formation à la cybersécurité des TPE / PMEpolenumerique33
 
resume-theorique-m206-v1-0-630dcd4c22d1d (1).pdf
resume-theorique-m206-v1-0-630dcd4c22d1d (1).pdfresume-theorique-m206-v1-0-630dcd4c22d1d (1).pdf
resume-theorique-m206-v1-0-630dcd4c22d1d (1).pdfFootballLovers9
 
resume-theorique-m206-v1-0-62f6e972d0748.pdf
resume-theorique-m206-v1-0-62f6e972d0748.pdfresume-theorique-m206-v1-0-62f6e972d0748.pdf
resume-theorique-m206-v1-0-62f6e972d0748.pdfAmineelbouabidi
 
Démystifier la gestion des vulnérabilités
Démystifier la gestion des vulnérabilitésDémystifier la gestion des vulnérabilités
Démystifier la gestion des vulnérabilitésNRC
 
Campagne business security
Campagne business securityCampagne business security
Campagne business securityThomas Alostery
 
HUB2B-DLM MIS 2012
HUB2B-DLM MIS 2012HUB2B-DLM MIS 2012
HUB2B-DLM MIS 2012VeilleMag
 
Présentation Axiopole
Présentation AxiopolePrésentation Axiopole
Présentation AxiopoleVeilleMag
 
Security intelligence overview_may 2015 - fr
Security intelligence overview_may 2015 - frSecurity intelligence overview_may 2015 - fr
Security intelligence overview_may 2015 - frSerge Richard
 
2020-06-06 Power Saturday 2020 - Cyber sécurité Microsoft 365 par la pratique
2020-06-06 Power Saturday 2020 - Cyber sécurité Microsoft 365 par la pratique2020-06-06 Power Saturday 2020 - Cyber sécurité Microsoft 365 par la pratique
2020-06-06 Power Saturday 2020 - Cyber sécurité Microsoft 365 par la pratiquePatrick Guimonet
 
Combler les écarts en sécurité de l'information
Combler les écarts en sécurité de l'informationCombler les écarts en sécurité de l'information
Combler les écarts en sécurité de l'informationmichelcusin
 

Similaire à Sécurité des applications Web (20)

La gestion du risque et de la sécurité en mode Agile
La gestion du risque et de la sécurité en mode AgileLa gestion du risque et de la sécurité en mode Agile
La gestion du risque et de la sécurité en mode Agile
 
Logiciel libre et sécurité
Logiciel libre et sécuritéLogiciel libre et sécurité
Logiciel libre et sécurité
 
F-Secure Protection Services for Business
F-Secure Protection Services for BusinessF-Secure Protection Services for Business
F-Secure Protection Services for Business
 
Security Day "Définitions, Risques et Droits" par Fouad Guenane
Security Day "Définitions, Risques et Droits" par  Fouad Guenane Security Day "Définitions, Risques et Droits" par  Fouad Guenane
Security Day "Définitions, Risques et Droits" par Fouad Guenane
 
Cybersécurité - Comment protéger ses activités ?
Cybersécurité - Comment protéger ses activités ?Cybersécurité - Comment protéger ses activités ?
Cybersécurité - Comment protéger ses activités ?
 
Cap sur la cyberrésilience : anticiper, résister, réagir
Cap sur la cyberrésilience : anticiper, résister, réagirCap sur la cyberrésilience : anticiper, résister, réagir
Cap sur la cyberrésilience : anticiper, résister, réagir
 
Nomadisme, Sécurité & Expérience utilisateur
Nomadisme, Sécurité & Expérience utilisateurNomadisme, Sécurité & Expérience utilisateur
Nomadisme, Sécurité & Expérience utilisateur
 
Ch_1 - Généralités sur la sécurité informatique.pdf
Ch_1 - Généralités sur la sécurité informatique.pdfCh_1 - Généralités sur la sécurité informatique.pdf
Ch_1 - Généralités sur la sécurité informatique.pdf
 
2014 09-25-club-27001 iso 27034-presentation-v2.2
2014 09-25-club-27001 iso 27034-presentation-v2.22014 09-25-club-27001 iso 27034-presentation-v2.2
2014 09-25-club-27001 iso 27034-presentation-v2.2
 
ANSSI D2IE Formation à la cybersécurité des TPE / PME
ANSSI D2IE Formation à la cybersécurité des TPE / PMEANSSI D2IE Formation à la cybersécurité des TPE / PME
ANSSI D2IE Formation à la cybersécurité des TPE / PME
 
resume-theorique-m206-v1-0-630dcd4c22d1d (1).pdf
resume-theorique-m206-v1-0-630dcd4c22d1d (1).pdfresume-theorique-m206-v1-0-630dcd4c22d1d (1).pdf
resume-theorique-m206-v1-0-630dcd4c22d1d (1).pdf
 
resume-theorique-m206-v1-0-62f6e972d0748.pdf
resume-theorique-m206-v1-0-62f6e972d0748.pdfresume-theorique-m206-v1-0-62f6e972d0748.pdf
resume-theorique-m206-v1-0-62f6e972d0748.pdf
 
Démystifier la gestion des vulnérabilités
Démystifier la gestion des vulnérabilitésDémystifier la gestion des vulnérabilités
Démystifier la gestion des vulnérabilités
 
Campagne business security
Campagne business securityCampagne business security
Campagne business security
 
HUB2B-DLM MIS 2012
HUB2B-DLM MIS 2012HUB2B-DLM MIS 2012
HUB2B-DLM MIS 2012
 
Présentation Axiopole
Présentation AxiopolePrésentation Axiopole
Présentation Axiopole
 
Security intelligence overview_may 2015 - fr
Security intelligence overview_may 2015 - frSecurity intelligence overview_may 2015 - fr
Security intelligence overview_may 2015 - fr
 
2020-06-06 Power Saturday 2020 - Cyber sécurité Microsoft 365 par la pratique
2020-06-06 Power Saturday 2020 - Cyber sécurité Microsoft 365 par la pratique2020-06-06 Power Saturday 2020 - Cyber sécurité Microsoft 365 par la pratique
2020-06-06 Power Saturday 2020 - Cyber sécurité Microsoft 365 par la pratique
 
Sécurité &amp; Continuité
Sécurité &amp; ContinuitéSécurité &amp; Continuité
Sécurité &amp; Continuité
 
Combler les écarts en sécurité de l'information
Combler les écarts en sécurité de l'informationCombler les écarts en sécurité de l'information
Combler les écarts en sécurité de l'information
 

Plus de Klee Group

Web Sémantique — Linked Data
Web Sémantique — Linked DataWeb Sémantique — Linked Data
Web Sémantique — Linked DataKlee Group
 
Introduction AOP
Introduction AOPIntroduction AOP
Introduction AOPKlee Group
 
Panorama d'applications Web
Panorama d'applications WebPanorama d'applications Web
Panorama d'applications WebKlee Group
 
Application lifecycle management
Application lifecycle managementApplication lifecycle management
Application lifecycle managementKlee Group
 
Intégration continue
Intégration continueIntégration continue
Intégration continueKlee Group
 

Plus de Klee Group (10)

HTML5
HTML5HTML5
HTML5
 
Web Sémantique — Linked Data
Web Sémantique — Linked DataWeb Sémantique — Linked Data
Web Sémantique — Linked Data
 
Introduction AOP
Introduction AOPIntroduction AOP
Introduction AOP
 
Panorama d'applications Web
Panorama d'applications WebPanorama d'applications Web
Panorama d'applications Web
 
Internet@TV
Internet@TVInternet@TV
Internet@TV
 
noSQL
noSQLnoSQL
noSQL
 
Drools
DroolsDrools
Drools
 
Talend
TalendTalend
Talend
 
Application lifecycle management
Application lifecycle managementApplication lifecycle management
Application lifecycle management
 
Intégration continue
Intégration continueIntégration continue
Intégration continue
 

Sécurité des applications Web

  • 1. Prez Flash :: Sécurité des applications Web Auteur : Julien Bourdin © Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin 1 1
  • 2. Agenda Introduction Le concept de sécurité Les protections indispensables Les attaques typiques © Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin 2
  • 3. Objectif de la présentation Cette présentation a pour but de présenter un large ensemble de problèmes de sécurité à prendre en compte dans un projet web. La présentation précisera en premier ce que le terme « sécurité » signifie au sens large, son périmètre et le discours qui doit l’accompagner. Ensuite, la présentation passera en revu un certain nombre des attaques possibles contre une application web en expliquant comment elles procèdent et surtout comment s’en prémunir © Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin 3
  • 4. Agenda Introduction Le concept de sécurité Les protections indispensables Les attaques typiques © Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin 4
  • 5. Le concept de sécurité La sécurité est une gestion des risques. © Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin 5
  • 6. La gestion des risques Lister les évènements qui peuvent survenir Estimer la probabilité de les voir arriver Estimer le coût lorsqu’un évènement se produit Estimer le coût pour réduire la chance que l’évènement en question se produise Méthodologie EBIOS © Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin 6
  • 7. La gestion des risques Le coût du risque  Probabilité du risque que multiplie le coût de l’évènement : P x C  À comparer avec le coût pour réduire le risque et au coût des autres risques. Conséquences  Tout risque identifié n’est pas un risque à corriger, on compare le coût de chacun des risques  Tout comme il existe de la surqualité, il existe des abus de sécurité Il n’est pas possible de réduire à 0 l’ensemble des risques ! © Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin 7
  • 8. Les différents domaines de la sécurité Intégrité des données Confidentialité des données Disponibilité des services Responsabilité des personnes © Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin 8
  • 9. Les différents domaines de la sécurité Intégrité des données  Transactions, Détection des incohérences, Sauvegarde Confidentialité des données  Authentification, Droits d’accès, Détection d’intrusion Disponibilité des services  Redondance, Récupération après incident, DOS, Supervision Responsabilité des personnes  Usage indu, Traçabilité, Maintenance © Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin 9
  • 10. La sécurité est une chaîne Chaque composant et chaque acteur apportent des risques Sur un type de menace donné, l’application à la sécurité de son maillon le plus faible La solution la plus efficace pour réduire le risque n’est pas nécessairement une solution technique Inutile de mettre une porte blindée si les murs sont en papier Inutile d’avoir une serrure 5 points si on laisse les clefs sous le paillasson Inutile d’avoir un SSO complexe si votre mot de passe est « 1234 » ou « password » © Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin 10
  • 11. La sécurité est un investissement Les bonnes pratiques, une fois acquises, permettent un niveau de sécurité correcte à moindre coût. © Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin 11
  • 12. Agenda Introduction Le concept de sécurité Les protections indispensables Les attaques typiques © Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin 12
  • 13. la première faille de sécurité © Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin 13
  • 14. la première faille de sécurité © Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin 14
  • 15. L’être humain est la première faille de sécurité Tout collaborateur n’est pas aussi bienveillant qu’on le souhaiterait :  la majorité des sabotages sont le fait de collaborateurs dans les entreprises Les relations hiérarchiques sont plus fortes que les règles de sécurité :  une secrétaire donne à son patron le mot de passe par téléphone s’il lui demande. La vigilance n’est pas une culture  On ne vérifie pas l’identité de la personne qui arrose les plantes  On prête son compte à son collègue pour ses congés On n’aime pas les contraintes pesantes ! © Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin 15
  • 16. Il est important de former et d’informer Ce qui est vécu comme une contrainte est souvent contourné Ce qui semble anodin n’est pas source d’attention Seule la formation de chaque personne permet de limiter le « piratage social » Il faut donc responsabiliser  les utilisateurs  les décideurs  les concepteurs  les développeurs  les exploitants © Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin 16
  • 17. Sécurité : la valeur des procédures Toute intervention sur un système apporte le risque d’introduire de nouveaux problèmes  Cela est encore plus vrai dans le cas de systèmes complexes comme les systèmes d’informations La disponibilité, la confidentialité et la cohérence des systèmes sont menacées lors de chaque intervention  Chaque intervention doit déclencher des contrôles précis sous une responsabilité précise  Un journal des interventions doit être tenu  L’état antérieur à l’intervention doit pouvoir être restauré Il est indispensable de formaliser les interventions récurrentes (livraisons, maintenances préventives…) Il est indispensable de tracer toutes les interventions sur un support consulté par les exploitants © Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin 17
  • 18. Les failles évidentes Essayez donc /typo3/install © Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin 18
  • 19. Les failles évidentes Changer les mots de passe par défaut Supprimer les dossiers et fichiers inutiles (MISC, .bak, .sql) Utilisez du HTTPS si votre application transmet des mots de passe en clair Ayez des certificats valides pour votre HTTPS Limitez l'accès au back-office / à l’application aux personnes pertinentes par une technique forte (LAN ou VPN) Mettez à jour les logiciels supports et les bibliothèques Choisissez vos bibliothèques (en évitant les versions obsolètes ou expérimentales) Désactivez l'option "indexes" d'APACHE © Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin 19
  • 20. Gestion des comptes Un compte utilisateur doit être attaché à une unique personne L’accès doit être restreint par des mots de passe non triviaux  Interdiction d’utiliser le login ou un mot de passe par défaut !  Interdiction d’utiliser le prénom de sa fille ou son année de naissance !  Interdiction d’utiliser les mots de passe type de l’entreprise ! Les droits doivent appartenir à des groupes Les droits donnés sont ceux nécessaires et suffisants pour les tâches confiées La délégation se fait en donnant des droits au compte du responsable par délégation Un mot de passe ne doit jamais être transmis, encore moins pas courriel © Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin 20
  • 21. Limiter la portée des intrusions Une brèche ne doit pas emporter tout le système ! © Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin 21
  • 22. Limiter la portée des intrusions Limitez les privilèges : les comptes administrateurs Limitez les comptes superadmin le plus possible  Un administrateur KLEE, un chez le client s’il a la compétence Activez un envoi de mail avertissant de la connexion d’un compte superadmin N’utilisez ce type de compte que pour les actions le nécessitant ! © Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin 22
  • 23. Limiter la portée des intrusions Limitez les privilèges : les droits d’écritures Les droits d’écriture sur les fichiers ne sont pas donnés à Apache / TomCat / … en dehors de de quelques répertoires bien choisis  les livraisons sont faites avec un compte distinct Ne laissez pas en production d‘outils donnant accès à la base de données ou au système de fichiers (phpmyadmin, terminal virtuel, etc.) Interdisez la livraison de contenus exécutables par l’interface Web (cas des produits à modules) © Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin 23
  • 24. Limiter la portée des intrusions Assurez-vous de la conservation des données Sauvegardez  vos environnements  vos données Vérifiez le bon fonctionnement de ces sauvegardes Validez les processus de restauration Cryptez les données confidentielles (mot de passe) et ne laissez pas de dumps accessibles © Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin 24
  • 25. Limiter la portée des intrusions N’accordez qu’un crédit limité à une protection donnée © Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin 25
  • 26. Surveillez les indicateurs de votre site Vérifiez dans les logs si des URL inconnues existent Cherchez si des variations de bande passante/nombre de hit apparaissent Vérifiez que l’espace disque, la mémoire occupée ou la charge CPU Réagissez en cas de doute ! © Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin 26
  • 27. Agenda Introduction Le concept de sécurité Les protections indispensables Les attaques typiques © Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin 27
  • 28. Le déni de service © Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin 28
  • 29. Qu’est-ce que le déni de service ? Une attaque en déni de service vise à rendre impossible le bon fonctionnement d’un service en saturant un composant de l’architecture rendant ces services. Il peut donc s’agir de saturer de requête la plateforme, mais cela peut aussi prendre des tours plus particuliers  Saturation de la base de données  Appel répété sur le moteur de recherche ou sur certaines pages vulnérables  Ajout de scripts infinis dans un contenu L’objet peut être simplement le déni de service, mais cela peut aussi avoir comme but de faire disparaître le serveur pour usurper ensuite son identité (spoofing) © Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin 29
  • 30. Se protéger contre le déni de service : attaque frontale Dimensionnez votre plateforme pour une pointe de trafique pertinente Activez les caches applicatifs et empêcher les contournements de ces derniers Mettez un reverse proxy avec un timeout : Il faut pouvoir délester en retournant un message d’erreur Limitez les pools de connexions à la BDD et les processus Apache Supervisez et alertez en cas de montée en charge non anticipée © Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin 30
  • 31. Se protéger contre le déni de service : écritures Limitez les possibilités d’écriture sur le serveur : pas de dépôt de fichiers ni d’écriture en base non régulés N'écrivez pas en base de données depuis un accès anonyme sauf avec protection anti-robot (livre d'or, commentaire, etc.) Supervisez l'espace sur file system et dans la BDD : alerte lors de franchissement de seuils ! © Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin 31
  • 32. Se protéger contre le déni de service : un exemple sur TYPO3 Le cache de TYPO3 est en base de données ! Une URL n’est acceptée que si elle répond à un certain nombre de critères comme la validité des paramètres soumis. Sont acceptées par défaut les variables « id » et « type » Les autres variables ne sont valables que si elles ont été signées par la génération d’une URL depuis TYPO3. La signature, le cHash, est le résultat d’un MD5 des données concaténées et d’une clef privée du serveur http://monsite.com/index.php?id=2&L=3&tx_ttnews[tt_news]=23&cHash=a7024cb7 © Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin 32
  • 33. Le spam depuis votre serveur Votre serveur peut devenir une source de spam ! © Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin 33
  • 34. Le spam depuis votre serveur Un serveur capable d’envoyer des mails doit être maîtrisé ! Le risque est de voir un écran exploité par un robot pour diffuser largement des publicités Un écran pouvant provoquer l’envoi d’un mail doit respecter au moins une des règles ci-dessous :  Le courriel est destiné à une unique boîte à lettres (contact)  Le formulaire ne peut être soumis qu’après un test identifiant un humain plutôt qu’un robot  Le courriel aura un contenu fixe, dépendant de paramètre non modifiable sur l’écran  Les courriels ne peuvent être envoyés que sur un domaine interne (intranet) La quantité de courriels envoyés par l’application doit être supervisée Vous risquez, en cas de souci, de voir votre serveur d’envoi de courriel dans les listes noires © Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin 34
  • 35. L’injection SQL Une injection SQL est l’utilisation d’instruction du langage SQL au sein d’un paramètre sensé ne contenir que de la donnée. © Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin 35
  • 36. Exemple : la connexion par login et mot de passe SELECT * FROM USERS WHERE LOGIN = '$_GET['login']' AND PASSWORD = '$_GET['password']'; Il lui suffit donc de saisir Monlogin';# pour que la requête devienne : SELECT * FROM USERS WHERE LOGIN = 'Monlogin';#' AND PASSWORD = ''; La bonne méthode consiste à considérer la saisie comme des caractères non susceptibles de déclencher des commandes MySQL (voir mysql_real_escape_string) SELECT * FROM USERS WHERE LOGIN = 'Monlogin'; #' AND PASSWORD = ''; Note : en aucun cas, la requête présentée n’est la bonne façon de gérer une authentification ! © Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin 36
  • 37. Se prémunir de l’injection SQL Si possible, préférez les requêtes préparées (prepared statement) qui n’attendent que des données et qui ne sont donc pas sensibles à l’injection Vérifiez toujours la nature des données insérées dans les requêtes Ne donnez à l’utilisateur SQL de l’application que le minimum de droits nécessaires (pas de DROP, TRUNCATE…) Ne stockez pas en base de mots de passe lisibles Ayez des sauvegardes régulières des données Utilisez les mécanismes du Framework / de l’API / du Langage pour générer le SQL © Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin 37
  • 38. L’injection SQL au quotidien © Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin 38
  • 39. L’injection de script (XSS) © Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin 39
  • 40. L’injection de script (XSS) Le principe de cette stratégie d’attaque est de profiter de l’affichage de données envoyées par l’utilisateur pour inclure des éléments de HTML ou de script non prévu Le moyen d’en faire une agression est d’inclure du script qui va soumettre à l’extérieur la saisie de données confidentielles Pour arriver à créer ce contexte, il faut fournir par un moyen ou un autre, une URL portant ces données. Ce sera typiquement par l’envoi de mails malicieux ou par une mise en ligne d’un lien sur un autre site © Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin 40
  • 41. Le Cross Site Scripting : cas concret Un moteur de recherche propose un champ de saisie et passe les données sous la forme : http://www.monsite.fr/index.php?wsearch=mot_recherche Les résultats sont présentés avec un rappel « votre recherche : mot_recherche » Si on remplace dans l’URL par wsearch=<script type="text/JavaScript">…</script> (moyennant un encodage de l’URL) On obtient une page dans laquelle, selon le traitement, on a un script inclus et interprété là où l’on croyait avoir un simple mot © Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin 41
  • 42. Le XSS : vérifier le type de vos sorties ! Normalement, une donnée utilisateur est d’un type simple :  Nombre  Texte  choix dans un menu déroulant… Ce ne sont pas des typages techniques !  Une chaîne de caractère et un texte simple ne sont pas la même chose Le cas simple : prendre la donnée à afficher et s’assurer que tous les caractères ne sont pas interprétés en HTML : htmlspecialchars en PHP Les cas complexes : autorisations de certaines balises par une analyse spécifique © Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin 42
  • 43. Bonne pratique : la programmation par contrat Chaque méthode définit le format de ses entrées et de ses sorties Les variables sont vérifiées par des assertions qui, en cas de non-respect, stoppent l’exécution function mafonction($a,$b){ assertion(type1,$a); assertion(type2,$b); $retour = corpsdemethode(); assertion(typesortie,$retour); return $retour; } Ce motif est à appliquer le plus souvent possible Il est impératif chaque fois que l’on définit un service recevant des données utilisateurs, proposant des données pour affichage ou devant agir sur les contenus © Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin 43
  • 44. Le Cross Site Request Forgery (CSRF) © Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin 44
  • 45. Le Cross Site Request Forgery (CSRF) La plupart des outils utilisent, avec raison, des URLs explicites:  http://www.monsite.fr/index.php?action=supprimer&id=35 Ces URL sont donc prévisibles même pour un utilisateur n’ayant pas le droit d’exécuter celle-ci Une personne va donc tenter de faire jouer cette URL à une personne ayant les droits à son insu  En proposant le lien dans le href d’une balise image sur une page susceptible d’être consultée  En proposant un JavaScript de la même façon © Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin 45
  • 46. Le Cross Site Request Forgery (CSRF) L’agression est difficile à détecter : c’est une personne ayant les droits qui fait les actions La faiblesse est accrue par les contextes de type SSO : la personne peut ne pas encore s’être authentifié à l’application et faire toutefois l’action L’attaque est d’autant plus facile à mener que les URL d’écriture passent leur paramètre en GET (possibilité d’utiliser des liens simple) © Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin 46
  • 47. Le Cross Site Request Forgery (CSRF) Il faut ajouter un élément non prévisible dans les URL Il faut que les URL ne soient pas rejouable Exemple de solution : ajouter une date et une signature du serveur http://www.monsite.fr/index.php ?action=supprimer&id=35&date=timestamp&cHash=jgs37829DE Il faut évidemment également privilégier l’usage de POST au lieu de GET pour toute action de modification de données ! © Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin 47
  • 48. Questions ? © Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin 48
  • 49. Questions ? Retrouvez-nous sur le blog technique de KLEE http://blog.kleegroup.com/teknics teKnics@kleegroup.com @teKnics_Klee © Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin 49