Rien n'est laissé au hasard
Ceux qui m'ont déjà lu ou entendu savent que je ne manque jamais une occasion de dire que "PHP est la pire régression pour la sécurité depuis 10 ans"(tm).
Or un incident de sécurité est récemment survenu sur une installation de SPIP dans un laboratoire du CNRS. Cet incident, fort bien analysé dans la newsletter "Sécurité de l'Information", pourrait en rester au stade de l'anecdote. Mais à y regarder de plus près, il s'agit d'un exemple flagrant qui vient habilement illustrer cette thèse.
Car le problème vient tout simplement du fait que SPIP gère l'intégralité de sa configuration et des données de session dans un fichier texte à plat, accessible depuis la racine du serveur Web. On peut supposer que ce choix a été contraint techniquement par le manque de fonctionnalités des premières versions de l'interpréteur PHP ... je n'ose croire qu'il puisse s'agir d'un choix conscient et délibéré de la part des développeurs.
Le fichier en question s'appelle meta_cache.txt. Il est normalement protégé par un .htaccess, qui pour plein de bonnes et de mauvaises raisons ne fait évidemment pas toujours son office, comme une rapide recherche Google permet de s'en rendre compte.
Ce fichier contient une variable nommée alea_ephemere qui s'avère essentielle pour la sécurité des opérations sur le site (les détails sont dans la newsletter susmentionnée).
Accessoirement, ce fichier contient également une variable au nom intriguant: secret_du_site.
Une rapide recherche documentaire permet d'approcher (sans toutefois le comprendre) le rôle de cette variable:
A la lecture de cette documentation, la première chose qui me vient en tête c'est cette merveille du 7ème art ...
PS. De source orale, SPIP émule également le mécanisme bien connu des register_globals afin de contourner les configurations PHP un peu trop sécurisées.
7 commentaires:
Très 2001. On dirai l'époque de phpsecure.info avec FrogM@n
Spip c'est aussi des gros enfoirés qui patchent sans jamais informer personne.
Ca quand meme l'air d'etre la faute de SPIP sur le coup ...
Le fichier de meta, je pense que meme avec une ancienne version on peut le mettre en dehors de la webapp.
Apres quand on voit qu'il émule le register_global, ainsi que d'autre détails, on comprend que SPIP est construit avec un soucis permanent d'insécurité
Ceci dit, PHP ca sucks on le sait....
tiens, un vieux blogpost de l'ami HD
http://www.breakingpointsystems.com/community/blog/php-safe-mode-considered-harmful
Qui n'a jamais rencontré cela ? :p
Ceci dis, je pense que PHP n'as pas grand chose à voir avec cela.
Mettre un fichier critique de cette sorte dans un dossier www-root, résulte de la débilitée profonde.
Ca n'est par contre pas PHP le coupable de cette bévue monumentale.
Sinon cela reviendrais à dire en gros :
ASP.NET est à chier, parce-que tel tiers-cms, fait un backup de base de donnée dans le www-root folder.
Quand ont met en place un site web basé sur un CMS, ont s'assure généralement qu'il ne représente pas de risque de sécurité, et ont se doit de renforcer la sécurité.
De plus concernant les .htaccess, il est vrai que sur certains hebergeurs mutualisé certaines directives sont désactivées pour des questions de sécurité, et c'est normal, celà reviens donc au developpeurs du dît cms de corriger le tir soit en modifiant le cms, soit en notifiant clairement à l'utilisateur les risques encourus à faire fonctionner le cms dans un environnement ne correspondant pas au prérequis du cms.
Aussi, la différence entre un site amateur et un site professionel prend forme comme suit;
Mettre un site professionel sur un hébergeur mutualisé représente à la base un grave risque de sécurité, en ASP,JSP,PHP,etc étant donné que l'ont possède aucun contrôle sur l'environnement de celui-ci.
Modifier sont cms pour faire fonctionner/émuler registers_globals prouve aussi l'anciennetée flagrante de ce programme, et donc ne convient plus au besoin de 2009 (le fichier en question disponible prouve aussi ce point)
@anonyme: ça explique mais ça n'excuse pas :)
Le problème c'est que PHP autorise, voire incite à utiliser ces constructions intrinsèquement non sécurisées.
Et les exemples de code dupliqués à l'infini par des développeurs inexpérimentés sont généralement bogués.
Le problème c'est pas que le fichier soit dans www... le vrai problème c'est que les abrutis qui ont conçus spip ont nommés le fichier .txt.
C'était pas possible de mettre un .php ?
C'est comme tous ceux qui nomment leur includes "config.inc" ou autres extensions qui ne sont par défaut pas interprétées en PHP.
Un des gros problèmes de PHP, c'est sa base d'utilisateurs du dimanche, qui ne savent même pas vraiment ce qu'ils font.
Enregistrer un commentaire