question basique sur php/apache

J'ai un intranet sous LAMP. (apache 2 php 4)
j'ai register_globals à on (il parrait que c'est mal, mais j'ai pas
compris en quoi dans mon cas, même après avoir lu
http://fr.php.net/register_globals)

Si tu initialises toujours toutes tes variables avant de les utiliser,
il n'y a pas grand risque à avoir register_globals à on. Il suffit de
bien faire attention à ce qu'on fait.

Cela dit, c'est vrai que l'avoir à off permet de se protéger contre un
éventuel oubli (mais tester ses scripts avec le niveau de traces maximal
devrait suffire).

y a t-il un risque que des variables se mélangent entre 2 utilisateurs
qui executent la même page php avec des arguments différents ?

Non, aucun. De même que si c'est un seul utilisateur qui appelle deux
fois la page, d'ailleurs.

La portée des variable est bien limitée à l'execution du script ?

Oui pour les variables globales. Et les variables locales sont encore
plus limitées (à l'intérieur d'une fonction dans une instance du script).


--
Olivier Miakinen
Troll du plus sage chez les conviviaux : le nouveau venu, avec
son clan, s'infiltre dans les groupes de nouvelles. (3 c.)

Bonjour,

j'ai register_globals à on (il parrait que c'est mal, mais j'ai pas
compris en quoi
Ca permet à des attaquants de faire de l'injection de variables si le

développeur ne code pas correctement.

y a t-il un risque que des variables se mélangent entre 2 utilisateurs
qui executent la même page php avec des arguments différents ?
Nullement. Faire un coup de google sur 'injection de variable'/'variable

injection' ou regarder le chapitre correspondant sur
www.saphirtech.com/securite.html

En revanche, il y a un risque à faire tourner des applications non
développées par toi, rien ne garanti qu'elles seront codées proprement.

Si tu n'as pas la main sur php.ini pour changer ce paramètre, utiliser
un .htaccess avec
php_flag register_globals 0
ça doit marcher modulo mes erreurs de syntaxe.

a++;
JG

Si tu n'as pas la main sur php.ini pour changer ce paramètre, utiliser
un .htaccess avec
php_flag register_globals 0

C'est super intéressant cette technique ! c'est dommage, tu n'en parle
pas dans don cour sur la sécurité... Ou peut-on trouver un récapitulatif
de tout ce que l'on peut mettre dans les .htaccess pour "changer" les
valeurs du php.ini ?
Cette technique fait-elle effet juste dans le répertoire du .htaccess,
ou de manière récursive dans tout ses sous répertoires ?

