Astuces de sécurité en PHP

Même en tout faisant correctement, il est encore possible de construire des applications PHP non sécurisées. La sécurité requiert une vigilance constante. Un aspect sur lequel vous devriez toujours garder un œil est un script ou formulaire qui envoie un e-mail selon des informations envoyées par l'utilisateur.

Comme nous en avons discuté dans d'autres astuces sur la sécurité en PHP, vous devez vous assurer de toujours filtrer et valider correctement l'input utilisateur. Si vous ne filtrez pas correctement l'input, il devient aisé pour quelqu'un de forger une injection de headers dans un mail ou bien de spammer des milliers de gens avant que vous en ayez connaissance.

Pour une lecture plus approfondie sur les injections d'e-mail, je vous recommande ce lien sur securephpwiki.com.

Je pense que nous serons tous d'accord sur un point : les utilisateurs sont à la fois notre meilleur avantage et notre plus grand fléau. D'une part, sans eux, nous n'aurions pas de problèmes de sécurité. D'autre part, nous n'aurions simplement pas d'application. Ainsi, nous sommes tous d'accord sur le fait que dans la plupart des cas, les utilisateurs ne s'en iront pas. Cela signifie que nous devons les prendre en compte dans notre mise sécurité. Un bon principe à adopter est :

Ne donnez des autorisations à vos utilisateurs qu'au niveau requis.

C'est un principe fondamental de programmation, et il peut être vu en action principalement en sécurité Unix. Lorsque l'on traite les utilisateurs et les ressources en Unix, il faut attribuer explicitement les ressources aux utilisateurs. Les permissions sont gérées de telle manière que l'on confère le moins possible d'autorisations à un utilisateur pour lui donner accès à une ressource. Nous pouvons adopter ce concept au moment de construire notre application, en considérant avec attention les utilisateurs qui ont besoin de telle page ou fonctionnalité.

La plupart des frameworks PHP modernes possèdent les concepts d'authentification ou de contrôle d'accès. Dans le Zend Framework, l'authentification est gérée par Zend_AuthDocumentation ZF : Zend_Auth, mais le contrôle d'accès, un sujet différent est géré par Zend_AclDocumentation ZF : Zend_Acl.

Quel que soit le framework choisi, les bonnes pratiques de sécurité suggèrent de soupeser avec attention les restrictions que vous placez sur chaque page ou fonctionnalité. Aussi souvent que possible, limitez l'accès au plus faible nombre d'utilisateurs que possible.

Nous avons parlé de filtrer, de valider, de filtrer à nouveau. Filtrer les données en entrée est un concept important et c'est le précurseur de maintes pratiques de sécurité. Cependant, lorsque vous avez filtré et validé les données, vous ne pouvez pas simplement croiser les doigts et vous relaxer. Vous devez rester vigilants en programmant, de manière à assurer la sécurité de part en part de l'application.

Filtrer les données en entrée donne à certains programmeurs un faux sentiment de sécurité. Ils supposent que, puisqu'ils ont filtré les données, il n'y a pas de raison de s'inquiéter. Cela peut être vrai dans certaines situations simples, mais, dans la plupart des situations complexes, vous devez être constamment conscient de ce pour quoi vous utilisez vos données. La commande eval() est le meilleur relai de cet avertissement. Cela nous amène à l'astuce d'aujourd'hui :

En utilisant des données soumises par l'utilisateur dans eval(), vous lui donnez potentiellement une porte d'entrée vers votre serveur. Même si votre application les force à choisir parmi des options définies, l'appel au script peut être forgé et votre script peut être utilisé pour exécuter des commandes à la demande, par des gens qui cherchent à vous pirater.

Utilisez eval() avec modération. Lorsque vous devez vraiment l'utiliser, prenez soin de filtrer et ensuite de valider les données. S'il y a d'autres moyens d'accomplir la même tâche, alors considérez ces autres moyens à la place.

La sécurité est un état d'esprit, pas seulement quelque chose que vous faites. Elle influe sur le design de votre application aussi bien que sur votre code. Cependant, vous devez également monitorer constamment votre environnement de production. C'est là que choisir l'outil adéquat entre en jeu. Je sais que j'ai mentionné PHPSecInfoSite officiel de PHPSecInfo auparavant, mais j'estime qu'il est suffisamment important pour justifier son propre message.

PHPSecInfo est un formidable outil pur utiliser et pour garder un œil sur votre environnement de production. Il fut écrit par Ed Finkler de CERIAS, le Centre d'Éducation et de Recherche en Assurance d'Information et en Sécurité à l'université de Purdue. C'est officiellement un projet du PHP Security Consortium. Voici ce que la page de PHPSenInfo dit à propos du projet :

PHPSecInfo fournit des informations similaires à celles données par la fonction phpinfo(), rapporte des informations de sécurité sur l'environnement PHP et propose des suggestions pour améliorer la configuration. Ce n'est pas un remplacement pour des techniques de développement sécurisé et ne fait aucune sorte d'audit de code ou d'application, mais le projet peut être un outil utile dans une approche à plusieurs niveaux.

