Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Sécurité Sécurité Sécurité code php

code php

13 réponses
Avatar
laurent sommier
bonjour,


je code un site web dont l'arborescence est, en gros, organisée par
fonctionnalités

il existe plusieurs types de droits dans l'application, ces droits renvoient
tous aux accès base de données,
c'est à dire qu'un utilisateur à droit minimal est définit pour chacun
d'eux.

Au lieu de déclarer mes droits dans chaque script, je les déclare en racine
du sous répertoire renvoyant à la fonction traitée avec un fichier perm.php
je désire rendre ce fichier inaccessible par une requête http, j'ai trouvé
la solution suivante, mais elle "m'inquiète" et recherche donc un conseil

dans chaque script, je déclare une variable $key = "..." commune aux scripts
de même droits
puis,

# perm.php

if ( $key != "..." ) exit ;

$user = "..." ;
$pass = "..." ;


qu'en pensez vous ?


ls...
Signaler un problème avec ce contenu

10 réponses

Supprimer
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
1 2
Avatar
Stephane Catteau
laurent sommier nous disait récement dans fr.comp.securite
<news:3f58b7e0$0$20175$ :

Au lieu de déclarer mes droits dans chaque script, je les déclare
en racine du sous répertoire renvoyant à la fonction traitée avec
un fichier perm.php


Jusqu'à là ça peut aller.


je désire rendre ce fichier inaccessible par une requête http,


Pourquoi ? :-/


j'ai trouvé la solution suivante, mais elle "m'inquiète"


Pourquoi ?


dans chaque script, je déclare une variable $key = "..." commune
aux scripts de même droits


Oui.


puis,

# perm.php

if ( $key != "..." ) exit ;

$user = "..." ;
$pass = "..." ;


qu'en pensez vous ?


Qu'un appel à une fonction serait plus simple.

[Note: je code à tête épuisée, il faudra peut-être adapter en vrai PHP]

perm.php

define( __LEVEL1__, "a" );
define( __LEVEL2__, "b" );
[...]
define( __LEVELn__, "x" );

function perm( $level )
{

switch( $level )
case __LEVEL1__ :
$user = "xyz";
$pass = "xyz";
break;
[...]
case __LEVELn__ :
$user = "abc";
$pass = "abc";
break;
default :
break;

return( array( $user, $pass ) );

}


[fichier].php

$user = '';
$pass = '';
include( "perm.php" );
list( $user, $pass ) = perm( __LEVEL1__ );


--
"Si ceux qui disent du mal de moi savaient exactement ce que je
pense d'eux , ils en diraient bien davantage."
Sacha Guitry

Avatar
DeadCow
"laurent sommier" a écrit dans le
message news: 3f58b7e0$0$20175$
je désire rendre ce fichier inaccessible par une requête http


