Variables Globales a OFF : contournement

[Road2Hells]

Salut,

en attendant de purger mes scripts contenant encore des variables globales
j'ai rajouté ceci au début ma librairie principale appelé par toutes mes
pages
[code]
foreach ($_POST as $k => $v) {
if ( (isset($_POST[$k])) && (!isset($$k)) ) {
$$k=$_POST[$k];
}
}
foreach ($_GET as $k => $v) {
if ( (isset($_GET[$k])) && (!isset($$k)) ) {
$$k=$_GET[$k];
}
}
[/code]

en gros ça me recrée les variables envoyés par les formulaires
pour chaque $_GET/POST[nom_variable] il me recrée une variable
$nom_variable

y a t'il un autre moyen lorsque les variables globales sont à OFF dans le
php.ini?

[slambert]

Post by Road2Hells
en attendant de purger mes scripts contenant encore des variables globales
j'ai rajouté ceci au début ma librairie principale appelé par toutes mes
pages
[code]
foreach ($_POST as $k => $v) {
if ( (isset($_POST[$k])) && (!isset($$k)) ) {
$$k=$_POST[$k];
}
}
foreach ($_GET as $k => $v) {
if ( (isset($_GET[$k])) && (!isset($$k)) ) {
$$k=$_GET[$k];
}
}
[/code]
en gros ça me recrée les variables envoyés par les formulaires
pour chaque $_GET/POST[nom_variable] il me recrée une variable
$nom_variable

Super dangereux.

Rajoute au moint un stripslashes, un trim, un striptag, un htmlentities,
voir un str_replace sur les % .

Au MI-NI-MUM. Et n'oublie pas non plus le cas des tableaux.

Tu peux, peut etre , faire comme cela, à la seule et unique condition de
bien comprendre ce que tu fais et de faire ton code en conséquence.

Post by Road2Hells
y a t'il un autre moyen lorsque les variables globales sont à OFF dans le
php.ini?

tu as le cas des magic quote aussi, dont il faudra prendre soin dans tes
tests....
if (get_magic_quotes_gpc()==1) .......

@++

Stef

[Road2Hells]

Post by slambert

Post by Road2Hells
[code]
foreach ($_POST as $k => $v) {
if ( (isset($_POST[$k])) && (!isset($$k)) ) {
$$k=$_POST[$k];
}
}
foreach ($_GET as $k => $v) {
if ( (isset($_GET[$k])) && (!isset($$k)) ) {
$$k=$_GET[$k];
}
}
[/code]

Super dangereux.
Rajoute au moint un stripslashes, un trim, un striptag, un
htmlentities, voir un str_replace sur les % .
Au MI-NI-MUM. Et n'oublie pas non plus le cas des tableaux.
Tu peux, peut etre , faire comme cela, à la seule et unique condition
de bien comprendre ce que tu fais et de faire ton code en conséquence.

