Astuces de sécurité en PHP

Traduction des Security Tips de la DevZone

| Cal Evans | Matthew Weier O'Phinney | Guillaume Rossolini |

Cal Evans, rédacteur en chef de la DevZone, publie de temps en temps des astuces sécurité pour PHP dont voici la traduction en français. Attention, le classement est chronologique (selon la date de publication) et non selon l'importance des astuces.

Commentez ♪

- Titre : Astuces de sécurité en PHP

- Auteurs : Cal Evans, Matthew Weier O'Phinney, Guillaume Rossolini

- Parution : 1 janvier 2007

- Licence : Copyright ® 2007 Guillaume Rossolini. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.

Sommaire

- I. Introduction

- I-A. Remerciements

- I-B. Préambule

- II. Astuces 1 à 9

- #1 : Tenez votre version de PHP à jour

- #2 : N'affichez pas les erreurs en production

- #3 : Auditez votre code

- #4 : Évitez les noms par défaut

- #5 : Ne faites jamais confiance à l'utilisateur

- #6 : Pour utiliser des nombres dans du SQL, castez systématiquement

- #7 : Nettoyez les sessions

- #8 : Validez systématiquement l'input utilisateur

- #9 : Conservez les informations et le code sensibles à l'extérieur de votre arborescence Web

- III. Astuces 10 à 19

- #10 : N'envoyez pas aveuglément un e-mail à partir d'un formulaire

- #11 : Le principe des privilèges minima

- #12 : Attention avec eval()

- #13 : PHPSecInfo

- #14 : Restreindre le contenu des cookies

- #15 : Supprimez les fichiers temporaires de diagnostic

- #16 : Tenez votre framework à jour

- #17 : PHP Security Consortium

- #18 : N'autorisez pas l'upload de scripts PHP

- #19 : L'application la plus sécurisée n'a aucun contact avec le monde extérieur

- IV. Astuces 20 et +

- #20 : Les livres à lire

- #21 : Inscrivez-vous à la newsletter de Security Focus

- V. Conclusion

- V-A. Épilogue

- V-B. Liens

I - Introduction

I-A - Remerciements

Cal Evans, bien sûr, pour publier ces astuces et pour m'avoir autorisé à les traduire en français.

I-B - Préambule

La sécurité en PHP est un sujet trop souvent pris à la légère ou ignoré par les développeurs. Lors de l'apprentissage, la sécurité est souvent délaissée afin d'apprendre plus rapidement à entrer dans le vif du sujet ; le problème est que l'on y revient rarement par la suite… Cal Evans propose chaque semaine une nouvelle astuce sécurité et je vais essayer de tenir le rythme en les traduisant ici.

II - Astuces 1 à 9

#1 : Tenez votre version de PHP à jour

Vous recherchez l'astuce ultime ? J'ai de mauvaises nouvelles pour vous, elle n'existe pas. La sécurité est à la fois un effort constant et de nombreuses petites choses, plutôt qu'une seule astuce toute puissante. Cette semaine nous lançons une nouvelle section sur la DevZone : « L'astuce sécurité de la semaine ». Pour faire correctement les choses, nous allons en publier une par jour durant le mois de mars. Quelques-unes de ces astuces seront des actions spécifiques que vous pourrez entreprendre, certaines seront des concepts généraux dont il faut avoir conscience, toutes seront brèves. Sans plus de préambule, voici la première astuce.

Tenez à jour votre version de PHP.

De même qu'avec n'importe quel autre langage, des vulnérabilités seront découvertes. Utiliser la version la plus récente et se tenir au courant des améliorations vous aidera à conserver des applications sécurisées, efficaces et stables.

La version actuelle de PHP peut toujours être trouvée ici.

Si vous souhaitez partager une astuce sécurité, enregistrez-vous sur la DevZone et sélectionnez le lien Contribute dans le coin supérieur droit. Nous sommes une communauté, faisons de la sécurité un effort communautaire.

