Prez Flash :: Sécurité des                          applications Web                                                      ...
Agenda                                                                   Introduction                                     ...
Objectif de la présentation       Cette présentation a pour but de présenter un large ensemble de problèmes de       sécur...
Agenda                                                                   Introduction                                     ...
Le concept de sécurité                                    La sécurité est une gestion des risques.© Klee Group  Prez Flas...
La gestion des risques       Lister les évènements qui peuvent survenir       Estimer la probabilité de les voir arriver  ...
La gestion des risques       Le coût du risque           Probabilité du risque que multiplie le coût de l’évènement : P x...
Les différents domaines de la sécurité       Intégrité des données       Confidentialité des données       Disponibilité d...
Les différents domaines de la sécurité       Intégrité des données           Transactions, Détection des incohérences, Sa...
La sécurité est une chaîne       Chaque composant et chaque acteur apportent des risques       Sur un type de menace donné...
La sécurité est un investissement    Les bonnes pratiques, une fois acquises,   permettent un niveau de sécurité correcte ...
Agenda                                                                   Introduction                                     ...
la première faille de sécurité© Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin   13
la première faille de sécurité© Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin   14
L’être humain est la première faille de sécurité       Tout collaborateur n’est pas aussi bienveillant qu’on le souhaitera...
Il est important de former et d’informer       Ce qui est vécu comme une contrainte est souvent contourné       Ce qui sem...
Sécurité : la valeur des procédures       Toute intervention sur un système apporte le risque d’introduire de nouveaux    ...
Les failles évidentes                      Essayez donc /typo3/install© Klee Group  Prez Flash  Sécurité des application...
Les failles évidentes       Changer les mots de passe par défaut       Supprimer les dossiers et fichiers inutiles (MISC, ...
Gestion des comptes       Un compte utilisateur doit être attaché à une unique personne       L’accès doit être restreint ...
Limiter la portée des intrusions                 Une brèche ne doit pas emporter tout le système !© Klee Group  Prez Flas...
Limiter la portée des intrusions     Limitez les privilèges : les comptes administrateurs       Limitez les comptes supera...
Limiter la portée des intrusions     Limitez les privilèges : les droits d’écritures       Les droits d’écriture sur les f...
Limiter la portée des intrusions     Assurez-vous de la conservation des données       Sauvegardez           vos environn...
Limiter la portée des intrusions                       N’accordez qu’un crédit limité                         à une protec...
Surveillez les indicateurs de votre site       Vérifiez dans les logs si des URL inconnues existent       Cherchez si des ...
Agenda                                                                   Introduction                                     ...
Le déni de service© Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin   28
Qu’est-ce que le déni de service ?       Une attaque en déni de service vise à rendre impossible le bon fonctionnement d’u...
Se protéger contre le déni de service :                                       attaque frontale       Dimensionnez votre pl...
Se protéger contre le déni de service :                                       écritures       Limitez les possibilités d’é...
Se protéger contre le déni de service :                                       un exemple sur TYPO3       Le cache de TYPO3...
Le spam depuis votre serveur                   Votre serveur peut devenir une source de spam !© Klee Group  Prez Flash  ...
Le spam depuis votre serveur Un serveur capable d’envoyer des mails doit être maîtrisé !       Le risque est de voir un éc...
L’injection SQL      Une injection SQL est l’utilisation d’instruction du langage SQL au sein d’un paramètre      sensé ne...
Exemple : la connexion par login et                                       mot de passe SELECT * FROM USERS WHERE LOGIN = $...
Se prémunir de l’injection SQL       Si possible, préférez les requêtes préparées (prepared statement) qui n’attendent que...
L’injection SQL au quotidien© Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin   38
L’injection de script (XSS)© Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin   39
L’injection de script (XSS)       Le principe de cette stratégie d’attaque est de profiter de l’affichage de données      ...
Le Cross Site Scripting : cas concret       Un moteur de recherche propose un champ de saisie et passe les données sous la...
Le XSS : vérifier le type de vos sorties !       Normalement, une donnée utilisateur est d’un type simple :           Nom...
Bonne pratique : la programmation par contrat       Chaque méthode définit le format de ses entrées et de ses sorties     ...
Le Cross Site Request Forgery (CSRF)© Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin    44
Le Cross Site Request Forgery (CSRF)       La plupart des outils utilisent, avec raison, des URLs explicites:           h...
Le Cross Site Request Forgery (CSRF)       L’agression est difficile à détecter : c’est une personne ayant les droits qui ...
Le Cross Site Request Forgery (CSRF)       Il faut ajouter un élément non prévisible dans les URL       Il faut que les UR...
Questions ?© Klee Group  Prez Flash  Sécurité des applications Web  Julien Bourdin   48
Questions ?                                       Retrouvez-nous sur le blog technique de KLEE                            ...
Prochain SlideShare
Chargement dans…5
×

Sécurité des applications Web

3 647 vues

Publié le

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

Publié dans : Technologie
0 commentaire
3 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
3 647
Sur SlideShare
0
Issues des intégrations
0
Intégrations
199
Actions
Partages
0
Téléchargements
239
Commentaires
0
J’aime
3
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Sécurité des applications Web

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

×