La sécurité PHP pour la certification

Transcription

1 La sécurité PHP pour la certification La nouvelle version de la certification PHP inclut un bonne dose de sécurité. Si vous voulez vous préparer adéquatement à cet épreuve, voici toutes les notions que vous devrez maîtriser lors de l examen. Et si vous ne préparez pas l examen, il sera bon de connaître les notions présentées ici pour ne plus vous faire prendre au piège : XSS, injections SQL, CSRF, protection et filtrage des données, listes blanches et noires, directives de configuration. Par Ben Ramsey Un jour, Ben Parker a conseillé à son jeune neveu Peter, dont l alter ego de superhéros était Spiderman, «Beaucoup de pouvoir entraîne beaucoup de responsabilités». Il en va de même avec les applications PHP. PHP offre un ensemble riche d outils dont le pouvoir est immense. Certains se sont même demandé s il n avait pas trop de puissance. Lorsque cette puissance est utilisée avec précautions, elle permet de créer des applications robustes et complexes. Dans le cas contraire, des utilisateurs malveillants risquent d utiliser la puissance de PHP à leur avantage, par le biais d attaques diverses et variées. Ce chapitre se penche sur certains de ces vecteurs d attaques afin que vous puissiez atténuer les effets, voire les éliminer pour la plupart. La théorie et la pratique Avant de faire l analyse d attaques spécifiques et d apprendre à se protéger contre elles, il convient d avoir une solide connaissance de quelques principes de base concernant la sécurité des applications Web. Ces principes ne sont pas difficiles à cerner, mais ils exigent l application d une certaine philosophie quant aux données. En d autres termes : être conscient de l importance de la sécurité implique de considérer que toutes les entrées de données sont suspectes et qu elles doivent être filtrées avant utilisation puis protégées au moment de quitter l application. La compréhension et la mise en pratique de ces concepts sont fondamentales pour assurer la sécurité de vos applications. Toutes les données d entrée sont suspectes L aspect qui est sans aucun doute le plus important dans toute transaction est la confiance. Pouvez-vous vous fier aux données qui vous sont fournies en vue d être traitées? La réponse est simple, dès que vous connaissez l origine des données. En somme, si elles proviennent d une source étrangère telle qu un formulaire, d une chaîne de requête, voire d un fil RSS : elles ne sont pas dignes de confiance, car il s agit de données étrangères. Les données qui sont issues de ces sources, parmi beaucoup d autres, sont suspectes, car on ne peut pas s assurer qu elles contiennent ou non des caractères qui pourraient avoir une autre interprétation dans le contexte différent. Par exemple, la valeur d une chaîne de requête peut contenir des données qui ont été manipulées par un utilisateur, qui contiennent du JavaScript, qui, lorsqu elles sont renvoyées à un