#2 : N'affichez pas les erreurs en production

La sécurité par obfuscation n'est pas de la sécurité le moins du monde. D'un autre côté, il n'est pas non plus souhaitable de donner des informations sur votre site. L'astuce qui suit est simple, mais elle est fréquemment ignorée en environnement de production.

Assurez-vous de ne pas afficher les erreurs et ainsi de potentiellement divulguer des informations sur votre site.

En mettant display_errors à OFF dans le php.ini de votre serveur de production, vous empêchez la divulgation d'informations qui pourraient donner aux attaquants des indices quant à la structure de votre système. Par défaut, display_errors est à ON.

Vous trouverez davantage d'informations et de possibilités de rapport d'erreur dans la section « Introduction à la Gestion des erreurs et aux fonctions de log » du manuel.

#3 : Auditez votre code

Être conscient de la sécurité est une bonne chose, mais cela ne résout pas tout le problème. Les développeurs doivent être vigilants lorsqu'il s'agit de sécurité. Et même ainsi, vous ne pouvez pas le faire seul. L'astuce d'aujourd'hui vous le rappelle.

Puisque votre application pourrait contenir des failles de sécurité auxquelles vous avez été exposé, des services et applications tiers devraient être pris en considération afin d'aider à faire intervenir une nouvelle perspective et à trouver les faiblesses qui n'ont pas encore été identifiées.

En tant que développeur, vous devriez avoir dans votre trousse à outils des éléments vous aidant à trouver les faiblesses de sécurité dans vos applications. Des outils comme Chorizo vous aideront à analyser automatiquement votre code. Des programmes comme PHPSecInfo vous assureront d'avoir un environnement configuré convenablement.

Utiliser de tels outils et des scanneurs ne devrait pas être les seules mesures prises pour améliorer la sécurité. Cependant, elles ont une part importante dans l'ensemble. Laissez à des projets et à des éditeurs de confiance le soin de vous aider à construire des applications sécurisées.

#4 : Évitez les noms par défaut

Le proverbe dit : « La sécurité par obfuscation n'est pas de la sécurité ». Cependant, le revers de la médaille est que l'obfuscation, lorsqu'utilisée comme partie d'une stratégie d'ensemble, est une bonne chose. Il n'y a aucun intérêt à rendre la vie facile à ceux qui ont des intentions malicieuses. Cela nous ramène à notre astuce du jour.

Évitez les noms par défaut pour les fichiers et les répertoires contenant des informations primordiales.

Ne vous comptez pas sur des noms obscurs pour améliorer la sécurité de votre application. Vous devriez toujours vérifier les droits d'accès, tester les vulnérabilités avec des outils et garder un œil sur les fichiers log pour veiller aux activités suspicieuses. Cela dit, au moment de construire le design de vos applications et de vos sites Web, ne facilitez pas la tâche des mauvaises personnes pour ayant de mauvaises intentions. N'utilisez pas des noms par défaut ou trop communs pour vos fichiers et répertoires.

#5 : Ne faites jamais confiance à l'utilisateur

La sécurité en PHP est une mission continue qui demande au programmeur de penser aux paramètres externes à l'application. Il n'est plus suffisant, de nos jours, de simplement penser « Cela fait-il ce que je veux ? » ; vous devez également prendre en compte « De quelle autre manière les gens peuvent-ils l'utiliser, est-ce que je souhaite les y autoriser ? ». L'astuce d'aujourd'hui est un proverbe que tous les programmeurs devraient réciter quotidiennement :

Ne jamais faire confiance à l'utilisateur.

C'est un triste fait dans la vie, mais les utilisateurs sont vils. Ils ne cherchent rien de mieux que de trouver un moyen d'exploiter votre application. Dès que vous laissez tomber votre garde et que vous commencez à penser « je vends seulement de petites peluches, mes utilisateurs sont-ils vraiment méchants ? », vous avez perdu la bataille.