(Excusez moi, c'est un peut hors sujet par rapport au thème...)

un .htaccess avec
php_flag register_globals 0

C'est super intéressant cette technique ! c'est dommage, tu n'en parle
pas dans don cour sur la sécurité...
Ah oui, je l'ai mis dans le cours tout court au paragraphe 5.3 donc j'ai

oublié de faire une redite dans le document spécifique sécu. Bon, un
truc de plus dans la TODO.

Ou peut-on trouver un récapitulatif
de tout ce que l'on peut mettre dans les .htaccess pour "changer" les
valeurs du php.ini ?
http://fr2.php.net/manual/en/ini.php#ini.list

Pour les .htaccess, prendre les colonnes INI_ALL et INI_PER_DIR

Attention néanmoins, .htacess implique apache, ça ne marchera pas sous
IIS par exemple, et il faut que httpd.conf permette d'utiliser lesdits
.htaccess (AllowOverride).

Cette technique fait-elle effet juste dans le répertoire du .htaccess,
ou de manière récursive dans tout ses sous répertoires ?
Récursive, comme tous les .htaccess.

a++;
JG

Si tu n'as pas la main sur php.ini pour changer ce paramètre, utiliser
un .htaccess avec
php_flag register_globals 0
ça doit marcher modulo mes erreurs de syntaxe.

Ca ne suffit malheureusement pas. Il faut auditer le code PHP à la
recherche de import_request_variables() qui fait l'équivalent de
register_globals comme option de configuration.

--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>

Bonjour,

Si tu n'as pas la main sur php.ini pour changer ce paramètre, utiliser
un .htaccess avec
php_flag register_globals 0
ça doit marcher modulo mes erreurs de syntaxe.

Ca ne suffit malheureusement pas. Il faut auditer le code PHP à la
recherche de import_request_variables() qui fait l'équivalent de
register_globals comme option de configuration.

Je ne le connaissais pas celui-ci, tiens, c'est du PHP>4.1. Encore un
truc d'une utilité douteuse (1) vu qu'un extract($_REQUEST/GET/POST)
faisait déjà un résultat assez similaire, à la portée des variables près
si j'ai bien compris la doc que j'ai lue en diagonale.

Enfin au moins c'est une démarche volontaire du développeur; ce qui à
mon sens est embêtant c'est d'avoir à l'heure actuelle un serveur en
register_globals à On si on ne maîtrise pas 100% du code qui se trouve
dessus(2) à cause de tous les scripts qui partent du principe idiot que
ce sera à Off. Donc forcer avec un .htaccess rectifiera ce problème là.

(1) moi ce que j'adore c'est
http://fr2.php.net/manual/en/function.date-sunset.php
Je me demande combien de caisses de bière ont été promises par l'auteur
de ce truc pour que ça rentre dans la distrib standard et surtout à qui
ça peut bien servir. Un gars qui vit dans une salle machine et qui voit
jamais la lumière du jour ? Quand PHP lui dit que le soleil est couché,
il va au dodo avec un VAX comme oreiller ?

(2) encore que, quand on lit bugtrack ou securityfocus, on se demande
vraiment si ce n'est pas dans tous les cas, en On ou Off, qu'il vaudrait
mieux maîtriser 100% du code... Que répondre à un client qui me demande
de lui créer un site marchand ? "téléchargez OsCommerce, je fais
l'assistance technique d'installation et vous vous débrouillez avec le
bidule mais c'est pas cher" ou "je vous développe tout le machin aux
petits oignons mais vous rajoutez un zéro à la facture" ?

a++;
JG

Enfin au moins c'est une démarche volontaire du développeur;

Oui mais il y a eu des cas historiques (PHPNuke) où l'on croyait être
sûr, parce que register_globals=off, mais le code fait
import_request_variables() et donc on héritait de tous les désavantages
en termes de sécurité... alors que, à cause de register_globals à off,
on se croyait en sécurité.

Bref, on avait le sentiment de sécurité, ce qui est la pire situation.

Et comme vous le notez, ce n'est pas forcément connu, donc des gens se
sont déjà faits avoir, et se feront encore avoir.

ce qui à
mon sens est embêtant c'est d'avoir à l'heure actuelle un serveur en
register_globals à On si on ne maîtrise pas 100% du code qui se trouve
dessus(2) à cause de tous les scripts qui partent du principe idiot que
ce sera à Off. Donc forcer avec un .htaccess rectifiera ce problème là.

Tout à fait d'accord, mais je pensais notamment au cas de figure où l'on
ne contrôle pas les applications : alors, register_globals à off ne
suffit pas, il faut auditer le code.

(1) moi ce que j'adore c'est
http://fr2.php.net/manual/en/function.date-sunset.php
Je me demande combien de caisses de bière ont été promises par l'auteur
de ce truc pour que ça rentre dans la distrib standard et surtout à qui
ça peut bien servir.

Ca devait être utile à un des développeurs de PHP.
Je ne sais comment PHP est développé dans son coeur, si les
développeurs se censurent les uns les autres ou si chacun fait ce qu'il
veut dans son coin.

(2) encore que, quand on lit bugtrack ou securityfocus, on se demande
vraiment si ce n'est pas dans tous les cas, en On ou Off, qu'il vaudrait
mieux maîtriser 100% du code...

Si, dans tous les cas, c'est mieux :-)
Mais en pratique, cela n'arrive jamais. Ou trop rarement.

--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>

Bonjour,

Bref, on avait le sentiment de sécurité, ce qui est la pire situation.
Absolument.

Et comme vous le notez, ce n'est pas forcément connu, donc des gens se
sont déjà faits avoir, et se feront encore avoir.
Moi le premier. Je vais de ce pas (non, d'ailleurs j'ai pas le teps,

mais j'y pense) l'ajouter dans la blacklist des fonctions à désactiver
via php.ini

Tout à fait d'accord, mais je pensais notamment au cas de figure où l'on
ne contrôle pas les applications : alors, register_globals à off ne
suffit pas, il faut auditer le code.
Je commence à croire qu'il faudrait le faire systématiquement dès qu'on

peut pour tout ce qui est PHP.

Ca devait être utile à un des développeurs de PHP.
Probablement. Ou alors il y en a un qui voulait avoir son adresse @php.net

Je ne sais comment PHP est développé dans son coeur, si les
développeurs se censurent les uns les autres ou si chacun fait ce qu'il
veut dans son coin.
Ce qui est à mon sens bizarre c'est que ce truc ait été intégré dans la

distribution *standard*, et pas dans pear ou pecl, où des choses bien
moins loufdingues ont été intégrées. Enfin bref.

Si, dans tous les cas, c'est mieux :-)
Mais en pratique, cela n'arrive jamais. Ou trop rarement.
Amen.

a++;
JG