Une question bête mais pas méchante, dans la lignée de ce qu'avait tenté
d'introduire sieur Gallet -john de son prénom-(c'est à dire une sorte de
théma mensuelle), à savoir quelle extension pour certains fichiers, relatifs
à la sécurité.
Concernant le connect.php, ou .inc, ou inc.php, ou trucmuche d'ailleurs...
Concernant d'autres fichiers pouvant relever de cette extension (fic
d'initialisation de variables par exemple...)
Alors, qd est-i de la sécurisation de ces dits-fichiers, l et que devrait-on
choisir comment nom d'extension ?
Merci de vos réponses,
xpatval
--
xpatval@(oo)wanadoo.fr [Oter le (oo) dans l'adresse]
-----
http://24lemans.free.fr
-----
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
John Gallet
Bonjour,
Une question bête mais pas méchante, dans la lignée de ce qu'avait tenté d'introduire sieur Gallet -john de son prénom-(c'est à dire une sorte de théma mensuelle), à savoir quelle extension pour certains fichiers, relatifs à la sécurité.
Louable intention, même si pour ce sujet là on ne va pas débattre longtemps, pour une fois ce sont des choses assez simples.
Alors, qd est-i de la sécurisation de ces dits-fichiers, l et que devrait-on choisir comment nom d'extension ?
Règle 1 : le contenu de tout fichier non parsé par php et contenant du code php sera renvoyé tel quel au navigateur. Donc tout code php qu'il contient sera lisible en clair. Donc selon la sensibilité du code en question, cela introduit une faille ou non. Si le contenu est constitué de déclaration de mots de passe ou de chemins sur disque, c'est plus sensible que <?php echo $row['coincoin'];?> dont on peut seulement déduire que probablement tu as une colonne d'une table qui s'appelle coincoin (et encore, car SELECT colonne1 AS coincoin est possible).
Règle 2 : ça dépend de la configuration du serveur http. Si le serveur en question parse les .toto avec php, tu peux mettre tout le code que tu veux dans les .toto : il est toujours amusant de voir l'augmentation dans les logs des attaques recherchant cmd.exe ou trucmuche.dll suite à renommage des .php en .asp sur une machine unix ;-)
Règle 3 : ça dépend d'où c'est situé sur le disque par rapport aux autorisations d'accès. Si tu mets dans ./local_seulement/ les fichiers toto.txt et .htacess avec <DENY FROM ALL> dedans, sur le papier, tu es aussi (in)secure avec toto.txt que toto.php
Règle 4 : il faut systématiquement séparer le code qui définit du code qui exécute. La vraie faille se situe surtout dans l'appel en direct d'un fichier qui exécute réellement le code alors que le développeur ne le voulait surtout pas. Ceci est particulièrement vrai dans le cas d'abus de header:location. Exemple typique du code gruyère rencontré N fois :
if(..... série de tests de cohérence)... header("Location:faire_enregistrement.php"); else header("Location:erreur.php");
Et là manque de bol, moi j'appelle en boucle faire_enregistrement.php et tous les tests de cohérence passent à la trappe. Alors que si j'avais remplacé ce code à la noix par : if(.....tests inversés...) { require("erreur.php"); exit(); } define('CHECK_DONE',1); require('faire_enregistrement.php');
ET que dans faire_enregistrement.php tu commences par : if(!defined('CHECK_DONE') exit();
OU (à la limite) que tu renommes faire_enregistrement.php en faire_enregistrement.txt (cas dans lequel il ne peut être exécuté que par require()/inclde() local)
OU que tu mets faire_enregistrement.php dans un répertoire avec un .htacess DENY FROM ALL
alors tu es blindé.
C'est très bien d'implémenter MVC (ou en tous cas, de tenter de s'en rapprocher) mais il ne faut ni faire 36 allers-retours inutiles entre le client et le serveur (je rappelle : header location = ping-pong) ni donner un moyen de court-circuiter les tests de cohérence de l'application.
Une fois de plus, le seul principe à se souvenir est simple : il est impossible d'empêcher quiconque d'appeler nos scripts "publics" avec les paramètres qu'il voudra, le nombre de fois à la seconde qu'il voudra, dans le "mode" (GET ou POST) qu'il voudra. Cf wget par exemple.
Enfin concernant le nom "inc", c'est une convention de nommage comme une autre, que personnellement je n'applique pas, mais c'est un autre soucis. Chez moi, les librairies (allez faisons snob : le framework !) sont en lib_NOMDUMODULE.php, les "templates du pauvre" ((C) JG 2002) en print_NOM_ECRAN.php et j'en passe et des meilleures. Mais là dessus, chacun son truc, du moment que lesdites règles sont claires.
A noter que la sécurité d'accès devrait elle aussi être indépendante du serveur http utilisé. le .htaccess n'est PAS une solution portable et devrait donc être évitée dans des développements à grande diffusion (open source par exemple).
HTH JG
PS : pour quelqu'un qui commençait par dire que le sujet était vite torché, j'en ai encore pondu une tartine moi...
Bonjour,
Une question bête mais pas méchante, dans la lignée de ce qu'avait tenté
d'introduire sieur Gallet -john de son prénom-(c'est à dire une sorte de
théma mensuelle), à savoir quelle extension pour certains fichiers, relatifs
à la sécurité.
Louable intention, même si pour ce sujet là on ne va pas débattre
longtemps, pour une fois ce sont des choses assez simples.
Alors, qd est-i de la sécurisation de ces dits-fichiers, l et que devrait-on
choisir comment nom d'extension ?
Règle 1 : le contenu de tout fichier non parsé par php et contenant du
code php sera renvoyé tel quel au navigateur. Donc tout code php qu'il
contient sera lisible en clair. Donc selon la sensibilité du code en
question, cela introduit une faille ou non. Si le contenu est constitué
de déclaration de mots de passe ou de chemins sur disque, c'est plus
sensible que <?php echo $row['coincoin'];?> dont on peut seulement
déduire que probablement tu as une colonne d'une table qui s'appelle
coincoin (et encore, car SELECT colonne1 AS coincoin est possible).
Règle 2 : ça dépend de la configuration du serveur http. Si le serveur
en question parse les .toto avec php, tu peux mettre tout le code que tu
veux dans les .toto : il est toujours amusant de voir l'augmentation
dans les logs des attaques recherchant cmd.exe ou trucmuche.dll suite à
renommage des .php en .asp sur une machine unix ;-)
Règle 3 : ça dépend d'où c'est situé sur le disque par rapport aux
autorisations d'accès. Si tu mets dans ./local_seulement/ les fichiers
toto.txt et .htacess avec <DENY FROM ALL> dedans, sur le papier, tu es
aussi (in)secure avec toto.txt que toto.php
Règle 4 : il faut systématiquement séparer le code qui définit du code
qui exécute. La vraie faille se situe surtout dans l'appel en direct
d'un fichier qui exécute réellement le code alors que le développeur ne
le voulait surtout pas. Ceci est particulièrement vrai dans le cas
d'abus de header:location. Exemple typique du code gruyère rencontré N
fois :
if(..... série de tests de cohérence)...
header("Location:faire_enregistrement.php");
else header("Location:erreur.php");
Et là manque de bol, moi j'appelle en boucle faire_enregistrement.php et
tous les tests de cohérence passent à la trappe. Alors que si j'avais
remplacé ce code à la noix par :
if(.....tests inversés...)
{
require("erreur.php");
exit();
}
define('CHECK_DONE',1);
require('faire_enregistrement.php');
ET que dans faire_enregistrement.php tu commences par :
if(!defined('CHECK_DONE') exit();
OU (à la limite) que tu renommes faire_enregistrement.php en
faire_enregistrement.txt (cas dans lequel il ne peut être exécuté que
par require()/inclde() local)
OU que tu mets faire_enregistrement.php dans un répertoire avec un
.htacess DENY FROM ALL
alors tu es blindé.
C'est très bien d'implémenter MVC (ou en tous cas, de tenter de s'en
rapprocher) mais il ne faut ni faire 36 allers-retours inutiles entre le
client et le serveur (je rappelle : header location = ping-pong) ni
donner un moyen de court-circuiter les tests de cohérence de
l'application.
Une fois de plus, le seul principe à se souvenir est simple : il est
impossible d'empêcher quiconque d'appeler nos scripts "publics" avec les
paramètres qu'il voudra, le nombre de fois à la seconde qu'il voudra,
dans le "mode" (GET ou POST) qu'il voudra. Cf wget par exemple.
Enfin concernant le nom "inc", c'est une convention de nommage comme une
autre, que personnellement je n'applique pas, mais c'est un autre
soucis. Chez moi, les librairies (allez faisons snob : le framework !)
sont en lib_NOMDUMODULE.php, les "templates du pauvre" ((C) JG 2002) en
print_NOM_ECRAN.php et j'en passe et des meilleures. Mais là dessus,
chacun son truc, du moment que lesdites règles sont claires.
A noter que la sécurité d'accès devrait elle aussi être indépendante du
serveur http utilisé. le .htaccess n'est PAS une solution portable et
devrait donc être évitée dans des développements à grande diffusion
(open source par exemple).
HTH
JG
PS : pour quelqu'un qui commençait par dire que le sujet était vite
torché, j'en ai encore pondu une tartine moi...
Une question bête mais pas méchante, dans la lignée de ce qu'avait tenté d'introduire sieur Gallet -john de son prénom-(c'est à dire une sorte de théma mensuelle), à savoir quelle extension pour certains fichiers, relatifs à la sécurité.
Louable intention, même si pour ce sujet là on ne va pas débattre longtemps, pour une fois ce sont des choses assez simples.
Alors, qd est-i de la sécurisation de ces dits-fichiers, l et que devrait-on choisir comment nom d'extension ?
Règle 1 : le contenu de tout fichier non parsé par php et contenant du code php sera renvoyé tel quel au navigateur. Donc tout code php qu'il contient sera lisible en clair. Donc selon la sensibilité du code en question, cela introduit une faille ou non. Si le contenu est constitué de déclaration de mots de passe ou de chemins sur disque, c'est plus sensible que <?php echo $row['coincoin'];?> dont on peut seulement déduire que probablement tu as une colonne d'une table qui s'appelle coincoin (et encore, car SELECT colonne1 AS coincoin est possible).
Règle 2 : ça dépend de la configuration du serveur http. Si le serveur en question parse les .toto avec php, tu peux mettre tout le code que tu veux dans les .toto : il est toujours amusant de voir l'augmentation dans les logs des attaques recherchant cmd.exe ou trucmuche.dll suite à renommage des .php en .asp sur une machine unix ;-)
Règle 3 : ça dépend d'où c'est situé sur le disque par rapport aux autorisations d'accès. Si tu mets dans ./local_seulement/ les fichiers toto.txt et .htacess avec <DENY FROM ALL> dedans, sur le papier, tu es aussi (in)secure avec toto.txt que toto.php
Règle 4 : il faut systématiquement séparer le code qui définit du code qui exécute. La vraie faille se situe surtout dans l'appel en direct d'un fichier qui exécute réellement le code alors que le développeur ne le voulait surtout pas. Ceci est particulièrement vrai dans le cas d'abus de header:location. Exemple typique du code gruyère rencontré N fois :
if(..... série de tests de cohérence)... header("Location:faire_enregistrement.php"); else header("Location:erreur.php");
Et là manque de bol, moi j'appelle en boucle faire_enregistrement.php et tous les tests de cohérence passent à la trappe. Alors que si j'avais remplacé ce code à la noix par : if(.....tests inversés...) { require("erreur.php"); exit(); } define('CHECK_DONE',1); require('faire_enregistrement.php');
ET que dans faire_enregistrement.php tu commences par : if(!defined('CHECK_DONE') exit();
OU (à la limite) que tu renommes faire_enregistrement.php en faire_enregistrement.txt (cas dans lequel il ne peut être exécuté que par require()/inclde() local)
OU que tu mets faire_enregistrement.php dans un répertoire avec un .htacess DENY FROM ALL
alors tu es blindé.
C'est très bien d'implémenter MVC (ou en tous cas, de tenter de s'en rapprocher) mais il ne faut ni faire 36 allers-retours inutiles entre le client et le serveur (je rappelle : header location = ping-pong) ni donner un moyen de court-circuiter les tests de cohérence de l'application.
Une fois de plus, le seul principe à se souvenir est simple : il est impossible d'empêcher quiconque d'appeler nos scripts "publics" avec les paramètres qu'il voudra, le nombre de fois à la seconde qu'il voudra, dans le "mode" (GET ou POST) qu'il voudra. Cf wget par exemple.
Enfin concernant le nom "inc", c'est une convention de nommage comme une autre, que personnellement je n'applique pas, mais c'est un autre soucis. Chez moi, les librairies (allez faisons snob : le framework !) sont en lib_NOMDUMODULE.php, les "templates du pauvre" ((C) JG 2002) en print_NOM_ECRAN.php et j'en passe et des meilleures. Mais là dessus, chacun son truc, du moment que lesdites règles sont claires.
A noter que la sécurité d'accès devrait elle aussi être indépendante du serveur http utilisé. le .htaccess n'est PAS une solution portable et devrait donc être évitée dans des développements à grande diffusion (open source par exemple).
HTH JG
PS : pour quelqu'un qui commençait par dire que le sujet était vite torché, j'en ai encore pondu une tartine moi...