pour info avant toutes injections/requetes mysql je passe mes variables
dans une de ces 2 fonctions
(j'utilise les librairies ADOdb pour mes accès database)

[code]
function make_db_safe ($input) {
// data going into the db
global $conf, $conn;
if ($conf[strip_html] = "yes") {
$output = strip_tags($input, $conf[allowed_html_tags]);
// strips out disallowed tags
}
$output = $conn->qstr($output, get_magic_quotes_gpc());
return $output;
}

function make_db_extra_safe ($input) {
// handles data going into the db
global $conn;
$output = strip_tags($input); // strips out all tags
$output = ereg_replace (";","",$output);
$output = $conn->qstr($output, get_magic_quotes_gpc());
return $output;
}
[/code]

[slambert]

Post by Road2Hells
function make_db_safe ($input) {
// data going into the db
global $conf, $conn;
if ($conf[strip_html] = "yes") {
$output = strip_tags($input, $conf[allowed_html_tags]);
// strips out disallowed tags
}
$output = $conn->qstr($output, get_magic_quotes_gpc());
return $output;
}

Je déduis a la présence de tes global ue tu n'as pas choisis la solution de
classes de conf qui te donne accès a des valeurs constantes via des appels
statiques...... Je n'aime pas les globales, mais bon.

Je pensais faire surtout tes verification non pas au moment de mettre dans
la bd, mais quand tes paramèteres arrivent. Tout en haut de la chaine, en
fait. Comme ca, meme si tu oublies ton appel avant une écriture, tes données
ont déjà été parsées. Et cela te permet de faire un moulinette plus
générale, y compris anti crossscripting.

Mais c'est dangereux tout de meme. Rien ne dit qu'un petit malin qui jouera
avec les urls ou un moteur d'envoit de param POST ne trouveras pas une
faille ou un truc que tu n'auras pas prévu. Il m'est arrivé de le faire sur
certains petits projets non vraiment critiques, mais mon écriture est dans
ce cas en conséquence.

Stef

[Road2Hells]

Post by slambert

Post by Road2Hells
function make_db_safe ($input) {
// data going into the db
global $conf, $conn;
if ($conf[strip_html] = "yes") {
$output = strip_tags($input, $conf[allowed_html_tags]);
// strips out disallowed tags
}
$output = $conn->qstr($output, get_magic_quotes_gpc());
return $output;
}

Je déduis a la présence de tes global ue tu n'as pas choisis la
solution de classes de conf qui te donne accès a des valeurs
constantes via des appels statiques...... Je n'aime pas les globales,
mais bon.

je programme mais en gros j'ai apris tout seul, en progressant du basic à
dcl/vms puis turbo pascal et perl puis php/mysql. j'en suis là !

Aucune méthode, juste que je regarde ce que font les autres, si je le
comprend et en saisit le concept, je l'intègre à mes developpements futurs
:-)
donc ta réflexion sur "solution de classes de conf qui te donne accès a des
valeurs constantes via des appels statiques" me laisse un peu pantois et
perplexe !

je suppose que ça cause "objet" mais je n'ai pas encore intégré ça dans un
coin de mon cerveau tordu.

tu aurais un exemple concis que je me faisse une idée :-) merci

[slambert]

Post by Road2Hells
donc ta réflexion sur "solution de classes de conf qui te donne accès a des
valeurs constantes via des appels statiques" me laisse un peu pantois et
perplexe !

L'appel à des valeurs statiques est une solution pour éviter de mettre des
constantes en globales ou de passer 40 000 paramètres à une fonction /
méthode.

Post by Road2Hells
je suppose que ça cause "objet" mais je n'ai pas encore intégré ça dans un
coin de mon cerveau tordu.
tu aurais un exemple concis que je me faisse une idée :-) merci

Bah, il faut aussi savoir ne pas faire d'objet.

Mais parfois, un bon petit modèle MVC....

Je t'encourage à aller te documenter. Au mieux, cela te fera une corde de
plus a ton arc, au pire, cela complètera ta culture : )

Stef

[thierry]

Post by Road2Hells
Salut,

bonjour,

le code

foreach ( $_REQUEST as $k => $v ) {
if ( !isset(${$k}) )
${$k} = $v;
}

devrait suffire

sinon
http://fr2.php.net/manual/fr/ini.core.php#ini.register-globals
si tu as accès à un htaccess (si ton serveur est sous apache quoi)

Post by Road2Hells
en attendant de purger mes scripts contenant encore des variables globales
j'ai rajouté ceci au début ma librairie principale appelé par toutes mes
pages
[code]
foreach ($_ as $k => $v) {
if ( (isset($_POST[$k])) && (!isset($$k)) ) {
$$k=$_POST[$k];
}
}
foreach ($_GET as $k => $v) {
if ( (isset($_GET[$k])) && (!isset($$k)) ) {
$$k=$_GET[$k];
}
}
[/code]
en gros ça me recrée les variables envoyés par les formulaires
pour chaque $_GET/POST[nom_variable] il me recrée une variable
$nom_variable
y a t'il un autre moyen lorsque les variables globales sont à OFF dans le
php.ini?

[Road2Hells]

Post by thierry
le code
foreach ( $_REQUEST as $k => $v ) {
if ( !isset(${$k}) )
${$k} = $v;
}
devrait suffire