2 navigateur Web, peuvent avoir des conséquences très différentes de celles qui sont attendues. En règle générale, les données qui se trouvent dans tous les tableaux de superglobales de PHP doivent être considérées comme suspectes. En effet, soit l ensemble, soit une partie des données qui en sont issues proviennent d une source externe. Même le tableau $_SERVER n est pas complètement sécuritaire, car il contient quelques données en provenance directe du navigateur client. La seule exception à cette règle concernant le tableau superglobal $_SESSION, qui réside sur le serveur et ne passe jamais par Internet. Avant de manipuler des données suspectes, il est important de les filtrer. Une fois filtrées, on peut considérer qu elles sont sûres. Deux approches existent pour le filtrage des données : l approche par liste blanche et l approche par liste noire. La liste blanche et la liste noire Les deux méthodes les plus courantes pour filtrer les entrées utilisent une liste blanche, ou une liste noire. Cette dernière constitue le moyen de filtrage le moins restrictif. Elle suppose que le programmeur connaît tout ce qui n est pas autorisé à passer. Par exemple, certains filtres de forums ne jurent que par cette approche. Elle consiste à établir une liste de mots spécifiques qui sont considérés comme inopportuns pour le forum et qui sont alors rejetés. Le problème, c est que tous les mots qui ne se trouvent pas dans cette liste sont autorisés. Par conséquent, il est nécessaire d ajouter de nouveaux mots dans la liste régulièrement, dés les modérateurs le considèrent nécessaire. Cet exemple n est peut-être pas directement lié aux problèmes spécifiques que peuvent rencontrer les programmeurs qui essaient de bloquer ce type d attaques, mais le problème inhérent au filtrage à liste noire est ici évident : les listes noires doivent être sans cesse être modifiées et rallongées à mesure que de nouveaux moyens d attaques apparaissent. Le filtrage à liste blanche est quant à lui beaucoup plus restrictif. Ils ne donnent néanmoins aux programmeurs que la possibilité d accepter les données qu il s attend à recevoir. Au lieu d identifier les données qui sont interdites, la liste blanche ne sait que repérer les données qui sont valides. Il s agit du type d informations que vous connaissez à l avance lorsque vous développez une application. Elles pourront changer à l avenir, mais vous maîtriserez les paramètres qui seront modifiés sans être victime des caprices de pirates potentiels. Comme vous avez le contrôle sur les données que vous acceptez, les pirates ne peuvent en effet passer aucune autre donnée que celles que votre liste blanche autorise. C est pourquoi les listes blanches offrent une meilleure protection contre les attaques par rapport aux listes noires. Filtrage des entrées Comme toutes les données sont suspectes et ne sont donc pas dignes de confiance, il faut filtrer vos entrées afin de vous assurer que celles que vous recevez sont bien celles que vous attendiez. Pour y parvenir, il convient d utiliser la méthode à liste blanche précédemment décrite. Prenez par exemple le formulaire HTML suivant : <form method=»post»> Utilisateur : <input type=»text» name=»username» /><br /> Mot de passe : <input type=»text» name=»password» /><br /> Couleur préférée: <select name=»color»> <option>rouge</option> <option>bleu</option> <option>jaune</option> <option>vert</option> </select><br /> <input type=»submit» /> Ce formulaire contient trois éléments d entrée : username, password, et color. Dans cet exemple, username ne doit contenir que des caractères alphabétiques, password des caractères alphanumériques et color seulement les couleurs Rouge, Bleu, Jaune ou Vert. Il est également possible d ajouter une validation du côté client grâce à JavaScript et même ne parvenant au même résultat, mais on ne peut pas toujours forcer les utilisateurs à utiliser uniquement nos formulaires, et par conséquent, à suivre nos règles de validations du côté client. Le filtrage du côté serveur est donc incontournable pour la sécurité, tandis que la validation du côté client est importante pour l ergonomie. Pour filtrer les entrées qui sont reçues dans ce formulaire, il faut commencer par initialiser un tableau vierge. Il convient d utiliser un nom pour ce tableau qui se démarque de ceux qui ne contiennent que des données brutes. Par exemple, on peut utiliser le nom de $clean. Lorsque vous rencontrerez dans votre code la variable $clean[ username ], vous serez certains que cette valeur aura été validée. À l inverse, lorsque vous verrez $_POST[ username ], vous ne pourrez pas être sûr que les données sont dignes de confiance. Il faudra donc se débarrasser de cette variable et en utiliser une qui proviendra du tableau $clean. Le code ci-dessous donne un exemple de la manière de filtrer les données pour ce formulaire.

3 $clean = array(); Les dossiers nexen.net if (ctype_alpha($_post[ username ])) $clean[ username ] = $_POST[ username ]; if (ctype_alnum($_post[ password ])) $clean[ password ] = $_POST[ password ]; $colors = array(rouge, Bleu, Jaune, Vert ); if (in_array($_post[ color ], $colors)) $clean[ color ] = $_POST[ color ]; Le filtrage à liste blanche vous permet de garder le contrôle et vous garantit que vous ne recevrez pas de données manipulées. Si, par exemple, quelqu un essaie de faire passer un nom d utilisateur ou une couleur non autorisée au script de traitement, le pire qui pourra arriver sera que le tableau $clean ne contiendra pas de valeur pour username ou color. Si username est requis, il suffira alors simplement d afficher un message d erreur à l utilisateur pour lui demander de fournir les données correctes. Forcez l utilisateur à donner les informations adéquates au lieu d essayer de les nettoyer pour les rendre saines vous-même. Si vous tentez d assainir les données, vous risquez de finir par avoir de mauvaises données, et vous rencontrerez donc les mêmes problèmes que ceux qui découlent de l utilisation des listes noires. La protection des sorties Elles concernent toutes les données qui quittent votre application et qui sont destinées à un client : le client est à prendre au sens large. Dans ce cas, le client peut aller d un navigateur Web à un serveur de base de données, et tout comme vous devez filtrer toutes les entrées, vous devez également protéger toutes les données qui sortent. Tandis que le filtrage des entrées protège votre application des données, la protection des sorties prémunit le client et l utilisateur contre les commandes potentiellement préjudiciables. Il évite que votre application Web ne serve de vecteur pour atteindre une autre ressource. Toutefois, il ne faut pas considérer la protection des sorties comme faisant partie du processus de filtrage. Ces deux étapes, même si elles sont toutes deux aussi importantes, servent des intérêts distincts. En effet, le filtrage garantit la validité des données qui entrent dans l application, tandis que la protection vous prémunit, ainsi que vos utilisateurs, contre les attaques potentiellement nuisibles. Les sorties doivent être protégées, car les clients, c est-à-dire les navigateurs Web, les serveurs de bases de données, et ainsi de suite, prennent des mesures lorsqu ils rencontrent des caractères spéciaux. Pour les navigateurs Web, ces caractères spéciaux prennent la forme de balises HTML. Quant aux serveurs de bases de données, ils peuvent aller des guillemets aux mots clés SQL. Par conséquent, il faut connaître la destination voulue des sorties et les protéger en conséquence. La protection des sorties qui sont destinées à une base de données ne suffira pas pour les envoyer à un navigateur Web. Il faudra les protéger en fonction de leur destination. Étant donné que la plupart des applications PHP font la jonction entre le Web et les bases de données, cette section se concentrera sur la protection des sorties pour ces médias, mais il faudra toujours faire attention à la destination de vos sorties, ainsi qu aux caractères spéciaux ou commandes que la destination pourra accepter et manipuler, afin de protéger ces caractères ou ces commandes en conséquence. Pour protéger des sorties destinées à un navigateur Web, PHP propose les fonctions htmlspecialchars() et htmlentities(). Cette dernière est la plus complète et c est pourquoi elle est recommandée. Le code cidessous illustre l utilisation de la fonction htmlentities() dans le but de préparer les sorties avant de les envoyer au navigateur. Il illustre également un autre concept : celui de l utilisation d un tableau qui a été tout spécialement conçu pour enregistrer les sorties. Grâce à la préparation des données de sortie dans un tableau particulier, vous n aurez pas à deviner si les données ont été ou non protégées lors de leur utilisation. Si vous rencontrez une variable dans votre script qui va être transmise à un autre système et qu elle ne fait pas partie de ce tableau, vous pourrez alors la considérer comme suspecte. Cette habitude rend votre code plus facile à lire et à entretenir. Pour cet exemple, imaginez que la valeur de $user_ message provient d un jeu de résultats d une base de données. $html = array(); $html[ message ] = htmlentities($user_message, ENT_QUOTES, UTF-8 ); echo $html[ message ]; Protégez les sorties destinées à un serveur de base de données, comme dans une commande SQL avec la fonction *_escape_string() particulière au pilote pour la base de données utilisée, et lorsque c est possible, utilisez des commandes préparées. Puisque PHP 5.1 est livré avec l extension PDO, vous pourrez utiliser des commandes préparées avec tous les moteurs de bases de données qui possèdent un pilote PDO. Si le moteur de la base de données ne

