Suite à un passage sur serveur dédié avec le register_globals sur OFF
nous sommes obligés de reprendre certaines portions de code PHP.
Dans le cas du passage de variables dans l'URL, il nous arrivait
fréquément de ne pas forcément utiliser la variable passée en url.
Je m'explique sur un exemple : imaginons l'affichage d'une information
issue d'une base de données avec dous le detail de l'information, les
titres des autres informations classées 10 par 10. On va pouvoir passer
comme variables $id qui est le numero de l'information et $page qui est
le numére de la page à afficher (position dans le flux des
informations).
Mais l'appel à l'une, l'autre ou les deux variables n'est pas toujours
présent dans notre code.
On peut avoir :
<A HREF>affiche.php</A>
ou
<A HREF>affiche.php?id=XX</A>
ou encore
<A HREF>affiche.php?id=XX&page=YY</A>
même si on a bien
$id_page=$_GET["id_ page"];
$id=$_GET["id"];
Les deux premiers exemples HTML vont provoquer une erreur...
La seule solution est-elle d'avoir systématiquement TOUTES LES VARIABLES
dans les liens quitte à avoir parfois "affiche.php?id=&page="
Les deux premiers exemples HTML vont provoquer une erreur...
Oui.
La seule solution est-elle d'avoir systématiquement TOUTES LES VARIABLES dans les liens quitte à avoir parfois "affiche.php?id=&page="
Non. Tu dois éviter les erreurs, quelles que soient les données que t'envoie le visiteur (et rien ne m'empêche d'appeler ton script avec les paramètres « ?idÎ_que_je_veux&messian=n_importe_quoi »).
Par exemple :
$id = "une valeur par défaut que *tu* choisis"; if (isset($_REQUEST["id"])) { if (tu vérifies que $_REQUEST["id"] est valide) { $id = $_REQUEST["id"]; } }
Note que j'ai remplacé _GET par _REQUEST car cela te permettra, sans perte de sécurité, de traiter aussi bien un GET qu'un POST.
-- Olivier Miakinen Non, monsieur le juge, je vous le jure : jamais je n'ai cité Bruxelles dans ma signature.
Les deux premiers exemples HTML vont provoquer une erreur...
Oui.
La seule solution est-elle d'avoir systématiquement TOUTES LES VARIABLES
dans les liens quitte à avoir parfois "affiche.php?id=&page="
Non. Tu dois éviter les erreurs, quelles que soient les données que
t'envoie le visiteur (et rien ne m'empêche d'appeler ton script avec
les paramètres « ?idÎ_que_je_veux&messian=n_importe_quoi »).
Par exemple :
$id = "une valeur par défaut que *tu* choisis";
if (isset($_REQUEST["id"])) {
if (tu vérifies que $_REQUEST["id"] est valide) {
$id = $_REQUEST["id"];
}
}
Note que j'ai remplacé _GET par _REQUEST car cela te permettra, sans
perte de sécurité, de traiter aussi bien un GET qu'un POST.
--
Olivier Miakinen
Non, monsieur le juge, je vous le jure : jamais je n'ai cité
Bruxelles dans ma signature.
Les deux premiers exemples HTML vont provoquer une erreur...
Oui.
La seule solution est-elle d'avoir systématiquement TOUTES LES VARIABLES dans les liens quitte à avoir parfois "affiche.php?id=&page="
Non. Tu dois éviter les erreurs, quelles que soient les données que t'envoie le visiteur (et rien ne m'empêche d'appeler ton script avec les paramètres « ?idÎ_que_je_veux&messian=n_importe_quoi »).
Par exemple :
$id = "une valeur par défaut que *tu* choisis"; if (isset($_REQUEST["id"])) { if (tu vérifies que $_REQUEST["id"] est valide) { $id = $_REQUEST["id"]; } }
Note que j'ai remplacé _GET par _REQUEST car cela te permettra, sans perte de sécurité, de traiter aussi bien un GET qu'un POST.
-- Olivier Miakinen Non, monsieur le juge, je vous le jure : jamais je n'ai cité Bruxelles dans ma signature.
(¯`·..Yttrium ...·´¯)
Note que j'ai remplacé _GET par _REQUEST car cela te permettra, sans perte de sécurité, de traiter aussi bien un GET qu'un POST.
Bjr,
"Sans perte de sécurité".. ???? Ah bon, ce n'est pas une faille que de laisser aux visiteurs la possibilité de passer en GET des variables qui sont censées etre récupéreés en POST ? Merci de quelques explications..
Note que j'ai remplacé _GET par _REQUEST car cela te permettra, sans
perte de sécurité, de traiter aussi bien un GET qu'un POST.
Bjr,
"Sans perte de sécurité".. ????
Ah bon, ce n'est pas une faille que de laisser aux visiteurs la possibilité
de passer en GET des variables qui sont censées etre récupéreés en POST ?
Merci de quelques explications..
Note que j'ai remplacé _GET par _REQUEST car cela te permettra, sans perte de sécurité, de traiter aussi bien un GET qu'un POST.
Bjr,
"Sans perte de sécurité".. ???? Ah bon, ce n'est pas une faille que de laisser aux visiteurs la possibilité de passer en GET des variables qui sont censées etre récupéreés en POST ? Merci de quelques explications..
John GALLET
"Sans perte de sécurité".. ???? Oui. Sans perte de sécurité.
Ah bon, ce n'est pas une faille que de laisser aux visiteurs la possibilité de passer en GET des variables qui sont censées etre récupéreés en POST ? Non. On s'en bat les coucougnettes de la méthode de transmission des
variables. C'est leur CONTENU qui est dangereux. Peu importe qu'elles arrivent par GET, POST, pigeon voyageur ou chameau postal.
Merci de quelques explications.. Merci de lire les archives, on en a causé des dizaines de fois. Tiens au
-- JR> Le progrès. Maintenant sur CD à dos de chameau. Quel protocole? La détection de collision. Si deux chameaux se téléscopent, on retransmet un kangourou. -+- JYB in GNU : C'est cha mot pour mot -+-
"Sans perte de sécurité".. ????
Oui. Sans perte de sécurité.
Ah bon, ce n'est pas une faille que de laisser aux visiteurs la possibilité
de passer en GET des variables qui sont censées etre récupéreés en POST ?
Non. On s'en bat les coucougnettes de la méthode de transmission des
variables. C'est leur CONTENU qui est dangereux. Peu importe qu'elles
arrivent par GET, POST, pigeon voyageur ou chameau postal.
Merci de quelques explications..
Merci de lire les archives, on en a causé des dizaines de fois. Tiens au
--
JR> Le progrès. Maintenant sur CD à dos de chameau. Quel protocole?
La détection de collision. Si deux chameaux se téléscopent, on
retransmet un kangourou.
-+- JYB in GNU : C'est cha mot pour mot -+-
"Sans perte de sécurité".. ???? Oui. Sans perte de sécurité.
Ah bon, ce n'est pas une faille que de laisser aux visiteurs la possibilité de passer en GET des variables qui sont censées etre récupéreés en POST ? Non. On s'en bat les coucougnettes de la méthode de transmission des
variables. C'est leur CONTENU qui est dangereux. Peu importe qu'elles arrivent par GET, POST, pigeon voyageur ou chameau postal.
Merci de quelques explications.. Merci de lire les archives, on en a causé des dizaines de fois. Tiens au
-- JR> Le progrès. Maintenant sur CD à dos de chameau. Quel protocole? La détection de collision. Si deux chameaux se téléscopent, on retransmet un kangourou. -+- JYB in GNU : C'est cha mot pour mot -+-
newdb
(..Yttrium ...) wrote:
Ah bon, ce n'est pas une faille que de laisser aux visiteurs la possibilité de passer en GET des variables qui sont censées etre récupéreés en POST ? Merci de quelques explications..
a priori non, il n'y a pas plus de risque. puisque quel que soit la route qu'elles auront empruntée tes variables doivent être initialisées/comparées/nettoyées/vérifiées.
si une variable pos un problème de sécurité en arrivant en $_GET, elle en posera tout autant en arrivant en $_POST : rien n'empêche l'utilisation d'un formulaire bâti **par l'utilisateur** (sur son serveur) avec action="ton_script_php" et **tes** noms de champ/variable ; tu verrais alors arriver des variables en $_POST pas plus **sûres** que si passées en $_GET dans l'url.
néanmoins, pour ce qui de l'utilisation de $_REQUEST, attention toutefois à la configuration variables_order (réglée le plus souvent en EGPCS) : ainsi, une variable **de même nom** passée en GET et en POST se verra affectée ***dans le tableau $_REQUEST*** de la valeur passée en POST. une variable de même nom passée en GET, en POST et en COOKIE se verra affectée ***dans le tableau $_REQUEST*** de la valeur passée en COOKIE.
un test avec le tableau $_REQUEST où sont donc inclus les tableaux $_GET, $_POST, et $_COOKIE
--------
test1.php (envoi d'une variable $commune à la fois en $_GET, $_POST et $_COOKIE)
Ah bon, ce n'est pas une faille que de laisser aux visiteurs la possibilité
de passer en GET des variables qui sont censées etre récupéreés en POST ?
Merci de quelques explications..
a priori non, il n'y a pas plus de risque.
puisque quel que soit la route qu'elles auront empruntée tes variables
doivent être initialisées/comparées/nettoyées/vérifiées.
si une variable pos un problème de sécurité en arrivant en $_GET, elle
en posera tout autant en arrivant en $_POST :
rien n'empêche l'utilisation d'un formulaire bâti **par l'utilisateur**
(sur son serveur) avec action="ton_script_php" et **tes** noms de
champ/variable ; tu verrais alors arriver des variables en $_POST pas
plus **sûres** que si passées en $_GET dans l'url.
néanmoins, pour ce qui de l'utilisation de $_REQUEST, attention
toutefois à la configuration variables_order (réglée le plus
souvent en EGPCS) :
ainsi, une variable **de même nom** passée en GET et en POST se
verra affectée ***dans le tableau $_REQUEST*** de la valeur passée en
POST.
une variable de même nom passée en GET, en POST et en COOKIE se verra
affectée ***dans le tableau $_REQUEST*** de la valeur passée en
COOKIE.
un test avec le tableau $_REQUEST
où sont donc inclus les tableaux $_GET, $_POST, et $_COOKIE
--------
test1.php
(envoi d'une variable $commune à la fois en $_GET, $_POST et $_COOKIE)
Ah bon, ce n'est pas une faille que de laisser aux visiteurs la possibilité de passer en GET des variables qui sont censées etre récupéreés en POST ? Merci de quelques explications..
a priori non, il n'y a pas plus de risque. puisque quel que soit la route qu'elles auront empruntée tes variables doivent être initialisées/comparées/nettoyées/vérifiées.
si une variable pos un problème de sécurité en arrivant en $_GET, elle en posera tout autant en arrivant en $_POST : rien n'empêche l'utilisation d'un formulaire bâti **par l'utilisateur** (sur son serveur) avec action="ton_script_php" et **tes** noms de champ/variable ; tu verrais alors arriver des variables en $_POST pas plus **sûres** que si passées en $_GET dans l'url.
néanmoins, pour ce qui de l'utilisation de $_REQUEST, attention toutefois à la configuration variables_order (réglée le plus souvent en EGPCS) : ainsi, une variable **de même nom** passée en GET et en POST se verra affectée ***dans le tableau $_REQUEST*** de la valeur passée en POST. une variable de même nom passée en GET, en POST et en COOKIE se verra affectée ***dans le tableau $_REQUEST*** de la valeur passée en COOKIE.
un test avec le tableau $_REQUEST où sont donc inclus les tableaux $_GET, $_POST, et $_COOKIE
--------
test1.php (envoi d'une variable $commune à la fois en $_GET, $_POST et $_COOKIE)
$_GET: Array ( [commune] => get [GET] => get ) $_POST: Array ( [commune] => post [POST] => post ) $_COOKIE: Array ( [commune] => cookie [COOKIE] => cookie ) $_REQUEST: Array ( [commune] => cookie [GET] => get [POST] => post [COOKIE] => cookie )
-- @@@@@ E -00 comme on est very beaux dis ! ' `) / |_ =="
CrazyCat
(¯`·..Yttrium ...·´¯) wrote:
Note que j'ai remplacé _GET par _REQUEST car cela te permettra, sans perte de sécurité, de traiter aussi bien un GET qu'un POST. "Sans perte de sécurité".. ????
Ah bon, ce n'est pas une faille que de laisser aux visiteurs la possibilité de passer en GET des variables qui sont censées etre récupéreés en POST ? Merci de quelques explications..
A l'origine les variables étaient en GET, donc Olivier n'a fait qu'ajouter la possibilité de les passer en POST, pas l'inverse.
-- Découvrez Original War: http://www.original-war.org Humour: http://www.chatfou.com Tchattez en liberté: http://www.crazy-irc.net
(¯`·..Yttrium ...·´¯) wrote:
Note que j'ai remplacé _GET par _REQUEST car cela te permettra, sans
perte de sécurité, de traiter aussi bien un GET qu'un POST.
"Sans perte de sécurité".. ????
Ah bon, ce n'est pas une faille que de laisser aux visiteurs la possibilité
de passer en GET des variables qui sont censées etre récupéreés en POST ?
Merci de quelques explications..
A l'origine les variables étaient en GET, donc Olivier n'a fait
qu'ajouter la possibilité de les passer en POST, pas l'inverse.
--
Découvrez Original War: http://www.original-war.org
Humour: http://www.chatfou.com
Tchattez en liberté: http://www.crazy-irc.net
Note que j'ai remplacé _GET par _REQUEST car cela te permettra, sans perte de sécurité, de traiter aussi bien un GET qu'un POST. "Sans perte de sécurité".. ????
Ah bon, ce n'est pas une faille que de laisser aux visiteurs la possibilité de passer en GET des variables qui sont censées etre récupéreés en POST ? Merci de quelques explications..
A l'origine les variables étaient en GET, donc Olivier n'a fait qu'ajouter la possibilité de les passer en POST, pas l'inverse.
-- Découvrez Original War: http://www.original-war.org Humour: http://www.chatfou.com Tchattez en liberté: http://www.crazy-irc.net
dmetzler
Pour moi ce n'est pas une faille de sécurité. C'est pas parce qu'il est plus facile de passer des variables en GET qu'il est impossible de le faire en POST... donc l'un ou l'autre reviennent au même au niveau de la sécurité.
Mon avis là dessus c'est que c'est se casser la tête que faire la différence entre les deux.
Pour moi ce n'est pas une faille de sécurité. C'est pas parce qu'il
est plus facile de passer des variables en GET qu'il est impossible de
le faire en POST... donc l'un ou l'autre reviennent au même au niveau
de la sécurité.
Mon avis là dessus c'est que c'est se casser la tête que faire la
différence entre les deux.
Pour moi ce n'est pas une faille de sécurité. C'est pas parce qu'il est plus facile de passer des variables en GET qu'il est impossible de le faire en POST... donc l'un ou l'autre reviennent au même au niveau de la sécurité.
Mon avis là dessus c'est que c'est se casser la tête que faire la différence entre les deux.
Olivier Miakinen
Note que j'ai remplacé _GET par _REQUEST car cela te permettra, sans perte de sécurité, de traiter aussi bien un GET qu'un POST.
Bjr,
Oui, beuah aussi.
"Sans perte de sécurité".. ????
Absolument.
Ah bon, ce n'est pas une faille que de laisser aux visiteurs la possibilité de passer en GET des variables qui sont censées etre récupéreés en POST ? Merci de quelques explications..
Facile.
Si c'était une perte de sécurité d'accepter les variables en GET plutôt qu'en POST, cela voudrait dire que n'accepter ces variables qu'en POST plutôt qu'en GET serait un gain de sécurité, n'est-ce pas ?
Si oui, c'est bien : continue à le penser, et file-moi l'url d'un site dans lequel les valeurs des variables ne sont pas contrôlées du fait qu'elles sont « protégées » par le POST, et moi je vais m'improviser pirate.
Si au contraire tu vérifies toujours les valeurs des variables, même en POST, parce que tu sais qu'un visiteur peut générer n'importe quelle requête GET ou POST, alors quelle importance par quel tuyau elles sont passées ?
-- Olivier Miakinen Non, monsieur le juge, je vous le jure : jamais je n'ai cité Bruxelles dans ma signature.
Note que j'ai remplacé _GET par _REQUEST car cela te permettra, sans
perte de sécurité, de traiter aussi bien un GET qu'un POST.
Bjr,
Oui, beuah aussi.
"Sans perte de sécurité".. ????
Absolument.
Ah bon, ce n'est pas une faille que de laisser aux visiteurs la possibilité
de passer en GET des variables qui sont censées etre récupéreés en POST ?
Merci de quelques explications..
Facile.
Si c'était une perte de sécurité d'accepter les variables en GET plutôt
qu'en POST, cela voudrait dire que n'accepter ces variables qu'en POST
plutôt qu'en GET serait un gain de sécurité, n'est-ce pas ?
Si oui, c'est bien : continue à le penser, et file-moi l'url d'un site
dans lequel les valeurs des variables ne sont pas contrôlées du fait
qu'elles sont « protégées » par le POST, et moi je vais m'improviser pirate.
Si au contraire tu vérifies toujours les valeurs des variables, même en
POST, parce que tu sais qu'un visiteur peut générer n'importe quelle
requête GET ou POST, alors quelle importance par quel tuyau elles sont
passées ?
--
Olivier Miakinen
Non, monsieur le juge, je vous le jure : jamais je n'ai cité
Bruxelles dans ma signature.
Note que j'ai remplacé _GET par _REQUEST car cela te permettra, sans perte de sécurité, de traiter aussi bien un GET qu'un POST.
Bjr,
Oui, beuah aussi.
"Sans perte de sécurité".. ????
Absolument.
Ah bon, ce n'est pas une faille que de laisser aux visiteurs la possibilité de passer en GET des variables qui sont censées etre récupéreés en POST ? Merci de quelques explications..
Facile.
Si c'était une perte de sécurité d'accepter les variables en GET plutôt qu'en POST, cela voudrait dire que n'accepter ces variables qu'en POST plutôt qu'en GET serait un gain de sécurité, n'est-ce pas ?
Si oui, c'est bien : continue à le penser, et file-moi l'url d'un site dans lequel les valeurs des variables ne sont pas contrôlées du fait qu'elles sont « protégées » par le POST, et moi je vais m'improviser pirate.
Si au contraire tu vérifies toujours les valeurs des variables, même en POST, parce que tu sais qu'un visiteur peut générer n'importe quelle requête GET ou POST, alors quelle importance par quel tuyau elles sont passées ?
-- Olivier Miakinen Non, monsieur le juge, je vous le jure : jamais je n'ai cité Bruxelles dans ma signature.
CrazyCat
Olivier Miakinen wrote:
Si c'était une perte de sécurité d'accepter les variables en GET plutôt qu'en POST, cela voudrait dire que n'accepter ces variables qu'en POST plutôt qu'en GET serait un gain de sécurité, n'est-ce pas ? Si oui, c'est bien : continue à le penser, et file-moi l'url d'un site dans lequel les valeurs des variables ne sont pas contrôlées du fait qu'elles sont « protégées » par le POST, et moi je vais m'improviser pirate.
Qu'on me rafraichisse l'esprit... Il y a bien un séparateur de données qui fait que les variables envoyées en GET sont assimilées comme étant envoyées en POST?
Et je pense que n'importe qui est capable de faire un formulaire qui va pointer sur une page particulière et lui envoyer des données sous une forme ou l'autre.
Et beaucoup de personnes peuvent "faker" un HTTP_REFERER.
Alors la sécurité des données envoyées vers une page, je n'y crois pas trop. Par contre, les traitements à réception sont la pour bien vérifier l'intégrité et les tentatives de contournement.
P.S.: John, j'adore le chameau postal :)
-- Découvrez Original War: http://www.original-war.org Humour: http://www.chatfou.com Tchattez en liberté: http://www.crazy-irc.net
Olivier Miakinen wrote:
Si c'était une perte de sécurité d'accepter les variables en GET plutôt
qu'en POST, cela voudrait dire que n'accepter ces variables qu'en POST
plutôt qu'en GET serait un gain de sécurité, n'est-ce pas ?
Si oui, c'est bien : continue à le penser, et file-moi l'url d'un site
dans lequel les valeurs des variables ne sont pas contrôlées du fait
qu'elles sont « protégées » par le POST, et moi je vais m'improviser pirate.
Qu'on me rafraichisse l'esprit... Il y a bien un séparateur de données
qui fait que les variables envoyées en GET sont assimilées comme étant
envoyées en POST?
Et je pense que n'importe qui est capable de faire un formulaire qui va
pointer sur une page particulière et lui envoyer des données sous une
forme ou l'autre.
Et beaucoup de personnes peuvent "faker" un HTTP_REFERER.
Alors la sécurité des données envoyées vers une page, je n'y crois pas trop.
Par contre, les traitements à réception sont la pour bien vérifier
l'intégrité et les tentatives de contournement.
P.S.: John, j'adore le chameau postal :)
--
Découvrez Original War: http://www.original-war.org
Humour: http://www.chatfou.com
Tchattez en liberté: http://www.crazy-irc.net
Si c'était une perte de sécurité d'accepter les variables en GET plutôt qu'en POST, cela voudrait dire que n'accepter ces variables qu'en POST plutôt qu'en GET serait un gain de sécurité, n'est-ce pas ? Si oui, c'est bien : continue à le penser, et file-moi l'url d'un site dans lequel les valeurs des variables ne sont pas contrôlées du fait qu'elles sont « protégées » par le POST, et moi je vais m'improviser pirate.
Qu'on me rafraichisse l'esprit... Il y a bien un séparateur de données qui fait que les variables envoyées en GET sont assimilées comme étant envoyées en POST?
Et je pense que n'importe qui est capable de faire un formulaire qui va pointer sur une page particulière et lui envoyer des données sous une forme ou l'autre.
Et beaucoup de personnes peuvent "faker" un HTTP_REFERER.
Alors la sécurité des données envoyées vers une page, je n'y crois pas trop. Par contre, les traitements à réception sont la pour bien vérifier l'intégrité et les tentatives de contournement.
P.S.: John, j'adore le chameau postal :)
-- Découvrez Original War: http://www.original-war.org Humour: http://www.chatfou.com Tchattez en liberté: http://www.crazy-irc.net
