Développement d’applications web

Développement d’applications web Initiation à la sécurité

Problématique / Enjeux • Système constamment soumis à des tentatives d’attaques • Protection du système • Protection des données personnelles des utilisateurs • Protection des données de notre application

Attaque sur le système • Attaques les plus graves • Mettent en jeu • L’intégrité du système • L’intégrité de toutes les données stockées sur le système

Type d’attaques les plus courantes • Attaque sur le serveur web • Attaque sur d’autres services • SSH • FTP • … • => Exécution de code arbitraire en tant qu’un certain utilisateur

Éléments de protection • Exécuter les serveurs web et ftp sous des utilisateurs n’ayant accès qu’aux fichiers qu’ils doivent servir • Sécuriser les connexions SSH • Privilégier la connexion par clé public/privé • Utiliser des utilitaires bannissant les personnes tentant de se connecter trop de fois sans succès (failtoban, iptoban, …) • Possibilité de n’accepter les connexions que de certaines IP/plages d’IP

Prévention et détection • Mettre à jour régulièrement les programmes installés • Bugfixes • Security issues • Se tenir au courant des failles potentielles existantes • Les failles connues sont souvent listées sur les sites dédiés • Consulter les logs ou utiliser un utilitaire le faisant pour détecter les tentatives d’exploitation de certaines failles

Attaques sur des applications web • Attaques cherchant à: • Exécuter une requête arbitraire en base de donnée • Insérer un code javascript dans une page • Détourner des sécurités pour accéder à des parties sécurisées d’une application • …

Importance • Moins d’impact qu’une attaque sur le système • A peu de risque de nuire à l’intégrité du système entier • Peut cependant: • Accéder à des données confidentielles • Accéder à des parties d’administration • Éviter un paiement • Récupérer des données personnelles d’utilisateurs • Effacer des données • …

Comment s’en protéger ? • Cela dépend du type d’attaque • Se tenir informer des dernières attaques effectués sur les applications que nous utilisons • Surveiller les logs

SQL injection • Principe: • Exécuter une requête arbitraire en base de données • Réalisation: • Utilisation d’un défaut de sécurité lors de l’insertion d’un élément en base de donné (un commentaire par exemple) pour exécuter la requête voulu • Risques: • Récupération des données utilisateur • Connexion en tant que n’importe que utilisateur • …

Exemple <?php mysql_query(“SELECT id FROM users WHERE name= ’“.$login. “ ‘ AND password=‘ “ .$password. “ ‘;“); ?> SELECT id FROM users WHERE name= ’dupont‘ AND password=‘ dupontpasswd‘; SELECT id FROM users WHERE name= ’dupont‘ -- ‘ AND password=‘ ‘;

Comment s’en protéger ? • Il faut échapper tous les caractères spéciaux avant de les insérer dans une requête • Des fonctions existent pour le faire • Se renseigner pour savoir si ce que l’on utilise nous protège • Utiliser des requêtes SQL paramétrées • Vérifier l’ensemble des informations fournies par l’utilisateur • …

XSS • XSS= cross site scripting • Principe: • Exécution d’un script (javascript, flash, java, …) dans le navigateur des clients • Réalisation: • Détourne l’utilisation de l’ajout de commentaire, d’un module de recherche ou autre pour insérer un script arbitraire dans une page • Risques: • Vol de cookie/session des utilisateurs • Récupération de données personnelles des utilisateurs • Infection des machines des utilisateurs par un code malin

Exemple • Quelqu’un ajoute sur notre blog un commentaire contenant: <Script language=“javascript“>…</script> • Lors de l’affichage du commentaire, le script javascript sera exécuter par le navigateur ayant chargé la page. • N’importe quel autre type de script client aurait pu être inséré (java, flash, etc.)

Solution • Toujours encoder les caractères utilisés dans les balises html avant d’affiché un texte fourni par un utilisateur. • Ceci se fait via l’utilisation de fonctions spécifique dans la plupart des langages • Vérifier que les bibliothèques, modules, framework que vous utilisez mettent en place des sécurités contre ces attaques

Modification de cookie • Qu’est-ce qu’un cookie ? • Un fichier stockant des données pour un site web • Ce fichier est renvoyé à chaque requête • Il peut contenir n’importe quel type d’information

Modification de cookie • Principe: • Modifier les informations contenu dans un cookie pour obtenir plus de droit ou éviter une sécurité ou un paiement • Réalisation: • Le cookie est un fichier texte s’il n’a pas été encodé, il suffit donc de l’éditer • Risques: • Le pirate peut obtenir le rôle d’administrateur ou éviter certaines sécurités (vérification de paiement, etc.)

Solution • Première solution: • Crypter le cookie • Quelqu’un sera toujours capable de trouver comment décrypter et pourra modifier les informations • Deuxième solution: • Fournir dans le cookie une clé d’identification • Les informations de session sont conservés sur le serveur • La clé permet de dire au serveur quelles informations regarder

url jumping • Principe: • Rentrer l’url d’une page dans la barre d’adresse sans suivre la progression imposée par le site • Réalisation: • Taper l’adresse dans la barre d’adresse de son navigateur • Risque: • Éviter un paiement ou une procédure d’authentification

Exemple • Une personne accède à l’url: • Monsite.com/administration/adminpanel.php • Si cette page ne vérifie pas que la personne est bien authentifiée, elle pourra avoir accès à cette page sans même s’être connectée.

Autre exemple • Dans une procédure d’achat en ligne: • La personne est à la page: • Monsite/achat/step3.php • Elle rentre directement l’adresse • Monsite/achat/step5.php • Si aucune vérification n’est faite, elle est peut-être passée de l’étape de paiement à l’étape de validation et d’envoie sans avoir payé.

Solution • Chaque page faisant partie d’une zone sécurisée ou d’une chaîne d’action est responsable de vérifier: • Que la personne accédant à la page est bien authentifiée • Que la personne accédant à la page a bien suivi toute la chaîne d’action • Attention, le stockage d’information directement dans le cookie n’est pas sûr (comme vu précédemment), une combinaison d’attaques reste possible

Déni de service • Principe: • Rendre inaccessible l’application • Réalisation: • Requêtes multiples, boucle « infini », … • But: • Rendre le site ou le service inaccessible

Exemple • Grand nombre de requêtes envoyées sur l’application • Remplissage de la mémoire: • … String TotalObjects = request.getParameter(“numberofobjects”); intNumOfObjects = Integer.parseInt(TotalObjects); ComplexObject[] anArray = new ComplexObject[NumOfObjects];

Solution • Limiter le nombre de requête provenant d’une même source • Ne pas utiliser de données fournies par l’utilisateur pour des boucles ou des allocations sans mettre des limites • …

Bonnes pratiques • Ne jamais croire une information entrée par un utilisateur • Formulaire, paramètre url, etc. • Toujours vérifier les informations passées d’une page à l’autre • Si une information est passée chez l’utilisateur, il faut supposer qu’elle a pu être altéré et la vérifier avant de l’utiliser • …

Plus d’informations ? • www.owasp.org • Open Web Application Security Project

Développement d’applications web