4 supporte pas nativement les commandes préparées, alors PDO émulera cette fonctionnalité pour vous : simple et transparent. L utilisation de commandes préparées vous permet de spécifier les espaces réservés dans une commande SQL. Cette dernière pourra alors être utilisée à répétition : elle placera les valeurs fournies dans les espaces réservés à chaque exécution. Le moteur de bases de données, ou PDO s il y a eu une émulation des instructions préparées, se chargera de protéger les valeurs de la commande. Le code ci-dessous vous offre un simple exemple de la mise en relation de paramètres à une instruction préparée. // D abord, filtrage des entrées $clean = array(); if (ctype_alpha($_post[ username ])) $clean[ username ] = $_POST[ username ]; // Set a named placeholder in the SQL statement for username $sql = SELECT * FROM users WHERE username = : username ; // Assume the database handler exists; prepare the statement $stmt = $dbh->prepare($sql); // Bind a value to the parameter $ s t m t - > b i n d P a r a m ( : u s e r n a m e, $clean[ username ]); régler $loggedin = FALSE en haut du script ou de désactiver les register_globals, ce qui est plus conseillé. Si le réglage des register_globals sur Off constitue la meilleure méthode, il est bon de prendre l habitude de toujours initialiser les variables. if (checklogin()) $loggedin = TRUE; if ($loggedin) // do stuff only for logged in users Notez que l un des avantages d avoir les register_ globals activées, c est qu il est possible d ignorer l origine de la donnée. Dans l exemple précédent, l utilisateur pouvait régler $loggedin à partir d une chaîne de requête, d un formulaire ou d un cookie. Rien ne peut limiter la mesure dans laquelle l utilisateur peut le régler, et rien n identifie l étendue d où il provient. Le meilleur moyen d obtenir du code possible à maintenir et gérable consiste à utiliser le tableau de superglobales pour l emplacement dont vous pensez que les données ont leur origine, à savoir : $_GET, $_POST, ou $_COOKIE. Cela permet d accomplir deux choses : premièrement, vous connaîtrez l origine des données, et deuxièmement, les utilisateurs seront forcés de suivre vos règles lorsqu ils enverront des données à votre application. // Execute and fetch results $stmt->execute(); $results = $stmt->fetchall(); Register Globals Lorsqu elle est réglée sur On, la directive de configuration register_globals injecte automatiquement des variables dans les scripts. En d autres termes, toutes les variables qui proviennent d une chaîne de requête, de formulaires, de sessions, de cookies, etc, seront disponibles dans le corps principal du script, et apparaîtront comme des variables natives. Par conséquent, si les variables ne sont pas initialisées avant utilisation, il est alors possible qu un utilisateur injecte des valeurs dans les scripts et compromette ainsi une application. Observez le code suivant, qui est utilisé dans un environnement où register_globals activé. La variable $loggedin n est pas initialisée. Par conséquent, si un utilisateur voit que checklogin() pourrait échouer, il pourra facilement régler $loggedin en passant loggedin=1 dans la chaîne de la requête. Mais tout le monde pourra avoir accès à une partie restreinte du site. Pour éviter de courir ce risque, il faut simplement Avant PHP 4.2.0, l instruction de configuration des register_globals était activée par défaut. Depuis, cette directive désactive par défaut, et elle n existera plus dans PHP 6 : soyez prévenus. La sécurité des sites Web La sécurité des sites Web fait référence à la sécurité des éléments d un site Web auxquels un pirate peut s interfacer pour communiquer avec votre application. Ces points vulnérables d entrée comprennent les formulaires et les URL, qui représentent les candidats les plus vulnérables et les plus probables à une attaque. Il est donc important de vous concentrer sur ces éléments et d apprendre à vous prémunir contre l utilisation impropre de vos formulaires et de vos URL. En somme, un bon filtrage des entrées et une protection adéquate des sorties atténueront la plupart de ces risques. Les formulaires détournés Les pirates utilisent fréquemment la soumission de formulaires usurpés. L usurpation de formulaires peut se faire de diverses manières. La plus simple consiste à copier un formulaire cible et de l exécuter à partir d un endroit différent. L usurpation d un formulaire