Tu veut une solution sure ? Alors change l'extension de ton fichier ( par
exemple .perm ). Ensuite, si tu est sous apache ( ce qui a des chances
d'être le cas ) tu créé un fichier .htaccess à la racine du site. Dedans tu
met ça :

<Files "*.perm" >
Deny from all
</Files>

Le mieux serait que tu puisse modifier le fichier de configuration, auquel
cas tu met les ligne si dessus directement dedans ( enfin au bon endroit
quand même =)

Voilà

-- Nicolas Repiquet

Avatar
Stephane Catteau
DeadCow nous disait récement dans fr.comp.securite
<news:3f58f91e$0$28906$ :

Tu veut une solution sure ? Alors change l'extension de ton
fichier ( par exemple .perm ). Ensuite, si tu est sous apache ( ce
qui a des chances d'être le cas ) tu créé un fichier .htaccess à la
racine du site. Dedans tu met ça :

<Files "*.perm" >
Deny from all
</Files>


Et cela apportera quoi en plus au niveau de la sécurité ? Un fichier
.php adressé directement est *obligatoirement* interprété par le
serveur, personne ne verra jamais son contenu, sauf à l'accéder en
passant par le FTP associé au site. Problème qui reste valable dans ta
solution. Reste le cas de l'adressage indirecte via la faille
traditionnelle des scripts PHP tout cuit[1]. Mais là encore la faille
est valable pour les fichiers en .php autant que pour ta solution.
Donc, à par compliquer les choses, et donc augmenter les risques de
failles, cela n'apporte rien de plus.


[1]
index.php?page=fichier
include( 'répertire/'.$page.'.php');

--
"Si ceux qui disent du mal de moi savaient exactement ce que je
pense d'eux , ils en diraient bien davantage."
Sacha Guitry

Avatar
DeadCow
"Stephane Catteau" a écrit dans le message news:

Et cela apportera quoi en plus au niveau de la sécurité ?


Par rapport à quoi ?

Un fichier
.php adressé directement est *obligatoirement* interprété par le
serveur, personne ne verra jamais son contenu, sauf à l'accéder en
passant par le FTP associé au site. Problème qui reste valable dans ta
solution. Reste le cas de l'adressage indirecte via la faille
traditionnelle des scripts PHP tout cuit[1]. Mais là encore la faille
est valable pour les fichiers en .php autant que pour ta solution.
Donc, à par compliquer les choses, et donc augmenter les risques de
failles, cela n'apporte rien de plus.


Ca apporte qu'il y a une différence entre "pas affichée" et "pas executée".
En l'occurence, même si la page n'affiche rien, il est conceptuellement plus
rigoureux d'interdire sont execution.

-- Nicolas Repiquet

Avatar
Stephane Catteau
DeadCow nous disait récement dans fr.comp.securite
<news:3f5a167c$0$28881$ :

"Stephane Catteau" a écrit dans le message

Et cela apportera quoi en plus au niveau de la sécurité ?


Par rapport à quoi ?


Fort logiquement, par rapport à la solution qu'il présentait et sur
laquelle il voulait des informations...


[...] Donc, à par compliquer les choses, et donc augmenter les
risques de failles, cela n'apporte rien de plus.


Ca apporte qu'il y a une différence entre "pas affichée" et "pas
executée". En l'occurence, même si la page n'affiche rien, il est
conceptuellement plus rigoureux d'interdire sont execution.


Parler de "rigueur" pour qualifier une méthode qui passe par une étape
qui désécurise complètement le fichier, ça me laisse perplexe. S'il est
obligé de réinstaller son site, ou qu'il en copie le principe pour un
autre site, mais oublie le fichier .htaccess ou y fait une erreur de
frappe, ou s'il oublie que l'extension du fichier doit être en accord
avec celle indiquée dans le fichier .htaccess (pire encore si comme tu
le conseillais il faisait la modification directement dans httpd.conf),
il se retrouve avec un niveau de sécurité nulle.
Tout cela pour n'apporter aucun plus, sécuritairement parlant, par
rapport à la version initiale.


--
"Si ceux qui disent du mal de moi savaient exactement ce que je
pense d'eux , ils en diraient bien davantage."
Sacha Guitry


Avatar
DeadCow
"Stephane Catteau" a écrit dans le message news:

Parler de "rigueur" pour qualifier une méthode qui passe par une étape
qui désécurise complètement le fichier, ça me laisse perplexe.


déssécurisé complètement ?

S'il est
obligé de réinstaller son site, ou qu'il en copie le principe pour un
autre site, mais oublie le fichier .htaccess ou y fait une erreur de
frappe, ou s'il oublie que l'extension du fichier doit être en accord
avec celle indiquée dans le fichier .htaccess (pire encore si comme tu
le conseillais il faisait la modification directement dans httpd.conf),
il se retrouve avec un niveau de sécurité nulle.
Tout cela pour n'apporter aucun plus, sécuritairement parlant, par
rapport à la version initiale.


Il me semble juste que quand on ne doit pas pouvoir acceder à un fichier, il
vaut mieux en interdire l'acces, plutot que de garder l'acces possible et
s'arranger pour que ce soit sans conséquences.

Moi toute mes librairies php sont des .inc, et j'ai mis dans ma config .inc
= interdit. Ca me semble tout à fait indiqué. Maintenant le jour ou
j'écrirais .ink à la place ben déja mon "require("xxx.inc")" va foirer donc
je m'en apercevrais vite.

Si il en est à faire ce genre d'erreur, il faudra pas qu'il oublis de
configurer sont serveur pour executer les .php et pas les afficher
directement ... franchement je trouve l'argument un peu tiré par les
cheuveux.

Et je répète que le "plus" c'est que le fichier ne sera même pas executé, ce
qui me semble être une sécurité.

-- Nicolas Repiquet

Avatar
Matthieu
bonsoir,

Au lieu de déclarer mes droits dans chaque script, je les déclare en
racine

du sous répertoire renvoyant à la fonction traitée avec un fichier
perm.php

je désire rendre ce fichier inaccessible par une requête http, j'ai trouvé
la solution suivante, mais elle "m'inquiète" et recherche donc un conseil



si tu heberges un serveur Apache, tu peux utiliser le mod_rewrite;
globalement il te permettra de tester si le referer est une page de ton site
ou pas.
dans le cas contraire, tu rediriges vers une autre page.
cherches sur google, tu trouveras plein de tutoriaux

mais cela passe encore par le .htaccess...

Avatar
Cedric Blancher
Dans sa prose, DeadCow nous ecrivait :
Il me semble juste que quand on ne doit pas pouvoir acceder à un fichier,
il vaut mieux en interdire l'acces, plutot que de garder l'acces possible
et s'arranger pour que ce soit sans conséquences.


De toute manière, si on veut un minimum de sécurité pour une page web
dynamique, on ne doit trouver sous la racine de publication qui les
fichiers accessibles depuis un navigateur. Ce qui veut dire qu'un .inc par
exemple ne doit pas se trouver là, mais en dessous.

Ça nous donne des arborescences du genre :

www_home --- htdocs (racine de publication)
|
`- includes

De fait, comme la racine de publication est htdocs, on ne peut pas
accéder via le navigateur en URL directe à un fichier situé sous
includes.

Ensuite, on peut se concentrer sur son code pour ne pas faire de directory
traversal et autre connerie grossière permettant d'aller chercher dans
ces répertoires.

--
BOFH excuse #437:

crop circles in the corn shell

Avatar
Eric Razny
"Matthieu" a écrit dans le message de
news:3f5a51db$0$13307$
bonsoir,

si tu heberges un serveur Apache, tu peux utiliser le mod_rewrite;
globalement il te permettra de tester si le referer est une page de ton
site

ou pas.


Raté : le referer est une info externe, qui peut être trafiquée :)
Ok pour un truc sans conséquence mais pas pour un vrai contrôle.

Eric.

Avatar
Stephane Catteau
DeadCow nous disait récement dans fr.comp.securite
<news:3f5a7fdc$0$28882$ :

"Stephane Catteau" a écrit dans le message

Parler de "rigueur" pour qualifier une méthode qui passe par une
étape qui désécurise complètement le fichier, ça me laisse perplexe.


déssécurisé complètement ?


Oui, puisque *l'une des étapes* consiste à changer l'extension du
fichier, le rendant accessible à tous.


[Snip]
Il me semble juste que quand on ne doit pas pouvoir acceder à un
fichier, il vaut mieux en interdire l'acces, plutot que de garder
l'acces possible et s'arranger pour que ce soit sans conséquences.


Oui, et il existe un moyen radical pour cela. Tu places un deny all
dans l'un au moins des répertoire de l'include_path, et tu mets le
fichier dedans. Pas besoin de changer son extension pour cela.


Et je répète que le "plus" c'est que le fichier ne sera même pas
executé, ce qui me semble être une sécurité.


Reprenons depuis le début...

1) http://balbla.tld/fichier.php
Le fichier sera interprété par le serveur

2) http://balbla.tld/fichier.ext
Le contenu du fichier sera affiché par le serveur

3) http://blabla.tld/index.php?inc=fichier et include( $inc.'.php' )
Le fichier sera interprété par le serveur

4) http://blabla.tld/index.php?inc=fichier et include( $inc.'.ext' )
Le fichier sera interprété par le serveur

Tu m'expliques où est le plus en matière de sécurité ? La seule chose
qui permet de sécuriser ton "astuce", c'est l'ajout d'un deny dans le
.htaccess. Tout cela pour obtenir à peine plus de sécurité que si l'on
avait rien fait.


--
"Si ceux qui disent du mal de moi savaient exactement ce que je
pense d'eux , ils en diraient bien davantage."
Sacha Guitry


1 2