Statistiques PHPinfos()

This document is also available in English  

Tout le monde connaît la fonction phpinfo() de PHP, qui présente une foule d'informations de configuration, sinon toutes. C'est un outil indispensable dès qu'on prend en main un serveur, et on s'en sert pour discuter facilement avec l'administrateur d'un site.

Mais après la prise en main, il est généralement conseillé de le retirer, ou de ne pas le publier sans restriction d'accès. En effet, phpinfo() peut-être dangereux lui-même : il fut victime d'injections XSS dans d'anciennes versions de PHP. De plus, même inerte, il publie des informations sensibles sur l'architecture de votre site. En termes de sécurité, il est toujours conseillé de conserver ses données à l'abri.

Malheureusement, l'habitude de placer un phpinfo sur un site est maintenant bien ancrée dans la communauté, à tel point qu'il est facile de trouver des milliers de phpinfo() sur les moteurs de recherche tels que Google ou Yahoo !. Il suffit de rechercher ‘phpinfo()' avec ‘GoogleBot' et la mention "Zend Scripting Language Engine" (voir l'article d'Ilia :  Reliably locating phpinfo (45 visites))

Le revers de la médaille est donc qu'en collectant suffisamment de phpinfo() sur Internet, on peut obtenir un aperçu des choix de configuration pris par les responsables de sites. En fait, il suffit d'obtenir les URL, puis de prélever le phpinfo. Ultérieurement, on analyse le fichier pour en extraire les données, et on peut compiler énormément de statistiques différentes.

J'ai donc collecté 12000 phpinfo() sur Internet, qui ont réduit à 11048 pour servir de base à cette étude. 11000, c'est peu, en comparaison avec la population totale des serveurs Internet qui utilisent PHP : cela représente une goutte d'eau dans l'océan. En comparant avec les stocks enregistrés sur Google et Yahoo!, cela représente un point de pourcentage des phpinfo disponibles publiquement : ce n'est pas si mal.

Dans quelle mesure est-ce que cette population est représentative des pratiques communes d'administration? Il est certain que publier un phpinfo() dans un moteur de recherche, même par inadvertance, n'est pas une pratique courante, sans parler de l'aspect sécurité. Je vous recommande d'ailleurs de vérifier si un phpinfo ne traîne pas dans les moteurs de recherche : par exemple, sur Google, essayez : ‘phpinfo' site :votresite.com. Vous pourriez être surpris! Sachez que dans cette population, il n'y a aucune adresse issue d'un site populaire sur Internet. Un coup d'œil rapide sur la liste des noms de domaines obtenus n'a rien donné (bref, pas de phpinfo provenant de google.com, Yahoo, la NASA, la SNECMA, la SPA ou liberation.fr)

D'un autre côté, 11000 est une population qui est déjà raisonnable en taille. De plus, après prélèvement de la population, j'ai mesuré une corrélation de 87 % entre les versions représentées cette population, et l'indice de référence, qui sont les statistiques PHP mensuelles de nexen.net. Finalemnt, ce corpus est plutôt représentatif.

Au final, les statistiques que nous allons présenter sont certainement sérieuses et représentatives, mais peuvent être pas très précises. Toutefois, il y a des enseignements intéressants à tirer, et des chiffres intéressants.

Dernière note avant de passer aux camemberts : phpinfo présente énormément de valeurs, et il est possible de produire de nombreuses statistiques, et même de croiser les données entre elles. Je vais publier les statistiques en plusieurs articles. Si vous êtes intéressés par d'autres chiffres, n'hésitez pas à les indiquer dans les commentaires, ou à me les envoyer : je traiterai toutes les demandes sensées!