5 permet à un pirate de supprimer toutes les restrictions côté client qui sont imposées au formulaire afin de soumettre tous types de données à votre application. Prenons le formulaire suivant : <form action=»process.php» method=»post»> <p>rue : <input type=»text» name=»street» maxlength=»100» /></p> <p>ville : <input type=»text» name=»city» maxlength=»50» /></p> <p>etat: <select name=»state»> <option value=»»>choisissez un état...</ option> <option value=»al»>alabama</option> <option value=»ak»>alaska</option> <option value=»ar»>arizona</option> <!-- options pour tous les états --> </select></p> <p>zip: <input type=»text» name=»zip» maxlength=»5» /></p> <p><input type=»submit» /></p> Ce formulaire utilise l attribut maxlength pour limiter la longueur du contenu qui est entré dans les champs. Il peut également y avoir une validation JavaScript qui teste ces restrictions avant de soumettre le formulaire à process.php. En outre, le champ select contient une liste fixe des valeurs, telles qu elles ont été définies par le formulaire. Il est courant de croire que ces valeurs sont les seules que le formulaire peut soumettre. Néanmoins, comme nous l avons vu précédemment, il est possible de recopier ce formulaire sur un autre site, ou même localement, puis de le soumettre grâce à l utilisation d une URL absolue. Prenons la version suivante du même formulaire : <form method=»post» action=» process.php»> <p>street: <input type=»text» name=»street» /></ p> <p>city: <input type=»text» name=»city» /></p> <p>state: <input type=»text» name=»state» /></ p> <p>zip: <input type=»text» name=»zip» /></p> <p><input type=»submit» /></p> Dans cette version, toutes les restrictions côté client ont été levées et l utilisateur peut entrer n importe quelle donnée sans problème : le formulaire sera ensuite soumis à qui constitue le script de traitement d origine du formulaire. Comme vous pouvez le constater, l usurpation d une soumission de formulaire est très simple. Il est pratiquement impossible de s en protéger. Vous aurez peut-être remarqué néanmoins qu il est possible de vérifier l en-tête Referer (sic) avec $_SERVER[ Referer ]. Cette parade pourra offrir une certaine protection contre les pirates qui veulent simplement copier le formulaire et l exécuter à partir d un autre emplacement. Toutefois, cette protection n est rien d autre qu une feinte. Étant donné que l en-tête HTTP Referer est envoyé par le client, il est simple à manipuler, et sa valeur attendue est toujours apparente. Quant à process.php, il s attendra à ce que l URL de préférence soit celle du formulaire d origine. En dépit du fait que les soumissions de formulaires usurpés soient difficiles à contrecarrer, il n est pas nécessaire de renier toutes les données qui proviennent d autres sources que celle de vos formulaires. En revanche, il faut veiller à ce que toutes les entrées suivent vos règles. Ne vous reposez donc pas uniquement sur les techniques de validation côté serveur. À nouveau, repensez à l importance de filtrer toutes les entrées. Le filtrage des entrées garantit que toutes les données seront conformes à une liste de valeurs acceptables et que même les formulaires usurpés ne pourront pas contourner vos règles de filtrage côté serveur. Les attaques XSS Les attaques XSS constituent le type d attaque le plus courant et le plus connu. La simplicité de cette attaque et le nombre d applications vulnérables existantes rendent cette attaque très séduisante aux yeux d utilisateurs malveillants. Une attaque XSS exploite la confiance de l utilisateur dans l application et s efforce généralement à voler les informations de l utilisateur, comme les cookies ou toute autre donnée d identification. Toutes les applications qui affichent des entrées courent ce risque. Par exemple, prenez le formulaire suivant. Il peut exister sur n importe lequel des nombreux sites communautaires populaires qui existent aujourd hui. Il permet à un utilisateur d ajouter un commentaire au profil d un autre utilisateur. Après soumission du commentaire, la page affiche tous les autres commentaires, afin que tout le monde puisse les voir à gauche du profil de l utilisateur. <form action=»process.php» method=»post»> <p>add a comment:</p>

6 <p><textarea name=»comment»></textarea></p> <p><input type=»submit» /></p> Imaginez qu un utilisateur malveillant soumette un commentaire concernant le profil d un autre utilisateur qui contient ce qui suit : l exemple suivant. Imaginez que vous ayez un site Web sur lequel les utilisateurs doivent ouvrir un compte pour pouvoir parcourir un catalogue de vente de livres. Imaginez maintenant qu un utilisateur malveillant ouvre un compte et commence à chercher à acheter un livre sur le site. Au fur et à mesure, il pourra apprendre ce qui suit grâce à une simple observation : <script> document.location = + document.cookie; </script> Maintenant, toutes les personnes qui visiteront le profil de cet utilisateur seront redirigées vers l URL présentent dans le commentaire et leurs cookies, y compris toutes les informations de connexion et identifiables comme étant personnelles, seront ajoutées à la fin de la chaîne de la requête. Le pirate pourra alors avoir facilement accès aux cookies avec $_GET[ cookies ] et les enregistrer pour les utiliser ultérieurement. Ce type d attaque ne fonctionne que si l application n a pas protégé ses affichages. Par conséquent, il est facile d éviter ce type d attaque grâce à une bonne protection des sorties. Les attaques CSRF Un détournement de requêtes intersites, plus connus sous le nom d attaque CSRF, consiste à forcer une victime à envoyer sans le savoir des requêtes HTTP, généralement à des URL qui requièrent un accès privilégié et qui utilisent la session existante de la victime pour obtenir cet accès. La requête HTTP force la victime à exécuter une action spécifique en se basant sur son niveau de privilèges : par exemple, effectuer un achat, modifier ou supprimer des informations. Si une attaque XSS exploite la confiance de l utilisateur dans une application, une requête contrefaite exploite la confiance d une application dans un utilisateur : la requête semblera être légitime et l application ne pourra pas savoir s il s agissait de l intention de l utilisateur ou pas. La protection correcte des sorties évite à votre application d être utilisée comme véhicule pour une attaque CSRF, mais elle ne la protégera pas contre la réception de requêtes contrefaites. Par conséquent, votre application doit pouvoir déterminer si la requête est intentionnelle et légitime ou si elle est éventuellement contrefaite et malintentionnée. Avant d étudier les moyens de se protéger contre les requêtes contrefaites, il peut être utile de comprendre comment une telle attaque peut se produire. Prenons Il doit se connecter pour effectuer un achat. Après avoir choisi un livre, il doit cliquer sur le bouton «Acheter», qui le redirige vers checkout. php. Il voit que l action qui mène à checkout.php est une action POST, mais il se demande si le fait de passer des paramètres à checkout.php par le biais de la chaîne de requête (GET) fonctionne Lorsqu il passe les mêmes valeurs du formulaire grâce à la chaîne de la requête, c est-à-dire grâce à checkout.php?isbn= &qty=1, il remarquera qu en réalité, il réussi à acheter un livre. Grâce à ses connaissances, l utilisateur malveillant pourra forcer d autres utilisateurs à effectuer des achats sur votre site sans le savoir. Le moyen le plus simple pour y parvenir consiste à utiliser une balise d image HTML pour appeler une image qui soit sur un autre serveur : attention, il se peut très bien que ce site distant soit le site local. Dans le cas suivant, la balise src de img lance une requête lorsque la page se charge. <img src=» &qty=1» /> Même si cette balise img est placée sur un site Web différent du site de la librairie ci-dessus, elle va envoyer la requête au site Web de vente de livres. En général, ce type de requête échoue, car les utilisateurs doivent être connectés pour effectuer un achat. Mais si un tel utilisateur se présente sur le site vulnérable, après avoir effectué un achat récent, il aura un cookie ou une session active. Dans ce cas, l attaque exploite la confiance du site Web dans cet utilisateur et le forcera à acheter un livre. La solution à ce type d attaque particulière est néanmoins assez simple : il faut forcer l utilisation de POST par rapport à GET. En effet, l attaque présentée ci-dessus fonctionne, car checkout.php utilise le tableau de superglobales $_REQUEST pour obtenir isbn et qty. L utilisation de $_POST atténuera le risque d encourir ce type d attaque, mais elle ne vous protégera pas totalement contre les requêtes contrefaites.

