Sécurité des TPL

[speedev]

Bonjour,

J'utilise Smarty et je souhaiterais pouvoir empêcher un visiteur quelconque sur mes sites d'accéder directement à mes templates smarty depuis son navigateur sans passer par ma page principale (index.php).

Je pensais à faire ceci :
- Renommer tous mes tpl avec l'extension .tpl.php
- Encadrer le code du template entre deux lignes PHP à savoir :

Code :

1
2
3
<?php if ($right_of_open) { ?>
[ Le code du template ]
<?php } else { echo "Vous n'êtes pas autorisé à consulter cette page"; ?>

La page index principale disposant de

Code :

$right_of_open = true;

C'est opérationnel biensur mais avez-vous une solution plus pratique (plus propre) svp ?

merci

[Raideman]

Bien en fait, et je suis désolé si ça ne répond pas à ta question, je ne comprends pas l'intérêt d'empecher la visualisation d'un template. Après tout, le but du template est d'etre affiché non ? Donc de toutes façons on peut afficher le source de la page et deviner assez simplement la structure du template je pense.

De plus, je ne pense pas que les données incluses dans le template soient sources de failles de sécurité.

M'enfin, peut etre as tu des besoins vraiment spécifiques sur ce point là.

[speedev]

Oui mais il s'agit d'un site avec authentification d'utilisateur donc on dipose de tags SMARTY spécifiques dans les templates, par exemple :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
{if $login!=0}
<div id="left">
	<div class="menu_left">
		<div class="logo spacer">
			Données spécifiques pour login
		</div>
	</div>
</div>
{else}
<div id="left">
	<div class="menu_left">
		<div class="logo spacer">
			Données pour tout le monde
		</div>
	</div>
</div>
{/if}

Si tu appelles ce template tu verras les tags smarty directement dans la page (!!!) car les libs smarty ne sont pas appelées.

Peut-être y a t-il quelque chose de prévu avec smarty pour cela ?

[speedev]

Franchement je trouve cela très surprenant. Il doit bien exister une méthode pour masquer ce code. Même s'il n'avance pas beaucoup un éventuel petit malin à faire des bêtises c'est quand même une "mise à nu" d'un code censé être lu par le serveur (PHP).

Ou alors j'ai zappé quelque chose...

[Raideman]

Ben comme je le disais, je ne vois pas en quoi voir les tags smarty pourraient constituer une faille ...

[speedev]

non mais faut admettre qu'il s'agit de code de traitement (comme PHP) et qu'il n'est pas censé être vu par le client...

[Raideman]

Oui, c'est possible, c'est d'ailleurs l'une des raisons qui me chagrinent un peu dans ces systèmes de template, c'est qu'on déplace des traitements (meme si ils sont consacrés à de l'affichage) dans des templates . (mais bon évidemment, c'est un choix, soit on déplace de l'affichage dans le php, soit on déplace du traitement dans le template).

[speedev]

Je cherche une astuce

[SlymDesign]

salut,

Je me pose actuellement la même question que toi.

Ce que je pensais faire, c'est modifier la classe Smarty pour qu'elle reconnaisse les balises php natives (<?php et ?>) plutôt que les balises smarty {php} {/php}.

J'ai pas encore essayer mais je crois avoir repérer une RegExp dans la classe Smarty qui s'occupe de ça.

En plus le deuxième avantage, et pas des moindres, c'est que si ça marche, dreamweaver reconnaitra enfin la syntaxe PHP puisqu'il y aura les vrais balises php dans les templates.

[speedev]

Je pense qu'il faut mieux adopter la méthode couramment utilisée à savoir isoler les TPL (et autres données éventuelles) à l'extérieur du répertoire WEB afin qu'elles ne soient pas accessibles depuis un navigateurs WEB. J'ai employé cette méthode, c'est radicale et hautement sécurisé.
Petite contrainte : il faut s'habituer à la nouvelle arborescence des dossiers et fichiers séparés entre deux dossiers principaux (online et offline) et être un poil plus rigoureux dans son organisation, mais c'est tout benef'....

[SlymDesign]

Et un simple .htaccess ne ferait pas l'affaire ?

[speedev]

C'est jouable avec un htaccess mais moins intéressant à mon goût.
Je préfère la solution d'externaliser les fichiers "protégés" à l'extérieur de la racine web.

[Raideman]

D'autant que le htaccess va te demander des codes à chaque fois que tu vas utiliser un template pour l'afficher

Maintenant comme tu le suggères, tu peux placer tes templates dans un répertoire non accéssible via le web.

[SlymDesign]

euh ... non ... Il est possible de bloquer tous les accés distants à un répertoire sans pour autant avoir besoin d'une authentification en local.

Je ne vois pas comment on fait pour faire un répertoire hors web sur serveur mutualisé. Est-ce que c'est possible au moins ?

[speedev]

Hello, je reviens sur ce post.

Je n'ai pas abandonné la pratique du répertoire "offline" et je l'ai même déployée partout...

Mais attention, utiliser un répertoire "offline" hors du document_root présente des subtilités et contraintes.

Pour ma part j'utilise un fichier unique de configuration de l'application ou du site web (un INI que je parse). Au même niveau que ce fichier de conf se trouvent mes deux répertoires principaux :
- httpdocs/ par exemple
- httpdocs-offline/ pour le répertoire offline par exemple.
(Qlqun de ce forum m'avait déjà conseillé cette pratique...)

Aujourd'hui :
- 90% de mes fichiers sont dans httpdocs-offline/ (les fichiers php, les templates, les modules, les classes...) et sont donc inaccessibles depuis un navigateurs Web.
- 10% dans httpdocs/ (images/, css/... et biensur le index.php) contenu accessible depuis le navigateur Web

J'ai encore des incertitudes avec la méthode mais j'apprécie beaucoup son utilisation car je m'y suis bien accoutumé et qu'elle m'offre une grande souplesse de configuration et de sécurisation des traitements.

Ennui rencontré pour le moment :
- J'utilise des chemins systèmes pour accéder au répertoire offline par exemple : /var/www/monsite.com/httpdocs-offline/ (biensur les chemins sont stockés dans des constantes...), et donc je dépend de la configuration de la machine. A noter qu'il y a moyen d'utiliser $_SERVER['DOCUMENT_ROOT'] pour trouver le répertoire "offline" en remontant d'un niveau dans l'arborescence mais je n'ai pas encore modifier ma conf.
- Plesk ! Cette chouette interface est figée et ne permet pas de modifier les droits sur les dossiers d'un vhost, par conséquent on ne peut créer le répertoire "offline" que par l'intermédiaire du compte root (une manip à faire en plus...légère et non récurrente vous me direz...) pour qu'il soit utilisable par l'utilisateur FTP (pour y déposer des fichiers). L'utilisateur FTP n'a de droit que sur le répertoire web httpdocs/... Dommage...

Si vous avez des réflexions...je reste à l'écoute.

a+

[speedev]

http://www.developpez.net/forums/sho...d.php?t=245238

J'ai retrouvé le conseil de Yogui
La méthode est effectivement celle utilisée dans les architectures MVC (modèles vue controller)...

[arnogb69]

Salut speedev,

Tout d'abord merci pour mettre à jour cette discussion...
Simplement, je ne comprend pas quel est le problème de sécurité lorsque l'on affiche les balise smarty dans le template.

De plus, par rapport à ton arborescence, commet par exemple afficher une page par exemple contact.tpl si seul ton index n'est accessible depuis le navigateur web?

[speedev]

Rectification ce n'est tant une histoire de sécurité mais de "garantie" plutôt.
Disons même du perfectionnisme.

Je me sens plus à l'aise avec un minimum de données dans le document_root càd JUSTE le nécessaire (image, css etc....). "boaf si c'est pour éviter la piraterie, faut pas oublier qu'un pirate peut passer par d'autres portes", c'est vrai mais encore une fois je préfère isoler un maximum de fichiers.

Pour ta deuxième question :
Avec un sniffer il est facile de récupérer l'arborescence d'un site Web. Une fois l'arbo trouvée, on cherche un peu et on trouve les TPL. On teste les urls comme par exemple :

http://www.le-site.com/templates/accueil.tpl

Et on découvre les balises smarty qui pourraient être, à titre de mauvais exemple :

Code :

1
2
3
4
5
6
7
 
{if $login}
    Bienvenue {$login}, tu as {$age} ans.
    N'oublie pas de te connecter sur http://www.top-secret.com/truc.php?clef=ldskfs4s1dfdsf pour récupérer les données
{else}
    Bienvenue, inscrivez-vous !
{/if}

Ce serait vraiment le cas d'un mauvais développement oui...le sniffeur découvre l'URL... mais ça résume un peu ce que je veux dire.

Smarty c'est du PHP (avec des "if" des "else" des "foreach" etc...), en tout cas un langage "capable" de faire du traitement (c'est traduit par du php...), il ne faut donc pas, à mon goût, qu'il soit "visible" depuis un navigateur à moins d'avoir la garantie que le développement n'engendre aucune faille ni aucune divulgation de donnée. Donc que l'on respecte bien la séparation de la couche traitement et de la couche présentation.

a+

[arnogb69]

Ah oui, en effet, j'ai bien compris le problème que pourrais susciter l'affichage du .tpl, une solution serait de passer en paramètre par Smarty toutes les données susceptibles d'être importantes, mais le problème n'est pas là... et surtout en effet la logique du code reste visible

Pour ma première question, je ne comprend toujours pas pourquoi tu n'as qu'un fichier php accessible; comment accéder aux autres fichiers php s'ils ne sont pas visibles (une chose m'échappe, cela doit être simple, mais mieux vaut poser des questions plutot que d'avoir de mauvaises surprises)

[speedev]

Ma pratique est assez simple :

J'ai développé une classe extends de Smarty qui gère entièrement mes fichiers (php et tpl). Disons même que je dépends d'un objet PHP.

Dans mon document_root je n'ai donc qu'un seul fichier "index.php" et dans ce dernier il y a très peu de code et ce n'est que de la configuration puis de l'instanciation de classes diverses (dont l'objet smarty).

Tout le site utilise l'Url Rewriting et chaque lien pointant vers une page HTML se caractérise donc par une réécriture, exemple simple :
accueil.html = index.php?page=accueil

Dans index.php, je récupère les variables de pages ensuite j'appelle mon objet smarty qui va s'occuper des traitements associés aux pages demandées :
- Recherche la présence d'un éventuel fichier de traitement PHP qui s'appèlerait accueil.php (dedans se trouvera tous les traitements relatifs à la page accueil), si il en existe un, l'objet effectue un simple require du fichier PHP (il remonte donc dans l'arborescence jusqu'en dehors du document_root). J'utilise des constantes pour ça...
- Puis , recherche de la présence d'un TPL, s'il existe, tu connais la suite, l'objet effectue un smarty->display de accueil.tpl

Je t'ai sommairisé la chose, mes traitements sont plus nombreux et optimisés.
Pour l'instant je n'ai rencontré aucun problème (vive la POO !), je touche du bois.