sauf qu'en fonction de la directive de ton php.ini varables_orders=EGPCS
les résultat de $_REQUEST peuvent être imprévisible si tu a la mauvaise
idées d'appeller des variables de la même facon que certaines autres comme
des variables d'environnement ou server
je ne veux que POST et GET
je ne me sert pas, ni des $_ENV, ni des variables $_COOKIES, ni des
variables $_SERVER

Post by thierry
sinon
http://fr2.php.net/manual/fr/ini.core.php#ini.register-globals
si tu as accès à un htaccess (si ton serveur est sous apache quoi)

en local oui mais chez mon hébergeur non :-)

[thierry]

enfonçons une porte ouverte

évidemment dans ton foreach tu DOIS valider le format
des entrées

[Jerome Blion]

Bonsoir,

Ca va faire CINQ ANNEES (avril 2002) que le groupe PHP a sorti PHP 4.2.0
dans lequel la configuration par défaut désactive les globales...

Et aujourd'hui, vous cherchez toujours à la contourner...

Rappelez vous ce que disait Darwin. Seules les espèces adaptées
survivent. Tous les bidouillages pour recréer des pseudo-variables
globales m'horrifient...

En refaisant cette couche, vous passez du temps à sécuriser ce système
(ce que le groupe PHP n'a pas fait !!!) et finalement, ce temps, vous ne
le passez pas sur quelque chose de plus productif...

Bonne nuit.
Jérôme.

[Road2Hells]

Post by Jerome Blion
Bonsoir,
Ca va faire CINQ ANNEES (avril 2002) que le groupe PHP a sorti PHP 4.2.0
dans lequel la configuration par défaut désactive les globales...
Et aujourd'hui, vous cherchez toujours à la contourner...

et alors ?
le php offre cette possibilité et certains hébergeurs la positionne sur
off.
je ne vois pas bien où est le problème !

Post by Jerome Blion
Rappelez vous ce que disait Darwin. Seules les espèces adaptées
survivent. Tous les bidouillages pour recréer des pseudo-variables
globales m'horrifient...

je veux bien arrêter de faire des trucs "débiles" mais il faut au moins
m'expliquer pourquoi ?
Si c'est juste parce que c'est désactivé par défaut, c'est léger comme
explication !

Post by Jerome Blion
En refaisant cette couche, vous passez du temps à sécuriser ce système
(ce que le groupe PHP n'a pas fait !!!) et finalement, ce temps, vous ne
le passez pas sur quelque chose de plus productif...

je ne vois pas bien où est le probleme ?
en quoi $_POST[mavariable] est moins dangeureux que $mavariable

j'ai loupé un épisode ou bien ?

[slambert]

Post by Road2Hells
je ne vois pas bien où est le probleme ?
en quoi $_POST[mavariable] est moins dangeureux que $mavariable

Avec $_POST[mavariable] , tu sais que ta variable provient d'un formulaire
ou tout du moins d'un envois POST.



Avec $mavariable, tu n'en sais rien.



Suivant ta façon de développer, cela peut ouvrir le champ à des failles
potentielles. Avec les globales désactivées, tu es obligé de vérifier la
provenance du contenu de tes variables. Et soit dit en passant, tu es obligé
de comprendre les concepts.



Or, la tendance est d'obliger le débutant à comprendre les concepts, et
désactiver les globales y contribue.



N'oublions pas que la techno PHP a souffert par le passé d'une image
d'amateurisme et de faille de sécurité. Sachant que la plupart de ces
failles provenaient de programmations mauvaises et non pas du langage lui
même, décision avait été prise de resserrer les boulons.

Post by Road2Hells
j'ai loupé un épisode ou bien ?

ou bien :)



Si tu es sur de toi, et que tu as le niveau pour pallier à la configuration
par défaut, alors c'est que tu es près à assumer ta responsabilité en cas de
soucis et de petits malins qui joue avec les url pour tenter de te
truander....



Stef

[Road2Hells]

Post by slambert

Post by Road2Hells
je ne vois pas bien où est le probleme ?
en quoi $_POST[mavariable] est moins dangeureux que $mavariable

Avec $_POST[mavariable] , tu sais que ta variable provient d'un
formulaire ou tout du moins d'un envois POST.
Avec $mavariable, tu n'en sais rien.

oui mais tout dépend ce que tu fais de ta variable derrière

Post by slambert
Or, la tendance est d'obliger le débutant à comprendre les concepts,
et désactiver les globales y contribue.

merci j'aime mieux ton explication que celle qui consiste à dire : "il ne
faut pas"
pourquoi ?
parce que !

Post by slambert

Post by Road2Hells
j'ai loupé un épisode ou bien ?

ou bien :)
Si tu es sur de toi, et que tu as le niveau pour pallier à la
configuration par défaut, alors c'est que tu es près à assumer ta
responsabilité en cas de soucis et de petits malins qui joue avec les
url pour tenter de te truander....