Pour de plus amples informations, voici le lien vers une courte interview d'Ed Finkler à propos de PHPSecInfo. Voici un autre lien vers la dernière information de sortie, la version 0.2.

Comme pour toutes les mesures de sécurité, en lui-même cet outil n'est pas la panacée. Cependant, utilisé à bon escient, il peut faire partie d'une bonne solution.

Presque toutes les applications utilisant PHP comme back-end, utilise les technologies Web pour le front-end. De nombreux développeurs qui prennent la sécurité au sérieux ne pensent pas à la sécurité du front-end pour leur application. Voici une astuce pour donner matière à réflexion à propos de la construction de votre HTML et JavaScript.

C'est bien triste, mais, dans le Web d'aujourd'hui, des méchants rôdent. Leur plus cher désir est de voir votre application divulguer des informations privées, de manière à pouvoir les exploiter. Prenez garde de considérer tous les angles lorsque vous évaluez votre application. C'est très important lorsque l'on considère les informations qui restent dans le front-end.

En tant que développeurs, nous sommes pour la plupart très désordonnés. J'ai travaillé sur d'innombrables projets et, dans chacun d'eux, soit j'ai vu traîner soit j'ai laissé traîner une trace de fichiers de diagnostic (info.php, test.php, doMe.php, etc.). Ces fichiers, s'ils sont trouvés par une personne malintentionnée, peuvent divulguer des informations très utiles sur votre application.

Voici l'astuce du jour :

Il serait vraiment dommage de passer autant de temps à sécuriser votre application, si d'un autre côté vous laissez info.php ou, pire encore, un « rapide extrait de code » dans test.php qui pourrait potentiellement donner des informations dangereuses sur votre système. N'aidez pas les pirates davantage que vous le devez.

Je l'ai postée précédemment comme un commentaire, mais, puisque je considère qu'elle est très importante, cette astuce mérite sans doute son propre « security tip » :

C'est particulièrement important si vous travaillez d'une traite sur un projet pour un client. Il est important de penser à qui maintiendra le site si (ou plutôt : quand) un patch de sécurité est publié pour l'un des fichiers provenant d'un tiers.

Habituellement, ces sites sont placés sur un hébergement mutualisé et cela signifie que l'hébergeur est responsable de la tenue à jour de PHP, le SGBD, le serveur Web, etc. Cela dot, ils ne tiendront probablement pas à jour les frameworks que vous installez.

Utiliser des frameworks est généralement une bonne idée, non seulement parce qu'ils vous épargnent beaucoup de travail, mais aussi parce que n'importe quel problème de sécurité est habituellement résolu rapidement.

D'un autre côté, cela signifie que les problèmes de sécurité dans ces frameworks sont très bien documentés, et il est donc très simple pour un pirate de rechercher les anciennes versions encore utilisées, et d'exploiter ces problèmes.

J'ai vu de très, très nombreux sites qui utilisent encore des versions extrêmement vieilles et périmées, simplement car il n'y a personne pour les tenir à jour. Je suis en train de parler d'anciennes installations de PEAR (avec des problèmes connus pour le composant « Mail ») et pire !

Même si vous n'avez pas à payer vous-mêmes la facture pour la charge excessive du serveur, vous pourriez être le destinataire d'une partie du spam envoyé à ce serveur !

La sécurité d'une application ne devrait pas être une situation « quand tout le reste plante ». Ce n'est pas quelque chose que l'on peut « ajouter plus tard ». Comme nous l'avons mentionné auparavant, il n'y a pas de remède miracle pour résoudre les problèmes de sécurité de votre application. La sécurité est quelque chose que vous devriez garder à l'esprit pendant la phase de design, la phase de codage, la phase de test, même après avoir mis votre code en production.

Chris Shiflett, expert sécurité reconnu, a mis sur son site un PDFPHP Security qui devrait être une lecture obligatoire pour tous les développeurs PHP. Compilé par le PHP Security Consortium, ce guide de 37 pages explique les termes et les concepts impliqués dans la sécurité de votre application PHP. Voici comment ils décrivent la sécurité :

• La sécurité est une mesure, pas une caractéristique. Il est regrettable que tant de projets de développement logiciel réduisent la sécurité à une simple exigence à satisfaire. Est-ce que c'est sécurisé? Cette question est aussi subjective que de demander si quelque chose est super.
• La sécurité doit être en équilibre avec les dépenses. Il est facile et relativement peu cher de fournir un niveau de sécurité suffisant pour la plupart des applications. Cependant, si vos besoins en sécurité sont très exigeants, parce que vous protégez des informations de grande valeur, alors vous devez atteindre un niveau de sécurité plus élevé, à un coût supérieur. Cette dépense doit être incluse dans le budget du projet.
• La sécurité doit être en équilibre avec l'utilisabilité. Il n'est pas rare que les étapes prises pour améliorer la sécurité d'une application web diminue également son utilisabilité. Les mots de passe, timeouts de sessions et contrôles d'accès créent autant d'obstacles aux utilisateurs légitimes. Parfois, ceux-ci sont nécessaires pour fournir un niveau adéquat de sécurité, mais il n'existe pas de solution qui convienne à toutes les applications. Il est sage de penser à vos utilisateurs légitimes lorsque vous implémentez des mesures de sécurité.
• La sécurité doit faire partie de la conception. Si vous concevez votre application sans penser à la sécurité, vous êtes condamnés à constamment faire face à de nouvelles vulnérabilités de sécurité. Une programmation prudente ne peut compenser une mauvaise conception.