7 D autres attaques plus sophistiquées peuvent envoyer des requêtes POST aussi facilement que des requêtes GET, et une simple méthode à jeton pourra bloquer ses tentatives et forcer les utilisateurs à se servir de vos formulaires. La méthode à jeton implique l utilisation d un jeton généré aléatoirement qui est à la fois enregistré dans la session de l utilisateur lorsque ce dernier accède au formulaire, et placé dans un champ masqué dans le formulaire. Le script de traitement compare la valeur du jeton du formulaire qui a été posté avec celle de la session de l utilisateur. Si elles correspondent, la requête est alors valide. Sinon, c est que le script est suspect et qu il ne doit pas traiter les données, mais afficher à la place une erreur à l utilisateur. Le fragment de code suivant issu du formulaire susmentionné illustre l utilisation de la méthode à jeton. le formulaire pour trouver toutes les vulnérabilités éventuelles pour injecter du SQL dans les champs du formulaire. Un exemple courant consiste à se servir d un simple formulaire de connexion d un utilisateur. <form method=»login.php» action=»post»> Utilisateur : <input type=»text» name=»username» /><br /> Mot de passe : <input type=»password» name=»password» /><br /> <input type=»submit» value=»log In» /> Un exemple de code vulnérable utilisé pour traiter ce formulaire de connexion peut ressembler à : <?php session_start(); $token = md5(uniqid(rand(), TRUE)); $_SESSION[ token ] = $token;?> <form action=»checkout.php» method=»post»> <input type=»hidden» name=»token» value=»<?php echo $token;?>» /> <! Reste du formulaire --> checkout.php est le script de traitement qui gère ce formulaire, puis qui vérifie le jeton : if (isset($_session[ token ]) && $_POST[ token ] == $_SESSION[ token ]) // Le jeton est valide, on peut continuer le traitement du dossier La sécurité de la base de données Dès que vous utilisez une base de données et que vous créez dynamiquement une partie de la requête SQL à partir des données utilisateur, vous devenez une proie facile pour les attaques par injection SQL. L injection SQL se produit lorsqu un utilisateur malveillant se sert d un formulaire pour obtenir des informations sur une base de données. Après avoir recueilli suffisamment d informations, généralement grâce aux messages d erreur, le pirate peut exploiter $username = $_POST[ username ]; $password = md5($_post[ password ]); $sql = SELECT * FROM users WHERE username = $username AND password = $password ; /* Connexion à la base de données et exécution */ if (count($results) > 0) // Identification correcte Dans cet exemple, vous noterez qu il n y a pas de code pour filtrer l entrée $_POST. À la place, l entrée brute est directement placée dans la variable $username. Cette entrée brute est ensuite utilisée dans la commande SQL. Rien n est donc protégé. Le pirate peut se connecter avec un nom d utilisateur aléatoire à l aide de cette valeur : username OR 1 = 1 -- Grâce à ce nom d utilisateur et à un mot de passe vierge, la commande SQL est maintenant : SELECT * FROM users WHERE username = username OR 1 = 1 -- AND password = d41d8cd98f00b204e ecf 8427e Comme 1 = 1 est toujours vrai et que -- débute un commentaire SQL, la requête SQL ignorera tout ce qui se trouvera après -- et retournera tous les enregistrements de l utilisateur. Cela est suffisant pour que le pirate puisse se connecter. En outre, si le pirate connaît le nom d utilisateur, il pourra