OK, ce n'est peut-être pas aussi dramatique, mais vous devez garder un œil vigilant sur vos visiteurs. C'est ici qu'intervient le second proverbe à réciter quotidiennement par tous les développeurs :

Filtrer la source (input), protéger la sortie (output). (Filter Input, Escape Output)

Oui, FIEO (OK, cela n'a pas aussi bonne allure que GIGO) est l'un des mantras que tous les programmeurs qui pensent à la sécurité doivent adopter.

#6 : Pour utiliser des nombres dans du SQL, castez systématiquement

Le thème de l'écriture d'applications PHP sécurisées couvre davantage que simplement écrire du bon code PHP. La plupart des applications utilisent une base de données, quel qu'en soit le type. Bien souvent, des vulnérabilités affectant toute l'application sont introduites en construisant du code SQL. L'astuce du jour traite d'une solution simple que les développeurs peuvent implémenter.

Toujours caster les valeurs numériques en les envoyant dans les requêtes SQL.

Même si vous filtrez l'input, une bonne méthode de sécurité (et simple à mettre en place) est de caster les valeurs numériques dans la requête SQL. Prenez par exemple le code suivant :

$myId = filter_var($_GET['id'], FILTER_VALIDATE_INT);
$sql = 'SELECT * FROM table WHERE id = '.$myId;

Même si vous appliquez le filtre natif de PHP 5.2, vous pouvez ajouter un niveau de protection. Essayez plutôt ceci :

$myId = filter_var($_GET['id'], FILTER_VALIDATE_INT);
$sql = 'SELECT * FROM table WHERE id = '.(int)$myId;

Ce cast final en valeur entière enlève tous les doutes quant à ce qui est envoyé à MySQL. L'exemple ci-dessus est volontairement simplifié. En situation réelle, le code serait plus complexe et le risque d'erreur serait bien plus grand. En appliquant le dernier cast lors de la construction de la requête, vous introduisez un niveau supplémentaire de sécurité.

#7 : Nettoyez les sessions

L'astuce d'aujourd'hui vient de Kevin Schröder et des jeunes (mais néanmoins doués) esprits des Services Professionnels Zend.

Lorsque vous utilisez session_regenerate_id() pour protéger contre l'attaque « session fixation », il est généralement une bonne idée de supprimer l'ancien ID de session.

Par exemple, le script :

<?php
session_start();
$_SESSION['data'] = time();
session_regenerate_id();
?>

Allez une première fois à l'URL et consultez le répertoire /tmp :

sess_82c6980017e100277a63983142fd454c
sess_a4bab88e6dfa6e900ade21e3fbd27a53

Allez-y une seconde fois, vous verrez :

sess_984c5230acca90b5a75eddb89bb48354
sess_a4bab88e6dfa6e900ade21e3fbd27a53
sess_82c6980017e100277a63983142fd454c

Allez-y une nouvelle fois, vous verrez :

sess_984c5230acca90b5a75eddb89bb48354
sess_a4bab88e6dfa6e900ade21e3fbd27a53
sess_82c6980017e100277a63983142fd454c
sess_dd88c05b724d80b30c90309847f2e919

Ces sessions sont encore actives. Pour les supprimer en régénérant l'ID, utilisez le code suivant :

<?php
session_start();
$_SESSION['data'] = time();
session_regenerate_id(true);
?>

Si vous utilisez votre propre gestionnaire de session, cela aura pour effet d'appeler votre fonction « destroy » de callback.

Bien que cela ne fasse ou ne détruise pas une application sécurisée, cela vous apporte un niveau supplémentaire de sécurité contre la fixation de session et cela vous coûte seulement quatre caractères de code.

#8 : Validez systématiquement l'input utilisateur

Dans les sujets de sécurité PHP, il y a toujours plus d'une manière d'accomplir une tâche. Souvent, c'est en combinant des tactiques que l'on obtient la meilleure sécurité. Nous avons déjà parlé de filtrer les données, mais, au-delà de filtrer, nous devons rester vigilants et valider les données provenant de l'utilisateur. Cela nous amène à notre astuce du jour.

Toujours valider l'input utilisateur.

Prenez par exemple le code suivant :

<?php
$myFile = filter_var($_GET['file'], FILTER_SANITIZE_STRING);
include($myFile);
?>

Appeler http://example.com/file.php?file=home.php obligera votre script à inclure le script home.php dans le répertoire courant. Toutefois, si quelqu'un venait à demander l'adresse http://example.com/file.php?file=badcode.php, vous vous exposez potentiellement à exécuter son code ou bien votre code que vous ne souhaitez pas exécuter dans ce contexte.

Ne dépendez pas uniquement de file_exists(). Simplement parce que c'est un fichier local ne signifie ni que le fichier est valide, ni qu'il est à vous. Ne facilitez pas la tâche aux pirates pour exécuter leur code sur votre serveur.

Pour protéger de cela, toujours filtrer et valider :

<?php
// Filtrer
$myFile = filter_var($_GET['file'], FILTER_SANITIZE_STRING);

// Puis valider
$valid = array('home.php', 'about.php');
if (!in_array($myFile, $valid)) {
die('Va-t’en, vil pirate');
}

include($myFile);
?>

#9 : Conservez les informations et le code sensibles à l'extérieur de votre arborescence Web

Ce sont parfois les idées les plus simples qui sont les plus importantes. Cette idée semble simple, mais je suis toujours surpris par la faible quantité de personnes qui la comprennent et qui l'implémentent.

Conservez les informations et le code sensibles à l'extérieur de votre arborescence Web

Considérez la structure suivante :

/htdocs
/includes
/images
/js

Si vous conservez vos informations de connexion à la base de données dans un fichier db.inc et que vous le placez dans le répertoire includes, il est possible pour quelqu'un de télécharger vos informations en allant à l'adresse http://example.com/includes/db.inc. Puisque la plupart des serveurs ne donnent pas d'informations spécifiques sur la manière de gérer les fichiers .inc, ils sont traités comme du texte s'ils sont demandés directement. Les implications sont évidentes. Si vous conservez les informations de connexion dans un fichier portant une extension autre que « .php » et à l'intérieur de la racine de votre serveur Web, il y a de grandes chances pour que vous laissiez filer des informations.

La solution est simple. Placez toutes vos informations sensibles à l'extérieur de la racine du serveur Web. De nombreux experts argumentent qu'il est mieux de placer la majorité, si ce n'est l'ensemble, du code PHP à l'extérieur de la racine de votre serveur Web. Puisque PHP n'est pas limité par les mêmes restrictions que votre serveur Web, vous pouvez faire un répertoire au même niveau que votre serveur Web et y placer toutes vos informations et votre code sensibles.

/phpinc
/includes
/htdocs
/images
/js

III - Astuces 10 à 19

#10 : N'envoyez pas aveuglément un e-mail à partir d'un formulaire

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.

Ne pas envoyer aveuglément un e-mail à partir d'un formulaire.

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.

#11 : Le principe des privilèges minima

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 :

Le principe des privilèges minimum.

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_Auth, mais le contrôle d'accès, un sujet différent est géré par 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.

#12 : Attention avec eval()

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 :

Réfléchissez attentivement avant d'utiliser eval().

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.

#13 : PHPSecInfo

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

#14 : Restreindre le contenu des cookies

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.

Toute information placée dans un cookie est potentiellement visible par d'autres personnes - réduisez au minimum.

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.

#15 : Supprimez les fichiers temporaires de diagnostic

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 :

N'oubliez pas de supprimer les fichiers temporaires de diagnostic.

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.

#16 : Tenez votre framework à jour

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 » :

Choisissez un framework qui est fréquemment mis à jour

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 !

#17 : PHP Security Consortium

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

Note du traducteur : Le Guide de la sécurité PHP est traduit en français sur le site de PHPSec.org (les définitions ci-dessus en sont extraites).

#18 : N'autorisez pas l'upload de scripts PHP

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 FileInfo. Sa documentation est accessible ici. 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.

#19 : L'application la plus sécurisée n'a aucun contact avec le monde extérieur

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.

L'application la plus sécurisée n'a aucun contact avec le monde extérieur

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.

IV - Astuces 20 et +

#20 : Les livres à lire

Pour paraphraser un patriote américain, « Le coût de la sécurité est la vigilance permanente ». Vous devez surveiller votre système, mais vous devez aussi continuer à apprendre. L'astuce d'aujourd'hui est une liste d'astuces pour essayer de garder vos connaissances au goût du jour. J'ai rassemblé quelques ressources à méditer lorsque vous recherchez des informations sur la sécurité en PHP.

Ce n'est pas une surprise si vous êtes déjà en train de lire ma première recommandation : les astuces sécurité de la DevZone ! Chaque semaine, nous posterons une nouvelle astuce pour que vous puissiez en soupeser la valeur. Ce sont généralement de petites astuces que vous pouvez lire rapidement et méditer tout au long de la journée.

Les livres à lire

Essential PHP Security par Chris Shiflett

Pro PHP Security par Chris Snyder

Professional PHP5 security par Ben Ramsey, Paul Michael Reinheimer et Jon Eaves

PHP|Architect's guide to security par Rasmus Lerdorf et Ilia Alshanetsky

Enfin, le magazine php|architect est une excellente ressource et vous devriez penser à vous y inscrire. En plus de leurs articles très détaillés, ils incluent tous les mois un article « le coin de la sécurité » (Security Corner).

Toutes ces ressources sont bonnes à lire et à ajouter à votre collection, afin de vous aider à rester sur vos gardes au moment de sécuriser votre application PHP.

#21 : Inscrivez-vous à la newsletter de Security Focus

L'astuce d'aujourd'hui est courte et facile à mettre en œuvre. Elle s'accorde très bien avec la dernière, restez vigilant. Voici une nouvelle ressource à prendre en compte.

Si ce n'est pas encore le cas, vous devriez vous inscrire à la newsletter de Security Focus

Si vous n'êtes pas encore inscrit, cliquez ici pour vous rendre à leur page des mailing lists et pour vous inscrire. Vous verrez en arrivant sur la page qu'ils ont 38 listes, ce qui amène la question « laquelle rejoindre ». La plus populaire et la plus active est celle qui recense les bogues (BugTraq list). Cette liste contient tout ce qu'il vous faut. Voici leur description :

BugTraq est une liste de diffusion modérée de type « full disclosure » pour la discussion détaillée et pour l'annonce de vulnérabilités en sécurité informatique : ce qu'elles sont, comment les exploiter et comment les résoudre.

Rejoignez BugTraq aujourd'hui et commencez à vous tenir à jour sur les vulnérabilités annoncées pour PHP en particulier et, plus généralement, des applications que vous pourriez utiliser sur votre serveur.

Lorsqu'il s'agit de construire des applications plus sécurisées, l'information est votre plus grand atout.

V - Conclusion

V-A - Épilogue

Vous n'en avez jamais assez des Astuces sécurité de la semaine ? Vous voulez savoir lorsqu'une nouvelle astuce est mise en ligne ? Nous avons mis en place un fil RSS spécialement pour vous. Utilisez ce lien pour l'ajouter à votre lecteur favori.

V-B - Liens

Liens Developpez

- Tutoriel : Developpement web : Généralités sur la sécurité, par Julien Pauli ;

- Julien Pauli parle souvent de la sécurité en PHP sur son blog ;

- La rubrique PHP traite également de la sécurité dans son blog ;

- La rubrique Sécurité : FAQ, livres, cours ;

- La rubrique PHP : FAQ, Cours.

Liens externes

- Les astuces sécurité en PHP originales, par Cal Evans (DevZone) ;

- Slides de la présentation « pièges de sécurité en PHP », par Ilia Alshanetsky.