les dangers de l'include PHP, pour un débutant

[Grognon]

Dans un système UNIX, chaque répertoire contient deux répertoires "virtuels" (des liens en quelque sorte) :
. qui pointe vers lui même
.. qui pointe vers son répertoire père
Donc en utilisant .., tu peux remonter aussi loin que voulu !
Exemple : include("../../rep2/monFichier.php");

Vi, ça j'ai compris
Sauf que le monfichier.php fait lui aussi appel à d'autres fichiers (forum phpbb pour le coup) et que je peine à mettre le bon phphbb_path. Du coup, j'ai tout mis en http pour pouvoir avancer quand même

Bref, au final ça sera bien comme il faut (avec des chemins relatifs)

Ma question (pas claire, je vous l'accorde) était de chercher à comprendre la différence entre variable et valeur fixe (et on ne rigole pas ). monfichier.php c'est bien une valeur fixe ?

[schlum]

D'ailleurs, je dis des bêtises ! À mon avis ça ne fonctionnera pas en mettant "http://www..." ; le serveur va probablement interpréter le PHP et sortir du HTML aussi.
Il faut donner soit le chemin relatif, soit le chemin complet mais dans la hiérarchie de fichiers du serveur lui même (et pas de la racine d'Apache).

[marc_os]

[...]
le serveur va probablement interpréter le PHP et sortir du HTML aussi.
[...]

Je dirais même plus: le serveur va de toute façon interpréter le PHP et sortir du HTML aussi ... si le code inclus contient du code HTML hors tags <?php ?> et/ou des echo dans le code php.
Si le code inclus ne contient que des définitions de fonctions, rien ne "sortira". D'ailleurs, dans ce cas là il vaut mieux utiliser un require_once.

cf. la doc :

La fonction include() inclut et exécute le fichier spécifié en argument.

[Master Buck]

En gros ce que tout le monde dit de façon assez floue, c'est :

-inclure une variable, c'est dangereux.
-inclure un lien absolu, c'est inclure du HTML, donc pas possibilité d'utiliser le code qui vient de la page inclue.
-inclure un chemin relatif (ou FTP), c'est bien, pratique, et sécurisé.

[marc_os]

En gros ce que tout le monde dit de façon assez floue, c'est :

-inclure une variable, c'est dangereux.
-inclure un lien absolu, c'est inclure du HTML, donc pas possibilité d'utiliser le code qui vient de la page inclue.
-inclure un chemin relatif (ou FTP), c'est bien, pratique, et sécurisé.

Non:
Ce qui est dangereux, c'est : include($page); où $page n'est pas défini explicitement dans le code qui précède, mais dont la valeur est définie par un choix de l'internaute qui peut alors faire inclure n'importe quoi.
De manière plus générale, ce qui est dangereux c'est d'inclure un fichier dont on n'est pas sûr. Via un include($page), ou via un include vers un fichier sur un serveur "étranger", càd dont on ne maîtrise pas le contenu.
Utiliser des chemins relatifs ou absolus, ce n'est pas le danger en soi. On peut très bien se retrouver dans une situation "dangereuse", avec des chemins relatifs, si on pointe sur un fichier dans un dossier publique où n'importe qui peut mettre n'importe quoi !

Enfin, comme je l'ai rappelé plus haut, dans tous les cas le code du fichier inclus est "exécuté".
S'il s'agit de code HTML, celui-ci sera affiché.
S'il s'agit de code php, les définitions de fonctions seront parsées et ces fonctions seront disponibles au code php qui suit l'include, et tout code "au premier plan" sera exécuté, et les echo et autres print provoqueront un affichage dans le navigateur du client.

Ce message a été modifié par marc_os - 6 Dec 2006, 14:06.

[Grognon]

J'ai finalement opté pour require_once en chemin relatif

Merci pour ces précieux renseignements

[hubeert]

que tu utilises require_once ou include_once ne vas pas changer grand chose au niveau sécurité si cest ce que tu recherches ; il faut simplement verifier que ce que tu inclus ou requiers sois reellement ce que tu veux inclure ou que tu requieres.. chemin absolu ou chemin ou chemin relatif ne change rien pour la personne qui tape dans le navigateur (meme si cest au hasard) la bonne adresse telle que le decrit Schlum..faut juste verifier que ce soit ce que toi tu veux inclure qui est inclu..sinon est bien tu reviens a la page index par exemple . rien de plus pour l'include. le reste de la sécurité web releve quand meme bien souvent que du bon sens.

Enfin, comme je l'ai rappelé plus haut, dans tous les cas le code du fichier inclus est "exécuté".

justement faut pas qu'il soit inclu

c'est donc ce qu'il faut faire.. et pour ce faire pas bcp de solution.. autre que verifier que ce c'est le bon include qui arrive tout autre est rejeté..


et mefiez vous des fichiers .bak.. que certain editeurs rajoutent pour sauvegarder..

en tout etat de cause en cas d'attaque serieuse la meilleures solution est encore d'avoir des sauvegardes a jours..

eviter l'inclusion de fichiers de programme distant..

et eviter les injection SQL..

bref c'est tout un binzzzz

bref tout un programme..

[Grognon]

que tu utilises require_once ou include_once ne vas pas changer grand chose au niveau sécurité si cest ce que tu recherches ; il faut simplement verifier que ce que tu inclus ou requiers sois reellement ce que tu veux inclure ou que tu requieres.. chemin absolu ou chemin ou chemin relatif ne change rien pour la personne qui tape dans le navigateur (meme si cest au hasard) la bonne adresse telle que le decrit Schlum..faut juste verifier que ce soit ce que toi tu veux inclure qui est inclu..sinon est bien tu reviens a la page index par exemple . rien de plus pour l'include. le reste de la sécurité web releve quand meme bien souvent que du bon sens.

Oula, pour ma part, je me contente déjà que ça fonctionne ; la sécurité vient loin derrière
J'ai juste remarqué que quand c'était include, ça ne fonctionnait pas et que quand c'était require ça fonctionnait

[marc_os]

Oula, pour ma part, je me contente déjà que ça fonctionne ; la sécurité vient loin derrière

Mais si tu as le temps, ça vaut le coup d'en profiter pour chercher à comprendre les subtilités du langage ! Un jour tu seras bien content d'avoir profité utilement du moment où tu avais le temps. Et même s'il y a la pression quand on doit livrer, cinq minutes de "perdues" à comprendre à un moment donné peuvent faire gagner des heures de débogage vraiment perdues par la suite !

J'ai juste remarqué que quand c'était include, ça ne fonctionnait pas et que quand c'était require ça fonctionnait

Encore et toujours, lire la documentation!

require() et include() sont identiques, sauf dans leur façon de gérer les erreurs. include() produit une Alerte (warning) tandis que require() génère une erreur fatale.

A noter aussi: les deux fonctions existent en deux variantes: la "normale", include() ou require() et la version "_once" : include_once() ou require_once(). Ces dernières assurent qu'un fichier inclus n'est inclus qu'une seule fois.

Le fait de remplacer include par require pour que ça marche est étonnant, car require est plus restrictif que include ! A mon avis, tu n'as probablement pas fait que cette modification entre le moment "ça ne marche pas" et celui où "ça marche". Par exemple, tu as peut-être utilisé la version "_once" et évité ainsi une double inclusion ?

Ce message a été modifié par marc_os - 7 Dec 2006, 11:40.

[Grognon]

Plus qu'une question de temps (même si j'en manque), il s'agit plus d'une question de capacité
Je ne suis pas programmeur, je n'ai pas la logique d'un programmeur et mes capacités se résument à modifier des scripts existants (ou assembler des bouts de scripts) à force de tâtonnements. J'essaye bien entendu de comprendre ce que je fais mais ce n'est pas toujours le cas et la documentation ne m'y aide pas toujours

J'en arrive donc parfoids à un point que je ne me souviens plus de toutes les modifications et tests effectués et, ainsi, de ne pas savoir exactement quelles modifications ont fait que cela fonctionne correctement

Désolé d'avoir fait dériver ce sujet

[Hyp]

Ce message a été modifié par Hyp - 12 May 2010, 11:53.

[schlum]

Non, ça ne fonctionne pas si le serveur est correctement sécurisé...

-->

HTML

<img src="photos/<?=$_GET['photo']?>.jpg" alt="Photo" />

[Hyp]

Merci

[Hyp]

Ce message a été modifié par Hyp - 12 May 2010, 11:53.

[Vin's]

Est-ce que j'ai d'autres choses à vérifier ?

Si tu utilises une base de données, il faut faire attention à l'injection SQL...
Genre si tu as une requête SQL comme :

CODE

$sql = "SELECT * FROM une_table WHERE message_num=$msg_num"

$msg_num est censé être un nombre. Si un attaquant met un truc genre '1; [Requete SQL dangereuse]' dans $msg_num, il pourra exécuter [Requete SQL dangereuse] sur le serveur.
Pour éviter ça, quand tu récupères $msg_num, il ne faut pas faire :

CODE

$msg_id = $_GET['id'];

mais

CODE

$msg_id = (int)$_GET['id'];

Ainsi, si $_GET['id'] n'est pas un nombre, $msg_id contiendra 0. Le méchant hacker ne pourra pas exécuter sa requête SQL.
Lorsqu'on utilise des chaînes de caractères dans les requêtes SQL, on les met entre apostrophes simples :

CODE

$sql = "INSERT INTO une_autre_table VALUES ('$une_chaine')"

Il faut dans ce cas remplacer les apostrophes ' de $une_chaine par \' pour qu'elles ne soit pas interprétées comme la fin de la valeur à insérer. (par exemple si $une_chaine contient "blabla'); DELETE FROM une_autre table; --" la requête SQL sera "INSERT INTO une_autre_table VALUES ('blabla'); DELETE FROM une_autre table; --);" -- Mauvais !)

On peut éviter ce problème en utilisant la fonction $str = addslashes($str), mais je crois que htmlentities() le fait si on lui donne ENT_QUOTES en second paramètre (voir la documentation sur le site de PHP)
Un bon test est d'essayer de mettre autre chose qu'un nombre dans les variables envoyées par le navigateur qui devraient être un nombre, et des apostrophes dans les variables qui devraient être des chaines...

Ce message a été modifié par Vin's - 10 Jun 2007, 10:39.

[hubeert]

coucou;

que veux tu dire par "mes include se font de maniere statique"?

[Master Buck]

Qu'il ne passe pas de paramètres qui viennent de GET ou POST, je suppose.
Sinon pour les problèmes ave les SQL queries, j'utilises intval() en gros, ça prend la valeur numérique de ce que tu mets.

Et je note que j'utilises toujours addslashes() et jamais htmlentities(), je me demande si ça peut me poser des problèmes...

[canari]

au lieu de addslashes, il est préférable d'utiliser mysql_real_escape_string.
et utiliser htmlentities permet d'éviter la faille xss (sinon, du code javascript peut être exécuté lors de l'affichage de données venant de bdd (ou saisies), par ex: "<script>alert(1)</script>").

Ce message a été modifié par canari - 10 Jun 2007, 15:06.

[Hyp]

Ce message a été modifié par Hyp - 12 May 2010, 11:53.

[Master Buck]

Ça existe, ça, des gens qui n'utilisent pas MySQL ?! Oo

[Hyp]

Ce message a été modifié par Hyp - 12 May 2010, 11:53.

[Hyp]

Ce message a été modifié par Hyp - 12 May 2010, 11:54.

[schlum]

Ca dépend comment tu gères ton système de fichiers...
MySQL apporte directement les optimisations classiques de bases de données comme le tri des clés par hash avec recherche rapide derrière, des jointures optimisées entre les tables etc.
Mais tu peux avoir un système aussi performant avec des fichiers, et moins lourd (pas de passage par la relation client / serveur).
Tout dépend de la complexité que prend la chose...

[Hyp]

Ce message a été modifié par Hyp - 12 May 2010, 11:54.

[sky]

MySQL permet de ne pas avoir de soucis en cas d'acces simultanné au fichier. En cas de bug, MySQL preserve en general les donnees, un fichier ouvert non fermé peut se retrouvé planté ( donnée perdu etc ... ).
Cela permet de faire des tris, des recherches, de faire des jointures de donnees, etc... plus facilement.

Et puis au final, c'est bien plus simple d'ouvrir une connection a une DB que d'ouvrir et lire un fichier. ( pour peu que MySQL soit déjà installé )

Perso, j'utilise beaucoup mysql ( en ligne de commande ou avec Navicat ) parce que j'ai souvent de tres longues listes de donnees, mais quand il y a un gros fichier (contenu HTML, image, etc... ) a enregistrer, il reste sous form de fichier, les disques des serveurs sont bien assez rapides et la quantité de mémoire ( et donc de cache ) permet d'avoir des performances equivalentes a une recuperation dans la db.

[edit]

pour produire des scripts les plus légers possibles

C'est une idee recu que plus un script est leger plus il est rapide. En general, c'est faux, il vaut mieux ajouter du code "utile" quitte a doubler ou tripler la longueur du code plutot que de complexifier avec des boucles, conditions inutiles, etc...

Par exemple, j'affiche un menu dont l'élément selectionné possede un affichage different, basiquement on ferait :

CODE

for ( $mesmenus as $index=>$monmenu ) {

if ( $index == $menuselectionne ) {
/ * affichage selectionné */
} else {
  /* affichage non selectionné */
}
}

alors qu'en faisant :

CODE

for ( $i=0; $i<$menuselectionne; $i++ ) {
/ * affichage non selectionné */
}

/* affichage selectionné */

for ( $i=$menuselectionne+1; $i<count($mesmenus); $i++ ) {
/ * affichage non selectionné */
}

On ne fait pas le test a chaque boucle pour savoir si le menu est le bon et l'on parcour le meme nombre d'object dans la boucle. Theoriquement, le second, bien que 2 fois plus long est mieux optimisé. L'exemple n'est pas forcement le plus parlant mais l'idee est la.


[/edit]

Ce message a été modifié par sky - 13 Jul 2007, 15:48.

[schlum]

Non non, faire une connexion à une base de donnée paraît peut-être plus simple qu'ouvrir un fichier, mais c'est plus lourd

[sky]

Non non, faire une connexion à une base de donnée paraît peut-être plus simple qu'ouvrir un fichier, mais c'est plus lourd

Je parlais vraiment du point de vu "code" Ouvrir une db, recuperer qq valeur sont plus facile a implementer que l'ouverture et le parse de 1 ou plusieurs fichiers.

Faire une connection a une db est plus lourd qu'ouvrir 1 fichier, mais qu'en ouvrir 5 ? 10 ? 15 ? + ?
Tout depends de l'utilisation qu'on en fait

Ce message a été modifié par sky - 13 Jul 2007, 17:40.

[Hyp]

Ce message a été modifié par Hyp - 12 May 2010, 11:54.

[sky]

A mon avis, la diff en perf doit etre negligeable. Et ce n'est pas pour une optique "pro".

De toute facon, la meilleur maniere de faire un programme, c'est celle qui marche

A propos des includes ( plus haut dans le topic ), il y a une solution qui semble simple et sans trop de problème de securité, c'est l'utilisation de la fonction glob() dans un dossier regroupant tout les fichiers a inclure.

CODE

$files = glob( MON_PATH.'/includes/*.php.inc' );
foreach ( $files as $file )
  include_once ( $file );

Ce message a été modifié par sky - 13 Jul 2007, 18:45.