SVN et PHP : attention !

PHP

Le site GForceSoftware nouveau est arrivé.

Il est hébergé sur le serveur d’Ohm Force dont j’ai la charge ; c’était une expérience intéressante, car je devait mixer une application à base de Servlets avec une application PHP, derrière le même domaine.

En frontal, il y a nginx, le serveur http russe léger et qui fonce.

Pendant 24 heures, il y avait un trou de sécurité flagrant, qui permettait de récupérer le code source des scripts php, à cause de svn. (je me suis tapé sur la tête quand je m’en suis rendu compte. Heureusement en analysant les logs, personne n’a eu l’idée de l’exploiter).

SVN

Le déploiement sur la production, c’est un checkout des scripts. C’est à dire que tous les répertoires ont un répertoire .svn qui contient les métadonnées sur les fichiers du répertoires ainsi qu’un cache contenant les fichiers originaux tels qu’ils sont stockés sur le repository svn.

Les fichiers originaux sont identifiés par une extension svn-base.

La faille

Or la configuration du serveur est d’envoyer le contenu tel quel pour une extension inconnue.

Du coup, on pouvait récupérer le code de la page d’index avec ce lien :

http://www.gforcesoftware.com/.svn/text-base/index.php.svn-base

Pas glop.

La correction

Donc pensez bien à ajouter la configuration suivante dans votre serveur web (ici pour nginx) :


location ~ .svn/ {
        deny all;
    }

La conclusion

C’est un des trucs qui me plaît le moins avec PHP, le fait que l’arborescence détermine l’URL, je préfère un MVC un peu plus abstrait comme avec les servlets ou avec Rails. On a beaucoup plus de souplesse, sans s’encombrer de rewrite rules trop complexes.

Vu que pour le MVC, toutes les URLs sont masqués derrière le contrôleur l’utilisateur ne sait même pas quel est l’arborescence système.

Sur le site Ohm Force, les JSP elles-même sont cachés dans le répertoire WEB-INF dont le contenu n’est pas publié.

3 comments so far

  1. Cédric on

    Bonjour,

    il est fortement déconseillé de faire un checkout sur un serveur de production. Un export évite d’avoir les dossiers de travail .svn.

    Sinon PHP permet parfaitement d’avoir une arborescence abstraire, comme je l’ai utilisé ici
    http://placedusport2.com/nimes2007/photo.php/FR/12/2980/podiums-adultes

    Et une seule règle de rewriting m’aurait permis de retirer le photo.php mais je n’en ai pas eu le temps à l’époque. L’avantage de rails et consorts est qu’ils le font par défaut, sans qu’on ait à se poser la question.

    Cordialement
    Cédric

  2. cstar on

    C’est vrai … mais j’aime beaucoup svn switch sur des tags pour le passage en production, on gagne du temps sur les transferts🙂

  3. Kneko on

    Par rapport à la conclusion : pour faire du MVC en PHP il y a plusieurs frameworks prévus juste pour combler cette lacune.

    Personnellement je recommande Code Igniter qui a le mérite de s’apprendre en moins d’une matinée (par rapport à CakePHP et ses amis…) et d’être léger!

    En regardant les deux vidéos du site puis en survolant la doc (pour ceux qui aiment lire) n’importe quel programmeur PHP digne de ce nom peut immédiatement faire du MVC sans s’arracher les cheveux😉

    Et si on ajoute jQuery pour le javascript on obtient une combinaison parfaitement “Web 2.0-compliant” pour coder des sites “next-gen” en vraiment peu de temps!


Comments are closed.

%d bloggers like this: