je dois faire une grande mise a jour d'un de mes sites web.
Jusqu'a maintenant j'ai toujours passe les parametres par des urls de type :
<a href="index.php3?page=home>Home</a>
et je recupere le tout avec $page.
Il semble que depuis la version 1.7 de EasyPHP, il ne permette pas les
variables globales par defaut. Donc je fais un test avec une url :
<a href="index.php3?page=home>Home</a>
et je recupere ma variable par:
$page=$_GET['page']
OK, mais il y a vraiment une bonne raison de devoir tout passer par
$_GET , parceque si je modifie la variable page=... dans la barre
d'adresse du navigateur, je peux modifier la page affichee.
Ou est le cote securite dans cette nouvelle de facon de faire ?
Si je dois refaire ce site, autant le faire tout de suite juste.
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
Ronnie Garcia
Jusqu'a maintenant j'ai toujours passe les parametres par des urls de type : <a href="index.php3?page=home>Home</a>
et je recupere le tout avec $page.
Il semble que depuis la version 1.7 de EasyPHP, il ne permette pas les variables globales par defaut. Donc je fais un test avec une url :
<a href="index.php3?page=home>Home</a>
et je recupere ma variable par: $page=$_GET['page']
OK, mais il y a vraiment une bonne raison de devoir tout passer par $_GET , parceque si je modifie la variable page=... dans la barre d'adresse du navigateur, je peux modifier la page affichee.
Ou est le cote securite dans cette nouvelle de facon de faire ?
Il y a deux choses différentes a cerner :
- les variables que tu recuperes d'une entrée utilisateur (au sens général), comme une variable d'url,
- les autres variables de ton script, qui ne servent qu'a l'intérieur du script.
Lorsque register_global est activé, ces *deux* types de variables pourraient être initialisées par une personne mal intentionnée en la passant dans l'url (par exemple). Tu peux vite arriver a des problèmes de sécurité que je ne détaillerais pas, ca a déjà été fait dans ce NG.
En revanche, et tu as bien raison de le signaler, ca ne t'empêche *surtout pas* d'avoir à faire des tests sur tes entrées utilisateur.
Tu *dois* (dans tous les cas) vérifier que la valeur entrée correspond à ce que tu attends. register_global activé ou non.
Hormis le coté sécurité, programmer avec les variables super-globales ($_GET, $_POST, etc) te garanti une meilleure portabilité de ton logiciel car il fonctionnera sur tous les serveurs, que register_global soit activé ou non.
-- Ronnie Garcia <ronnie at mk2 dot net>
Jusqu'a maintenant j'ai toujours passe les parametres par des urls de
type :
<a href="index.php3?page=home>Home</a>
et je recupere le tout avec $page.
Il semble que depuis la version 1.7 de EasyPHP, il ne permette pas les
variables globales par defaut. Donc je fais un test avec une url :
<a href="index.php3?page=home>Home</a>
et je recupere ma variable par:
$page=$_GET['page']
OK, mais il y a vraiment une bonne raison de devoir tout passer par
$_GET , parceque si je modifie la variable page=... dans la barre
d'adresse du navigateur, je peux modifier la page affichee.
Ou est le cote securite dans cette nouvelle de facon de faire ?
Il y a deux choses différentes a cerner :
- les variables que tu recuperes d'une entrée utilisateur (au sens
général), comme une variable d'url,
- les autres variables de ton script, qui ne servent qu'a l'intérieur
du script.
Lorsque register_global est activé, ces *deux* types de variables
pourraient être initialisées par une personne mal intentionnée en la
passant dans l'url (par exemple). Tu peux vite arriver a des problèmes
de sécurité que je ne détaillerais pas, ca a déjà été fait dans ce NG.
En revanche, et tu as bien raison de le signaler, ca ne t'empêche
*surtout pas* d'avoir à faire des tests sur tes entrées utilisateur.
Tu *dois* (dans tous les cas) vérifier que la valeur entrée correspond à
ce que tu attends. register_global activé ou non.
Hormis le coté sécurité, programmer avec les variables super-globales
($_GET, $_POST, etc) te garanti une meilleure portabilité de ton
logiciel car il fonctionnera sur tous les serveurs, que register_global
soit activé ou non.
Jusqu'a maintenant j'ai toujours passe les parametres par des urls de type : <a href="index.php3?page=home>Home</a>
et je recupere le tout avec $page.
Il semble que depuis la version 1.7 de EasyPHP, il ne permette pas les variables globales par defaut. Donc je fais un test avec une url :
<a href="index.php3?page=home>Home</a>
et je recupere ma variable par: $page=$_GET['page']
OK, mais il y a vraiment une bonne raison de devoir tout passer par $_GET , parceque si je modifie la variable page=... dans la barre d'adresse du navigateur, je peux modifier la page affichee.
Ou est le cote securite dans cette nouvelle de facon de faire ?
Il y a deux choses différentes a cerner :
- les variables que tu recuperes d'une entrée utilisateur (au sens général), comme une variable d'url,
- les autres variables de ton script, qui ne servent qu'a l'intérieur du script.
Lorsque register_global est activé, ces *deux* types de variables pourraient être initialisées par une personne mal intentionnée en la passant dans l'url (par exemple). Tu peux vite arriver a des problèmes de sécurité que je ne détaillerais pas, ca a déjà été fait dans ce NG.
En revanche, et tu as bien raison de le signaler, ca ne t'empêche *surtout pas* d'avoir à faire des tests sur tes entrées utilisateur.
Tu *dois* (dans tous les cas) vérifier que la valeur entrée correspond à ce que tu attends. register_global activé ou non.
Hormis le coté sécurité, programmer avec les variables super-globales ($_GET, $_POST, etc) te garanti une meilleure portabilité de ton logiciel car il fonctionnera sur tous les serveurs, que register_global soit activé ou non.
-- Ronnie Garcia <ronnie at mk2 dot net>
Frederic BISSON
Hello !
Ou est le cote securite dans cette nouvelle de facon de faire ? D'une part, tu indiques précisément d'où viens ta variable $page. C'est
pratique pour la maintenance des programmes et par le fait qu'un utilisateur malintentionné ne peut pas utiliser d'autre moyen que la méthode $_GET pour donner une valeur à $page (implicite vs explicite).
Ensuite, ta manière de sélectionner une page est dangereuse.
Si, dans ton code, tu écris quelque chose comme : include $page.'.php';
Le même utilisateur intentionné peut s'amuser à donner à $page la valeur suivante : http://site.dangereux.com/code_malintentionne
et ainsi opérer comme il veut dans ton code et des données.
En général, plus le déroulement de ton code est explicite et déterministe, plus le nombre de failles potentielles diminue.
@+
Frédéric BISSON
Hello !
Ou est le cote securite dans cette nouvelle de facon de faire ?
D'une part, tu indiques précisément d'où viens ta variable $page. C'est
pratique pour la maintenance des programmes et par le fait qu'un
utilisateur malintentionné ne peut pas utiliser d'autre moyen que la
méthode $_GET pour donner une valeur à $page (implicite vs explicite).
Ensuite, ta manière de sélectionner une page est dangereuse.
Si, dans ton code, tu écris quelque chose comme :
include $page.'.php';
Le même utilisateur intentionné peut s'amuser à donner à $page la
valeur suivante :
http://site.dangereux.com/code_malintentionne
et ainsi opérer comme il veut dans ton code et des données.
En général, plus le déroulement de ton code est explicite et
déterministe, plus le nombre de failles potentielles diminue.
Ou est le cote securite dans cette nouvelle de facon de faire ? D'une part, tu indiques précisément d'où viens ta variable $page. C'est
pratique pour la maintenance des programmes et par le fait qu'un utilisateur malintentionné ne peut pas utiliser d'autre moyen que la méthode $_GET pour donner une valeur à $page (implicite vs explicite).
Ensuite, ta manière de sélectionner une page est dangereuse.
Si, dans ton code, tu écris quelque chose comme : include $page.'.php';
Le même utilisateur intentionné peut s'amuser à donner à $page la valeur suivante : http://site.dangereux.com/code_malintentionne
et ainsi opérer comme il veut dans ton code et des données.
En général, plus le déroulement de ton code est explicite et déterministe, plus le nombre de failles potentielles diminue.
@+
Frédéric BISSON
Olivier Miakinen
D'une part, tu indiques précisément d'où viens ta variable $page. C'est pratique [...] par le fait qu'un utilisateur malintentionné ne peut pas utiliser d'autre moyen que la méthode $_GET pour donner une valeur à $page (implicite vs explicite).
Voir <news: ou encore <http://www.google.fr/groups?selmAA1C3C1.22FF0946%40wanadoo.fr>.
Je suis d'accord avec tout le reste de ta réponse, que je ne cite pas.
-- Olivier Miakinen Non, monsieur le juge, je vous le jure : jamais je n'ai cité Bruxelles dans ma signature.
D'une part, tu indiques précisément d'où viens ta variable $page.
C'est pratique [...] par le fait qu'un utilisateur malintentionné ne
peut pas utiliser d'autre moyen que la méthode $_GET pour donner une
valeur à $page (implicite vs explicite).
Voir <news:41A1C3C1.22FF0946@wanadoo.fr> ou encore
<http://www.google.fr/groups?selmAA1C3C1.22FF0946%40wanadoo.fr>.
D'une part, tu indiques précisément d'où viens ta variable $page. C'est pratique [...] par le fait qu'un utilisateur malintentionné ne peut pas utiliser d'autre moyen que la méthode $_GET pour donner une valeur à $page (implicite vs explicite).
Voir <news: ou encore <http://www.google.fr/groups?selmAA1C3C1.22FF0946%40wanadoo.fr>.