de toutes facons je ne les utilise plus, c'était juste pour mettre vite
fais à jour un code que j'avais pondu il y a longtemps du temps ou c'éatit
à On :-)

mais comme quoi, quand c'est bien expliqué, ça va tout de suite mieux !

merci d'avoir perdu du temps pour ma culture générale et darwin ne s'en
portera que mieux ;-)

[Olivier Miakinen]

Bonjour,

Post by Road2Hells
je ne vois pas bien où est le probleme ?
en quoi $_POST[mavariable] est moins dangeureux que $mavariable

Tout d'abord, je suppose que tu compares $mavariable non pas avec
$_POST[mavariable], mais avec $_POST['mavariable'].

Cela étant dit, $mavariable n'est en rien plus dangereux que
$_POST['mavariable'], à partir du moment où toutes tes variables
sont initialisées avant d'être utilisées. Le danger pourrait venir
d'une variable que tu aurais oublié d'initialiser, et qui aurait un
effet non prévu au cas où l'initialisation se ferait par une valeur
venant de l'extérieur.

Bien entendu, si tu connais ton code par cœur et que tu as vérifié que
chaque variable était bien initialisée, alors il n'y a aucun problème.

D'un autre côté, si tu connais vraiment ton code par cœur, alors tu
devrais savoir quelles sont les variables dont tu as besoin qu'elles
soient fournies par l'appelant dans $_POST, et donc tu pourrais te
contenter de n'extraire *que* ces variables-là. Le fait que tu veuilles
faire une boucle pour extraire tout ce qu'on te passe sans distinction
pourrait nous faire douter que tu connaisses ton code si bien que ça, et
que tu sois assuré d'avoir vraiment initialisé tout ce qui ne doit pas
venir de l'extérieur.

En outre, puisque tu fais une boucle automatique, je ne vois pas bien
comment tu peux t'assurer que telle variable est bien un entier compris
entre 5 et 20, que telle autre est une chaîne qui ne peut valoir que
"admin" ou "guest", que telle autre encore est un chemin d'accès qui
pointe bien vers un fichier dans ton répertoire "./images" et pas vers
un fichier système à grands coups de "../../../..", etc.

Bref... en résumé, si tu maîtrises ton code, alors ce que tu veux faire
n'est peut-être pas dangereux mais il est certainement inutile, tandis
que si tu ne maîtrises pas ton code il est potentiellement dangereux.

[Thierry]

Post by Road2Hells
en quoi $_POST[mavariable] est moins dangeureux que $mavariable
j'ai loupé un épisode ou bien ?

Regarde :
http://www.manuelphp.com/php/security.globals.php
et l'exemple court est partlant:

<?php
// $authorized = true uniquement si l'utilisateur est identifié
if (authenticated_user()) {
$authorized = true;
}

// Comme nous n'avons pas initialisé $authorized avec false, cette dernière
// peut être définie via register_globals, comme avec l'URL GET
auth.php?authorized=1
// Tout le monde peut facilement être reconnu comme identifié!
if ($authorized) {
include "/donnees/critiques/data.php";
}
?>

[Road2Hells]

Post by Thierry

Post by Road2Hells
en quoi $_POST[mavariable] est moins dangeureux que $mavariable
j'ai loupé un épisode ou bien ?

http://www.manuelphp.com/php/security.globals.php
<?php
// $authorized = true uniquement si l'utilisateur est identifié
if (authenticated_user()) {
$authorized = true;
}
// Comme nous n'avons pas initialisé $authorized avec false, cette
dernière // peut être définie via register_globals, comme avec l'URL
GET auth.php?authorized=1
// Tout le monde peut facilement être reconnu comme identifié!
if ($authorized) {
include "/donnees/critiques/data.php";
}
?>