Notez aussi que je suis toujours à la recherche d'autres phpinfo(), alors si vous voulez me les faire parvenir sous forme de mail, d'URL ou de pièce jointe (l'HTML de phpinfo() est suffisant), je suis intéressé. Je les agrégerai simplement à la liste actuelle

Environnement technique

Système d'exploitation

Sans surprise, Linux est le système le plus indiqué dans les fichiers phpinfo(). Les autres systèmes sont : AIX, OpenBSD, OSF1, NetBSD, IRIX64, HP-UX, BSD/OS, Debian, NetWare, UnixWare, IRIX, VMS, SCO_SV, AmigaOS, QNX, BeOS.

Apache domine le marché très nettement, comme d'habitude. IIS n'apparaît pas directement, mais sous le vocable de ISAPI, CGI ou FastCGI. La part d'Apache 2 semble un peu surestimée par rapport à Apache 1.

La date de compilation est aussi un indicateur intéressant pour vérifier la validité des statistiques. L'immense majorité des serveurs ont été recompilés cette année, ou l'an dernier. Il semble donc que la communauté prenne un soin régulier de ses serveurs.

Une répartition par mois des dates de compilations confirme que les mois d'été août et septembre sont les mois préférés des administrateurs pour recompiler PHP. Cela coïncide d'ailleurs avec des gains records de PHP 5 cette année en août 2006. Les mêmes administrateurs doivent se reposer en octobre, avec les plus bas taux de compilation.

Directives célèbres

Plusieurs directives ont défrayé la chronique, étudions-les.

Register_globals

La recommandation officielle : désactivez-la! L'état de la situation : elle est encore activée sur plus de la moitié des configurations! Les explications seront sûrement nombreuses et diverses pour cet état de fait. En réalité, les comportements sont très différents en fonction des versions de PHP. Nous en reparlerons plus tard.

Autre directive qui fait parler d'elle : le safe_mode. Pour le coup, il est rarement utilisé. Nexen Services l'a abandonné depuis quelques années au profit d'open_basedir, et il semble que le mouvement soit généralisé chez les hébergeurs. Les serveurs dédiés s'en passent avec joie. La recommandation officielle est d'éviter le safe_mode.

Allow_url_fopen permet aux fonctions de fichiers (fopen, file, file_get_contents, etc.) d'accéder à des ressources distantes, tels des pages Web ou des fichiers sur FTP. C'est aussi un problème de sécurité, car elle ouvre la porte aux injections de code. Pourtant, 90 % des sites l'autorisent.

Les magic_quotes étaient une fonctionnalité de sécurité, mais sont maintenant marquées du sceau de l'infamie, et disparaîtront en PHP 6. Nombre de spécialistes basent encore leur sécurité SQL sur cette directive.

La version plus générale de magic_quotes, c'est à dire ‘runtime' qui affecte tous les flux passant par PHP, n'est jamais utilisée.

Max_execution_time est probablement la directive qui frappe en premier. Aucun serveur ou presque ne choisit de donner une valeur plus faible à cette directive, alors que l'immense majorité des scripts doivent livrer le résultat en une seconde ou moins. En fait, la tendance est même de donner une valeur très forte à cette directive, pour pouvoir exécuter les scripts d'administration, qui peuvent tourner longtemps avant d'aboutir.

Memory_limit est peut être la directive qui m'a le plus étonné. Avant de lire les résultats, je pensais que tout le monde l'utilisait. En fait, c'est une option de compilation, et il semble que de nombreuses architectures ne l'utilisent même pas!

La valeur par défaut est de 8 Mo, et elle semble très souvent insuffisante. Seuls 8 % des serveurs l'utilisent. Il est vrai que les besoins de mémoire pour les galeries sont souvent plus élevés que 8 Mo. D'après les statistiques, 32Mo seraient confortable. En PHP 5.2, la valeur par défaut de cette directive est 16 Mo.

Sécurité

Voici quelques choix de sécurité, faits au niveau de la configuration.

Open_basedir est la meilleure option de sécurité dans les directives PHP, mais elle semble souffrir d'un manque important de reconnaissance. Je n'ai pas détaillé les valeurs choisies, par manque d'intérêt pour l'exercice.

Disable_functions permet de désactiver des fonctionnalités spécifiques de PHP. Elle va de pair avec le safe_mode. En général, elle n'est pas populaire.

Display_errors est la directive qui fait afficher les erreurs dans les pages web, durant l'exécution. C'est très pratique en développement, mais c'est un faux pas en production. Désactivez-la en production!

enable_dl est la directive qui permet l'inclusion dynamique de fonctionnalités en PHP. En général, cette technique est pratique pour le développement, afin de ne pas relancer en permanence le serveur Web. Mais en production, il est recommandé de compiler les fonctionnalités nécessaires dans PHP, puis de désactiver cette option. Autrement, une injection de code et un upload de fichier seront suffisants pour pirater votre serveur!

Error_reporting règle le niveau de rapport d'erreur. Plus la valeur est haute, plus PHP signale des problèmes bénins. Traditionnellement, on recommandait de mettre error_reporting à 0 : je l'ai fait souvent. En réalité, il vaut mieux mettre error_displays à off, pour éviter TOUS les affichages, mais laisser une valeur raisonnable pour error_reporting afin d'avoir des indications sur le comportement de PHP en production. Des valeurs supérieures à 2000 (c'est le cas de E_ALL depuis longtemps) sont OK en développement, mais peuvent être difficiles à conserver en production sur un serveur à fort trafic.

Le log d'erreur enregistre les erreurs détectées par PHP dans un fichier de log. Ce processus peut être fait en plus de l'affichage au niveau du navigateur, et sert d'informations sur le comportement du serveur. Il est toujours intéressant de lire ces logs, après une catastrophe, ou bien simplement pour surveiller la santé d'une application.

Expose_php affiche la version de PHP dans les en-têtes du serveur Web. C'est une pratique qui n'est pas recommandée en termes de sécurité, afin de donner le moins d'indications possible à un pirate potentiel. D'un autre coté, cette information permet de produire les statistiques de PHP version, alors entre les deux, mon cœur balance. Merci à ceux qui le laissent accessible! 

Autres directives

File_upload active la possibilité de télécharger des fichiers sur PHP. Ces stats semblent indiquer que 99 % des sites manipulent des fichiers envoyés par les utilisateurs sur leur serveur. C'est impressionnant.

Une fois que les uploads de fichiers sont autorisés, il y a une autre valeur qui limite la taille des fichiers uploadés. Sa valeur est réglée par défaut à 2 Mo, ce qui est généralement valable pour les galeries d'images. Il est étonnant de trouver que 1,5 % des administrateurs autorisent des chargements de 100 Mo…

< ? au lieu de < ?php : il existe encore de nombreux projets et programmes qui dépendent de cette balise. Il est recommandé d'utiliser < ?php, mais cela ne coûte pas grand-chose de l'avoir activé sur son serveur.

Faire du PHP en utilisant des balises de type ASP : un choix pour 4 % des programmeurs.

La compatibilité an 2000? c'est bon pour 75 % des serveurs!

Le nombre de chiffres après la virgule dans les nombres décimaux, au moment de l'affichage.

Conclusion

Les choix de configuration de PHP se révèlent très conservateurs ou bien étonnants. En relisant les statistiques ci-dessus, on peut même se demander si certaines fonctionnalités avaient vraiment besoin d'une directive de configuration…

Comme toujours, les valeurs par défaut fournies par la distribution restent les valeurs les plus utilisées, ce qui montre la confiance que les administrateurs ont dans le groupe PHP : ou bien, en d'autres termes, rares sont ceux qui analysent les directives pour pour bien les comprendre et les adapter à leurs objectifs.

Les camemberts ci-dessus donnent un aperçu global de la communauté, mais ne soulignent par les tendances dans les choix qui sont faits. Pour cela, il faudrait éclater les données par version, et ce sera l'objet d'un futur article…