8 l utiliser dans cette attaque en vue d usurper l identité l utilisateur en obtenant l accès à ses coordonnées. Les attaques par injection SQL sont dues à une protection et à un filtrage insuffisants. En somme, un bon filtrage des entrées et une protection adéquate des sorties pour SQL réduiront considérablement ce risque d attaque. Pour protéger les requêtes SQL, utilisez la fonction *_escape_string() spécifique au pilote de votre base de données. Si possible, utilisez les paramètres de requête, ou encore les requêtes préparées. Pour plus d informations sur ces derniers, reportez-vous à la section précédente Protection des sorties de ce chapitre sur les Bases de données et SQL. La sécurité des sessions Deux formes courantes d attaques de sessions sont la fixation de session et le piratage de session. Alors que la plupart des autres attaques décrites dans ce chapitre peuvent être évitées grâce au filtrage des entrées et à la protection des sorties, les attaques de session ne peuvent pas l être ainsi. Il faut à la place les prévoir et identifier les zones potentiellement vulnérables de votre application. Lorsqu un utilisateur visite pour la première fois une page de votre application qui appelle la fonction session_start(), une session est créée pour lui. PHP génère un identifiant de session aléatoire pour identifier l utilisateur, puis il envoie un en-tête Set- Cookie au client. Par défaut, le nom de ce cookie est PHPSESSID, mais il est possible de le modifier dans php.ini. Au cours de ses prochaines visites, le client identifiera l utilisateur avec le cookie, et c est ainsi que l application connaîtra son état. Il est néanmoins possible de forcer l identifiant de session manuellement, grâce à la chaîne de la requête, en forçant l utilisation d une session en particulier. Cette simple attaque s appelle une fixation de session, car le pirate impose la valeur de l identifiant de session. Il y arrive généralement en créant un lien vers votre application et en le mettant à la fin de l identifiant de session que le pirate souhaite donner à n importe quel utilisateur qui cliquera sur le lien. <a href=» =1234»>cliquez ici </a> Alors que l utilisateur sera en train d accéder à votre site par le biais de cette session, il pourra fournir des informations sensibles voire ses coordonnées de connexion. Si l utilisateur se connecte grâce à l identifiant de session fourni, le pirate sera capable de «s inviter» sur la même session et obtenir les mêmes accès au compte de l utilisateur. C est pourquoi on fait parfois référence à la fixation de session sous le nom de «chevauchement de session». Puisque le but de cette attaque est d obtenir un plus haut niveau de privilèges, les points qu il faut surveiller sont évidents : à chaque fois que le niveau d accès d une connexion est modifié, il faut générer à nouveau l identifiant de session pour renouveler le contrat entre vous et l utilisateur. PHP sait le faire simplement grâce à la fonction session_regenerate_id(). session_start(); // Si l utilisateur s identifie, on regénère l identifiant de session if (authenticate()) session_regenerate_id(); Si cette méthode évite aux utilisateurs de voir leurs sessions piratées, ce qui offrirait un accès facile à leur compte, l autre attaque de session courante est le piratage de session : un pirate tente d obtenir l identifiant de session valide de l utilisateur, par tous les moyens possibles et imaginables. La fixation de session n est qu un moyen parmi d autres, mais imaginez qu un utilisateur se connecte. Si l identifiant de sa session est regénéré, il aura un nouvel identifiant de session sécuritaire. Que se passe-t-il alors si un pirate obtient ce nouvel identifiant et tente de l utiliser pour avoir accès à la session de cet utilisateur? Il sera alors nécessaire d utiliser d autres moyens pour identifier l utilisateur. Parmi ceux-ci, pour identifier l utilisateur ainsi que l identifiant de sa session, il faut vérifier divers entêtes de requête qui ont été envoyés par le client. L un des en-têtes de requête qui est particulièrement utile et qui ne change pas entre les requêtes est l en-tête User-Agent. Comme il est fort peu possible qu un utilisateur change de navigateur alors qu il utilise la même session, cet en-tête pourra être utilisé pour détecter une éventuelle tentative de piratage de session. Si cette tentative réussit, il faut enregistrer l agent User-Agent dans la session : $_SESSION[ user_agent ] = $_SERVER[ HTTP_USER_ AGENT ]; Puis, aux prochains chargements de pages, comparez la valeur de l en-tête User-Agent avec celui qui est enregistré en session. S il a été modifié, il faut de s en inquiéter : le mieux est de faire que l utilisateur s identifie à nouveau. if ($_SESSION[ user_agent ]!= $_SERVER[ HTTP_ USER_AGENT ])