ok mais comme répondu dans un autre message, mon passage en premier lieu
par le language perl et l'utilisation du langage perl avec le use strict
m'a obligé à prendre l'habitude de déclarer toutes mes variables en début
de programme avec les valeurs par défaut à "off" ou "no" ou "-1"

donc l'utilisation en plus du (!isset($variable)) évite l'écrasement
accidentel

[slambert]

Post by Road2Hells
ok mais comme répondu dans un autre message, mon passage en premier lieu
par le language perl et l'utilisation du langage perl avec le use strict
m'a obligé à prendre l'habitude de déclarer toutes mes variables en début
de programme avec les valeurs par défaut à "off" ou "no" ou "-1"

C'est pas mal, ca.

Bon bien sur, on en est pas à typer les fonctions/variables et à tout
déclarer en début de script.

Il faudrait presque une option dans l'IDE qui permette d'automatiser cela :
toutes les variables utilisées dans le script se retrouveraient initilaisées
à vide en début de script, et il n'y aurait plus qu'à passer derrière pour
supprimer sauvagement les lignes des variables post/get/cookie utilisées.

Un IDE propose t il cette option/gadget à ce jour ?

Stef

[Olivier Miakinen]

toutes les variables utilisées dans le script se retrouveraient initialisées
à vide en début de script, et il n'y aurait plus qu'à passer derrière pour
supprimer sauvagement les lignes des variables post/get/cookie utilisées.

Ce genre de chose ne serait forcément que partiel, ne serait-ce qu'à
cause des « variables variables ».

Un IDE propose t il cette option/gadget à ce jour ?

Je passe.

[slambert]

Post by Olivier Miakinen
Ce genre de chose ne serait forcément que partiel, ne serait-ce qu'à
cause des « variables variables ».

Très bonne remarque.

Post by Olivier Miakinen

Post by slambert
Un IDE propose t il cette option/gadget à ce jour ?

Je passe.

Mais si voyons !

Je dis dans le micro a l'IDE : Sort moi les variables ne venant pas du web
et fait un unset() dessus en début de script. Et puis après, l'intelligence
artificielle du Zend framework, elle appelle ses petites marmottes internes
et toutes les variables sont bien placées en tête de script, avec
l'indentation, les commentaires... C'est que c'est intelligent, une
marmotte....

Bon ok, => []

Dzlé

N'empêche, on rigole, mais quand tu vois des trucs comme Celine de N. Ruiz,
un jour, ça se passera peut être comme cela.



Stef

[Patrick Mevzek]

Post by Road2Hells
y a t'il un autre moyen lorsque les variables globales sont à OFF dans le
php.ini?

Oui, l'horreur import_request_variables() que vous avez en gros recodée.
register_globals et cette dernière n'auraient jamais dû être inventé.
Vivement qu'elles disparaissent définitivement, en attendant de faire un
pas dans le bon sens c'est à dire l'exact contraire, comme le « taint
checking » en Perl.

[Road2Hells]

Post by Patrick Mevzek

Post by Road2Hells
y a t'il un autre moyen lorsque les variables globales sont à OFF
dans le php.ini?

Oui, l'horreur import_request_variables() que vous avez en gros
recodée. register_globals et cette dernière n'auraient jamais dû être
inventé. Vivement qu'elles disparaissent définitivement, en attendant
de faire un pas dans le bon sens c'est à dire l'exact contraire, comme
le « taint checking » en Perl.

contrairement à un peu tout ce que j'ai pu lire, je n'ai pas trop peur de
mon code vu que j'ai pris l'habitude en perl d'utiliser "use strict" et
par conséquent d'initaliser toutes mes variables par défaut.
Ce qui fait que mes programmes en php utilisent les mêmes principes.

le fait d'avoir ajouté le && (!isset à chaque fois me permet aussi d'éviter
d'écraser une variable non prévu dans le formulaire !

m'enfin ensuite tout n'est qu'une histoire d'appréciation personnelle.

merci pour toutes ces réponses constructives qui m'ont en fait rassuré :-)