Si la sécurité est importante pour vous, mais que vous ne savez pas par où commencer, voici le bon endroit. Téléchargez le PDFPHP Security et passez le temps qu'il faut à le lire attentivement. Si vous êtes déjà un vétéran dans le domaine, téléchargez-le et parcourez-le. Vous pourriez y trouver de nouvelles idées.

Lorsque vous autorisez l'upload de fichiers, votre système est potentiellement en danger. Il faut toujours restreindre les types de fichiers que vous autorisez. Ne vous appuyez pas sur une approche par « liste noire ».

Par exemple, une liste noire raisonnable serait « ne pas autoriser les fichiers .php ».

C'est une bonne technique jusqu'à ce que quelqu'un uploade un fichier .htaccess : ce n'est pas un fichier PHP, ainsi la liste noire ne l'empêche pas. Mettre cette ligne dans un fichier .htaccess et l'uploader vers un système protégé seulement par une liste noire, ouvre la porte pour les pirates :

AddType application/x-httpd-php .php .htm

Ils peuvent désormais uploader n'importe fichier .htm avec du code PHP, et commencer à s'amuser avec votre système.

Par exemple :

<?php
echo system("locate config");
?>

Il y a de bonnes chances pour que le code ci-dessus donne à l'attaquant le nom de chaque fichier de configuration de votre serveur. Les possibilités d'attaques sont infinies, tout cela à cause d'un simple upload non protégé vers votre serveur.

Soyez vigilants avec les uploads de fichiers et protégez-les plutôt avec une approche « liste blanche ». Assurez-vous que le fichier uploadé est bien du type que vous attendez. Il y a plusieurs moyens de le faire, le plus simple (et le plus simple à dévier) st de vérifier l'extension du fichier uploadé. Vous pouvez facilement supprimer tout fichier n'ayant pas une extension correcte. Cependant, ce n'est pas le moyen le plus sûr.

Pour une vérification, regardez l'extension PECL FileInfoExtension PHP en PECL : FileInfo. Sa documentation est accessible iciDocumentation de FileInfo. FileInfo examine le contenu puis essaie d'en deviner le type en fonction de certaines séquences d'octets magiques. Utiliser FileInfo comme une part d'une approche liste blanche est une solution bien plus sécurisée d'autoriser les utilisateurs à uploader des fichiers.

Parfois, la meilleure mesure de sécurité est simplement de déconnecter le câble réseau de votre serveur. OK, en fait dans le monde réel ce n'est pas viable. Cependant, y penser vous met sur une voie qui peut vous mener à développer des applications plus sécurisées.

Lorsqu'il s'agit de sécurité, il faut prendre en compte le matériel aussi bien que le logiciel. L'astuce d'aujourd'hui nous vient de Chris Hartjes.

Comme nous l'avons vu, vous ne pouvez pas vraiment déconnecter votre ordinateur du réseau si vous développez des applications Web. En revanche, vous pouvez étudier quels serveurs ont besoin d'être connectés au monde extérieur et lesquels peuvent être protégés par votre firewall. Au-delà, vous pouvez également évaluer comment les serveurs qui doivent rester à l'extérieur du firewall communiquent avec ceux qui sont à l'intérieur.

Piratage de session, XSS et XSRF sont tous de sérieux problèmes pour les développeurs et je n'ai pas l'intention de les minimaliser. Cependant, dans la plupart des cas, ils sont un moyen d'obtenir quelque chose. Pour la plupart des pirates, la poule aux œufs d'or est votre base de données. Le pire problème auquel nous, développeurs, ayons à faire face de nos jours, est le piratage de notre application, notre base de données compromise et les informations qui nous ont été confiées par nos utilisateurs divulguées sur le Net.

Un moyen simple (à expliquer) permettant de rendre cela plus difficile est de déplacer votre base de données à l'intérieur de votre firewall et d'y limiter l'accès. Une fois que vous empruntez ce chemin, vous trouverez d'autres idées pour sécuriser votre système complet.

C'est juste une courte astuce pour vous mettre sur la voie, ce n'est pas un premier prix de sécurité en réseaux. Aujourd'hui, je vous laisse le soin de vous allonger dans votre sofa et, pendant quelques minutes, de réviser mentalement comment est structuré votre réseau physique. Réfléchissez à comment sont connectés les éléments et voyez si vous pouvez faire quelque chose pour les sécuriser.