9 Les dossiers nexen.net // Force user to log in again exit; include ou require. Dans cet exemple, le filtrage peut être aussi simple que la spécification d un certain ensemble de valeurs attendues pour section: L injection de code distant Lorsque vous incluez des fichiers avec include et require, faites particulièrement attention à l utilisation de données suspectes dans la création du chemin qui mène au fichier inclus. Lorsque vous utilisez des données suspectes pour inclure un fichier avec include ou require, vous encourez un grand risque, car les pirates pourront lancer une attaque par injection de code distant. Ce type d attaque se produit lorsqu un pirate est en mesure de forcer votre application à exécuter du code PHP de leur choix. Cela peut avoir des effets dévastateurs à la fois pour votre application et pour votre système. Par exemple, de nombreuses applications se servent des variables des chaînes de requête pour structurer l application en plusieurs sections, telles que : example.org/?section=news. Une telle application peut utiliser une assertion include pour inclure un script qui s affichera dans la section «actualité» : include «$_GET[ section ]/data.inc.php»; Lorsque le script utilisera l URL appropriée pour accéder à cette section, il inclura le fichier qui se trouve dans news/data.inc.php. Néanmoins, imaginez ce qui pourrait arriver si un pirate avait modifié la chaîne de la requête pour inclure du code néfaste qui se trouve sur un site distant? L URL suivante illustre comment un pirate peut y parvenir : example.org%2fattack.inc%3f Dès lors, la valeur suspecte de section est injectée dans l assertion include, ce qui donne un résultat semblable à : include « data.inc.php»; Maintenant, l application inclut attack.inc qui se trouve sur le serveur distant. Le serveur distant traitera / data.inc.php comme faisant partie de la chaîne de la requête. Tout code PHP qui se trouve dans attack. inc sera ajouté dans le script exécuté : le pirate peut lancer l attaque de son choix, en manipulant à sa guise le code PHP sur votre serveur! Cette attaque est très puissante, car elle permet au pirate d obtenir les mêmes privilèges dont jouit le serveur Web. Il est pourtant facile de s en protéger grâce au filtrage de toutes les entrées et en n utilisant jamais de données suspectes dans une assertion $clean = array(); $sections = array( home, news, photos, blog ); if (in_array($_get[ section ], $sections)) $clean[ section ] = $_GET[ section ]; else $clean[ section ] = home ; include «clean[ section ]/data.inc.php»; La directive allow_url_fopen La directive allow_url_fopen de PHP activer une fonctionnalité qui lui permet d accéder aux URL, en les traitant comme des fichiers. C est cette autorisation qui permet qu une attaque telle que celle décrite ici est possible. Par défaut, allow_url_fopen est activée; toutefois, il est possible de la désactiver via php.ini : en le réglant sur Off, cela évite à vos applications d inclure ou d ouvrir des URL distantes comme si elles étaient des fichiers. Le réglage de cette directive sur Off limite l utilisation de fonctions telles que fopen(), file_get_contents(), ou encore simplexml_load_file(); en effet, elles ne pourront plus être en mesure d accéder aux fichiers distants. Cette directive n affecte pas les fonctions CURL. L injection de commande Si le fait qu un client autorise des entrées afin d inclure les fichiers est un comportement dangereux, il en va de même lorsqu il autorise l utilisation de commandes système. Si PHP offre une grande puissance grâce aux fonctions exec() et passthru(), elles ne doivent pas être utilisées à la légère et il est extrêmement important de vérifier que les pirates n injectent pas et n exécutent pas de commandes système arbitraires. À nouveau, un bon filtrage des entrées et une protection adéquate des sorties atténueront se risque. Je préconise une approche de filtrage à liste blanche, car elle limite le nombre de commandes que les utilisateurs peuvent exécuter. PHP propose également les fonctions escapeshellcmd() et escapeshellarg() pour protéger de manière adéquate les sorties Shell. Lorsque cela est possible, évitez d utiliser les commandes Shell. Si elles sont nécessaires, évitez d utiliser les entrées du client pour construire des commandes Shell dynamiques. L hébergement partagé Les solutions d hébergement partagé posent tout un Octobre

10 ensemble de problèmes de sécurité. Par le passé, PHP a essayé de résoudre certains d entre eux grâce à la directive safe_mode. Néanmoins, comme le souligne le manuel de PHP, il est «incorrect au niveau de l architecture d essayer de résoudre ce problème au niveau de PHP». C est pourquoi safe_ mode ne sera pas disponible en PHP 6. Pourtant, il existe trois directives php.ini qui restent importantes dans un environnement d hébergement partagé : open_basedir, disable_functions, et disable_classes. Ces directives ne dépendent pas de safe_mode, et resteront disponibles dans PHP. La directive open_basedir permet de limiter les fichiers que PHP peut ouvrir dans un arbre de répertoire spécifique. Quand PHP essaie d ouvrir un fichier avec, par exemple, la fonction fopen() ou la méthode include, il vérifie l emplacement du fichier. Si le fichier existe à l intérieur de l arbre de répertoire spécifié par open_basedir, il sera autorisé à l ouvrir. Sinon, il refusera de l ouvrir. Vous pouvez régler la directive open_basedir dans php.ini ou selon des cas particuliers dans httpd.conf. Dans l exemple d hôte virtuel suivant httpd.conf, les scripts de PHP pourront ouvrir les fichiers qui se trouvent dans les répertoires /home/user/www et/usr/local/lib/php. Ce dernier se trouve généralement à l emplacement de la bibliothèque PEAR : ; Disable classes disable_classes = DirectoryIterator,Directory Résumé Les pages précédentes ont décrit certaines des attaques les plus courantes que rencontrent les applications Web et vous ont expliqué comment vous en protégez ou comment atténuer le risque de ces attaques. Six mots peuvent résumer la plupart des solutions aux problèmes de sécurité des applications Web, même s ils échouent parfois : filtrage en entrée, protection en sortie. L application de ces bonnes pratiques sécuritaires vous permettra de tirer le meilleur parti de la grande puissance qu offre PHP, tout en réduisant le pouvoir de pirates potentiels. Quoi qu il en soit, il en va de votre responsabilité. <VirtualHost *> DocumentRoot /home/user/www ServerName <Directory /home/user/www> php_admin_value open_basedir «/home/user/ www/:/usr/local/lib/php/» </Directory> </VirtualHost> Les directives disable_functions et disable_classes fonctionnent de manière semblable, et vous permettent de désactiver certaines fonctions et classes PHP natives pour des questions de sécurité. Toutes les fonctions de toutes les classes énumérées ne seront pas disponibles sur les applications PHP qui fonctionneront sur le système. Il est également possible de les régler dans php.ini. L exemple suivant illustre l utilisation de ces directives en vue de désactiver des fonctions et des classes spécifiques : ; Disable functions disable_functions = exec,passthru,shell_ exec,system Octobre