Ca fait au moins deux ans que je n'ai pas touché à php. On me commande
un site en m'imposant php. Ok !
Pour ce faire, j'installe EasyPHP 1.7, j'ai été très content lors de mon
précédent site en php. OK !
Je fais tout classe bien. Je commence par un formulaire simple pour me
remettre dans le bain, de type :
un login et un mot de passe avec un bouton submit.
le champs login est
<input name="login" type="text" id="login" size="50">
le champs password est
<input name="passwd" type="password" id="passwd">
Mon problème est que je n'arrive pas à récupérer les variables $login et
$passwd dans la page d'action du formulaire (checklogin.php).
Même quand j'écris
http://localhost/monsite/checklogin.php?login=bidon&passwd=grosbidon
J'ai un message d'erreur me disant que les variables $login et $passwd
ne sont pas définie !!
Même un lien type <a href="mapage.php?id=1">clickme</a> ne fonctionne
pas, alors que l'administration d'Easy PHP fonctionne suivant ce
principe et lui fonctionne très bien!!!
Pleeaaase ! Je ne comprends pas ce qu'il se passe.
Amicalement et merci d'avance
Regis
PS: un indice peut être mon répertoire perso s'appelle "Régis" et Apache
2 m'a causé beaucoup de fils à retordre sur un autre site écrit avec
mod_python.
Surtout pas, malheureux ! Voir <http://www.php.net/manual/fr/security.globals.php>.
Une fois deplus, je m'insurge violemment contre cette désinformation et mauvaise méthode. Mettre register_globals à On n'a jamais été une faille de sécurité en soit, c'est un problème d'interface chaise-clavier.
La vraie faille de sécurité, c'est de ne pas initialiser ses variables.
La vraie correction de cette faille de sécurité, c'est donc d'initialiser ses variables. Le jour où du code porc-grammé sans initialisations tourne sur une plateforme où justement on est en register_globals=On, c'est la cata.
Et de toutes façons, il faut filtrer systématiquement ses variables en entrée pour éviter les injections SQL(avec ou sans magic quotes) et les xss.
a++; JG
onjour,
Surtout pas, malheureux !
Voir <http://www.php.net/manual/fr/security.globals.php>.
Une fois deplus, je m'insurge violemment contre cette désinformation et
mauvaise méthode. Mettre register_globals à On n'a jamais été une faille
de sécurité en soit, c'est un problème d'interface chaise-clavier.
La vraie faille de sécurité, c'est de ne pas initialiser ses variables.
La vraie correction de cette faille de sécurité, c'est donc d'initialiser
ses variables. Le jour où du code porc-grammé sans initialisations tourne
sur une plateforme où justement on est en register_globals=On, c'est la
cata.
Et de toutes façons, il faut filtrer systématiquement ses variables en
entrée pour éviter les injections SQL(avec ou sans magic quotes) et les
xss.
Surtout pas, malheureux ! Voir <http://www.php.net/manual/fr/security.globals.php>.
Une fois deplus, je m'insurge violemment contre cette désinformation et mauvaise méthode. Mettre register_globals à On n'a jamais été une faille de sécurité en soit, c'est un problème d'interface chaise-clavier.
La vraie faille de sécurité, c'est de ne pas initialiser ses variables.
La vraie correction de cette faille de sécurité, c'est donc d'initialiser ses variables. Le jour où du code porc-grammé sans initialisations tourne sur une plateforme où justement on est en register_globals=On, c'est la cata.
Et de toutes façons, il faut filtrer systématiquement ses variables en entrée pour éviter les injections SQL(avec ou sans magic quotes) et les xss.
a++; JG
WebRod
exact :( Faut dire que j'avais fait ca dans l'urgence aprés avoir déplacé un site en production d'un hébergeur bidon vers ovh. Je ne me suis pas rendu compte avant du problème car il ne se posait que sur certaines pages, du coup j'ai pondu ce truc bizarre.
C'est vrai qu'un unset est beaucoup plus approprié!!
Rod
exact :(
Faut dire que j'avais fait ca dans l'urgence aprés avoir déplacé un site en
production d'un hébergeur bidon vers ovh.
Je ne me suis pas rendu compte avant du problème car il ne se posait que sur
certaines pages, du coup j'ai pondu ce truc bizarre.
C'est vrai qu'un unset est beaucoup plus approprié!!
exact :( Faut dire que j'avais fait ca dans l'urgence aprés avoir déplacé un site en production d'un hébergeur bidon vers ovh. Je ne me suis pas rendu compte avant du problème car il ne se posait que sur certaines pages, du coup j'ai pondu ce truc bizarre.
C'est vrai qu'un unset est beaucoup plus approprié!!
Rod
Olivier Miakinen
Le 28/01/2005 17:14, John GALLET me répondait :
Surtout pas, malheureux ! Voir <http://www.php.net/manual/fr/security.globals.php>.
Une fois deplus, je m'insurge violemment contre cette désinformation et mauvaise méthode. Mettre register_globals à On n'a jamais été une faille de sécurité en soit, c'est un problème d'interface chaise-clavier.
La vraie faille de sécurité, c'est de ne pas initialiser ses variables.
La vraie correction de cette faille de sécurité, c'est donc d'initialiser ses variables. Le jour où du code porc-grammé sans initialisations tourne sur une plateforme où justement on est en register_globals=On, c'est la cata.
Rien à dire, tu as raison.
-- Olivier Miakinen Et je repars la queue basse, jurant -- mais un peu tard -- qu'on ne m'y prendrait plus.
Le 28/01/2005 17:14, John GALLET me répondait :
Surtout pas, malheureux !
Voir <http://www.php.net/manual/fr/security.globals.php>.
Une fois deplus, je m'insurge violemment contre cette désinformation et
mauvaise méthode. Mettre register_globals à On n'a jamais été une faille
de sécurité en soit, c'est un problème d'interface chaise-clavier.
La vraie faille de sécurité, c'est de ne pas initialiser ses variables.
La vraie correction de cette faille de sécurité, c'est donc d'initialiser
ses variables. Le jour où du code porc-grammé sans initialisations tourne
sur une plateforme où justement on est en register_globals=On, c'est la
cata.
Rien à dire, tu as raison.
--
Olivier Miakinen
Et je repars la queue basse, jurant -- mais un peu tard -- qu'on ne m'y
prendrait plus.
Surtout pas, malheureux ! Voir <http://www.php.net/manual/fr/security.globals.php>.
Une fois deplus, je m'insurge violemment contre cette désinformation et mauvaise méthode. Mettre register_globals à On n'a jamais été une faille de sécurité en soit, c'est un problème d'interface chaise-clavier.
La vraie faille de sécurité, c'est de ne pas initialiser ses variables.
La vraie correction de cette faille de sécurité, c'est donc d'initialiser ses variables. Le jour où du code porc-grammé sans initialisations tourne sur une plateforme où justement on est en register_globals=On, c'est la cata.
Rien à dire, tu as raison.
-- Olivier Miakinen Et je repars la queue basse, jurant -- mais un peu tard -- qu'on ne m'y prendrait plus.
WebRod
Une fois deplus, je m'insurge violemment contre cette désinformation et mauvaise méthode. Mettre register_globals à On n'a jamais été une faille de sécurité en soit, c'est un problème d'interface chaise-clavier.
La vraie faille de sécurité, c'est de ne pas initialiser ses variables.
ton point de vue est juste mais un peu poussé.
Si l'on suit ton raisonnement, on supprime toutes les mesures de sécurite qui peuvent être évitées par du développement. Non seulement dans php, mais aussi dans les bases de données. Plus besoin d'avoir de champs du type "unique" puisqu'il suffit que le développeur vérifie l'unicité avant de créer l'enregistrement. Etc etc, les exemples tant au niveau php, bd que système sont nombreux.
"Mettre register_globals à On n'a jamais été une faille " non, mais il en ouvre une. Mettre register_globals à Off offre une sécurité supplémentaire
Par contre je suis d'accord avec tous le reste, il y a des règles de codage à respecter (pas seulement pour des raisons de sécurité d'ailleurs).
Rod
Une fois deplus, je m'insurge violemment contre cette désinformation et
mauvaise méthode. Mettre register_globals à On n'a jamais été une faille
de sécurité en soit, c'est un problème d'interface chaise-clavier.
La vraie faille de sécurité, c'est de ne pas initialiser ses variables.
ton point de vue est juste mais un peu poussé.
Si l'on suit ton raisonnement, on supprime toutes les mesures de sécurite
qui peuvent être évitées par du développement.
Non seulement dans php, mais aussi dans les bases de données.
Plus besoin d'avoir de champs du type "unique" puisqu'il suffit que le
développeur vérifie l'unicité avant de créer l'enregistrement.
Etc etc, les exemples tant au niveau php, bd que système sont nombreux.
"Mettre register_globals à On n'a jamais été une faille " non, mais il en
ouvre une.
Mettre register_globals à Off offre une sécurité supplémentaire
Par contre je suis d'accord avec tous le reste, il y a des règles de codage
à respecter (pas seulement pour des raisons de sécurité d'ailleurs).
Une fois deplus, je m'insurge violemment contre cette désinformation et mauvaise méthode. Mettre register_globals à On n'a jamais été une faille de sécurité en soit, c'est un problème d'interface chaise-clavier.
La vraie faille de sécurité, c'est de ne pas initialiser ses variables.
ton point de vue est juste mais un peu poussé.
Si l'on suit ton raisonnement, on supprime toutes les mesures de sécurite qui peuvent être évitées par du développement. Non seulement dans php, mais aussi dans les bases de données. Plus besoin d'avoir de champs du type "unique" puisqu'il suffit que le développeur vérifie l'unicité avant de créer l'enregistrement. Etc etc, les exemples tant au niveau php, bd que système sont nombreux.
"Mettre register_globals à On n'a jamais été une faille " non, mais il en ouvre une. Mettre register_globals à Off offre une sécurité supplémentaire
Par contre je suis d'accord avec tous le reste, il y a des règles de codage à respecter (pas seulement pour des raisons de sécurité d'ailleurs).
Rod
Guillaume Bouchard
Mettre register_globals à On n'a jamais été une faille de sécurité en soit, c'est un problème d'interface chaise-clavier.
La vraie faille de sécurité, c'est de ne pas initialiser ses variables.
Si l'on suit ton raisonnement, on supprime toutes les mesures de sécurite
qui peuvent être évitées par du développement.
Plus besoin d'avoir de champs du type "unique" puisqu'il suffit que le développeur vérifie l'unicité avant de créer l'enregistrement.
Les champs de types uniques sont une fonctionalité visant à justement ne pas avoir à verifié l'unicité avant en s'embrarassant de transactions ou de lock sur les tables.
De plus les champs uniques sont trés utiles dans les indexes. Donc il ne s'agit pas seulement d'une fonctionalité de sécurité, mais d'une fonctionalité d'utilisation. On ne va pas enlever la fonction quick_sort() sous pretexe que l'on peux faire là meme chose en 15 lignes ?
"Mettre register_globals à On n'a jamais été une faille " non, mais il en ouvre une. Mettre register_globals à Off offre une sécurité supplémentaire
Dans ce raisonement, oui? Le gros problème que souleve john c'est que en se croyant à l'abris de la faille, on se met à coder comme un goret.
-- Guillaume.
Mettre register_globals à On n'a jamais été une faille
de sécurité en soit, c'est un problème d'interface chaise-clavier.
La vraie faille de sécurité, c'est de ne pas initialiser ses variables.
Si l'on suit ton raisonnement, on supprime toutes les mesures de sécurite
qui peuvent être évitées par du développement.
Plus besoin d'avoir de champs du type "unique" puisqu'il suffit que le
développeur vérifie l'unicité avant de créer l'enregistrement.
Les champs de types uniques sont une fonctionalité visant à justement ne
pas avoir à verifié l'unicité avant en s'embrarassant de transactions ou
de lock sur les tables.
De plus les champs uniques sont trés utiles dans les indexes. Donc il ne
s'agit pas seulement d'une fonctionalité de sécurité, mais d'une
fonctionalité d'utilisation. On ne va pas enlever la fonction
quick_sort() sous pretexe que l'on peux faire là meme chose en 15 lignes ?
"Mettre register_globals à On n'a jamais été une faille " non, mais il en
ouvre une.
Mettre register_globals à Off offre une sécurité supplémentaire
Dans ce raisonement, oui? Le gros problème que souleve john c'est que en
se croyant à l'abris de la faille, on se met à coder comme un goret.
Mettre register_globals à On n'a jamais été une faille de sécurité en soit, c'est un problème d'interface chaise-clavier.
La vraie faille de sécurité, c'est de ne pas initialiser ses variables.
Si l'on suit ton raisonnement, on supprime toutes les mesures de sécurite
qui peuvent être évitées par du développement.
Plus besoin d'avoir de champs du type "unique" puisqu'il suffit que le développeur vérifie l'unicité avant de créer l'enregistrement.
Les champs de types uniques sont une fonctionalité visant à justement ne pas avoir à verifié l'unicité avant en s'embrarassant de transactions ou de lock sur les tables.
De plus les champs uniques sont trés utiles dans les indexes. Donc il ne s'agit pas seulement d'une fonctionalité de sécurité, mais d'une fonctionalité d'utilisation. On ne va pas enlever la fonction quick_sort() sous pretexe que l'on peux faire là meme chose en 15 lignes ?
"Mettre register_globals à On n'a jamais été une faille " non, mais il en ouvre une. Mettre register_globals à Off offre une sécurité supplémentaire
Dans ce raisonement, oui? Le gros problème que souleve john c'est que en se croyant à l'abris de la faille, on se met à coder comme un goret.
-- Guillaume.
John GALLET
Bonjour,
La vraie faille de sécurité, c'est de ne pas initialiser ses variables. ton point de vue est juste mais un peu poussé.
Nullement.
Si l'on suit ton raisonnement, on supprime toutes les mesures de sécurite qui peuvent être évitées par du développement. Tu n'as pas compris ce que je veux dire||je me suis mal expliqué.
Non seulement dans php, mais aussi dans les bases de données. Rien à voir avec la choucroute.
Plus besoin d'avoir de champs du type "unique" puisqu'il suffit que le développeur vérifie l'unicité avant de créer l'enregistrement.
1) ce n'est pas de la sécurité, c'est de l'intégrité des données. 2) depuis le nombre d'années que je me tue à répéter qu'il ne faut pas foutre des auto-increment partout et que tout autoincr DOIT être accompagné d'une contrainte UNIQUE sur la VRAIE PK de la table, tu as très mal choisi ton exemple :-)
Oui, il est débile de faire d'abord un SELECT pour savoir si on a déjà l'enregistrement et faire un INSERT s'il existe pas et un UPDATE s'il existe, parce que la base de données est PREVUE POUR LE GERER.
"Mettre register_globals à On n'a jamais été une faille " non, mais il en ouvre une. Oui.
Mettre register_globals à Off offre une sécurité supplémentaire Oui.
Mais coder en admettant qu'on aura toujours register_globals à Off est une faille majeure.
Il en va de même avec les fameuses magic_quotes. Partir du principe qu'on aura toujours l'ajout "automagically" des caractères d'échappement des " et ' vers le sgbd est une connerie sans nom. Il faut le vérifier et le faire si le système ne l'a pas fait ça tombe bien, get_magic_quotes_gpc() renvoie l'information...)
Le jour où le php group, dans son infinie sagesse, se décidera enfin à interdire totalement register_globals à On et le fera disparaître des paramètres de php.ini, modulo le temps (au moins 2 à 3 ans) qu'il faudra pour que les anciennes configurations se mettent à jour, alors on pourra dire "la faille potentielle a définitivement été résolue par la plateforme php". D'ici là, tout développeur qui n'initialise pas ses variables correctement s'expose à la faille.
a++; JG
Bonjour,
La vraie faille de sécurité, c'est de ne pas initialiser ses variables.
ton point de vue est juste mais un peu poussé.
Nullement.
Si l'on suit ton raisonnement, on supprime toutes les mesures de sécurite
qui peuvent être évitées par du développement.
Tu n'as pas compris ce que je veux dire||je me suis mal expliqué.
Non seulement dans php, mais aussi dans les bases de données.
Rien à voir avec la choucroute.
Plus besoin d'avoir de champs du type "unique" puisqu'il suffit que le
développeur vérifie l'unicité avant de créer l'enregistrement.
1) ce n'est pas de la sécurité, c'est de l'intégrité des données.
2) depuis le nombre d'années que je me tue à répéter qu'il ne faut pas
foutre des auto-increment partout et que tout autoincr DOIT être
accompagné d'une contrainte UNIQUE sur la VRAIE PK de la table, tu as très
mal choisi ton exemple :-)
Oui, il est débile de faire d'abord un SELECT pour savoir si on a déjà
l'enregistrement et faire un INSERT s'il existe pas et un UPDATE s'il
existe, parce que la base de données est PREVUE POUR LE GERER.
"Mettre register_globals à On n'a jamais été une faille " non, mais il en
ouvre une.
Oui.
Mettre register_globals à Off offre une sécurité supplémentaire
Oui.
Mais coder en admettant qu'on aura toujours register_globals à Off est une
faille majeure.
Il en va de même avec les fameuses magic_quotes. Partir du principe qu'on
aura toujours l'ajout "automagically" des caractères d'échappement des "
et ' vers le sgbd est une connerie sans nom. Il faut le vérifier et le
faire si le système ne l'a pas fait ça tombe bien, get_magic_quotes_gpc()
renvoie l'information...)
Le jour où le php group, dans son infinie sagesse, se décidera enfin à
interdire totalement register_globals à On et le fera disparaître des
paramètres de php.ini, modulo le temps (au moins 2 à 3 ans) qu'il faudra
pour que les anciennes configurations se mettent à jour, alors on pourra
dire "la faille potentielle a définitivement été résolue par la plateforme
php". D'ici là, tout développeur qui n'initialise pas ses variables
correctement s'expose à la faille.
La vraie faille de sécurité, c'est de ne pas initialiser ses variables. ton point de vue est juste mais un peu poussé.
Nullement.
Si l'on suit ton raisonnement, on supprime toutes les mesures de sécurite qui peuvent être évitées par du développement. Tu n'as pas compris ce que je veux dire||je me suis mal expliqué.
Non seulement dans php, mais aussi dans les bases de données. Rien à voir avec la choucroute.
Plus besoin d'avoir de champs du type "unique" puisqu'il suffit que le développeur vérifie l'unicité avant de créer l'enregistrement.
1) ce n'est pas de la sécurité, c'est de l'intégrité des données. 2) depuis le nombre d'années que je me tue à répéter qu'il ne faut pas foutre des auto-increment partout et que tout autoincr DOIT être accompagné d'une contrainte UNIQUE sur la VRAIE PK de la table, tu as très mal choisi ton exemple :-)
Oui, il est débile de faire d'abord un SELECT pour savoir si on a déjà l'enregistrement et faire un INSERT s'il existe pas et un UPDATE s'il existe, parce que la base de données est PREVUE POUR LE GERER.
"Mettre register_globals à On n'a jamais été une faille " non, mais il en ouvre une. Oui.
Mettre register_globals à Off offre une sécurité supplémentaire Oui.
Mais coder en admettant qu'on aura toujours register_globals à Off est une faille majeure.
Il en va de même avec les fameuses magic_quotes. Partir du principe qu'on aura toujours l'ajout "automagically" des caractères d'échappement des " et ' vers le sgbd est une connerie sans nom. Il faut le vérifier et le faire si le système ne l'a pas fait ça tombe bien, get_magic_quotes_gpc() renvoie l'information...)
Le jour où le php group, dans son infinie sagesse, se décidera enfin à interdire totalement register_globals à On et le fera disparaître des paramètres de php.ini, modulo le temps (au moins 2 à 3 ans) qu'il faudra pour que les anciennes configurations se mettent à jour, alors on pourra dire "la faille potentielle a définitivement été résolue par la plateforme php". D'ici là, tout développeur qui n'initialise pas ses variables correctement s'expose à la faille.
a++; JG
John GALLET
Et le tour est joué, le code devient plus propre!!
Non, pas plus propre : insensible à l'injection de variables php. Mais la méthode est en effet intéressante en pis-aller.
JG
Et le tour est joué, le code devient plus propre!!
Non, pas plus propre : insensible à l'injection de variables php. Mais la
méthode est en effet intéressante en pis-aller.
Et le tour est joué, le code devient plus propre!!
Non, pas plus propre : insensible à l'injection de variables php. Mais la méthode est en effet intéressante en pis-aller.
JG
WebRod
tu as très mal choisi ton exemple :-) Exact, exemple assez moyen :(
Oui, il est débile de faire d'abord un SELECT pour savoir si on a déjà l'enregistrement et faire un INSERT s'il existe pas et un UPDATE s'il existe, parce que la base de données est PREVUE POUR LE GERER. Tout à fait, c'est bien pour cela que j'ai choisi cet exemple ;)
On est d'accord qu'il est inutile de faire quelquechose dans la bd si celle ci est prévue pour le gérer. Pourquoi php ne pourrait -il pas gérer une partie de la sécurité? Et si t'elle était le cas, pourquoi rajouter un niveau de sécurité au niveau du code pour sécurise PLUS quelque chose qui l'est déjà? (attention je parle de la faille qui consiste à initialiser des variables en les passant en paramètres, pas de la faille qui consiste à initialiser des champs de formulaires avec des valeurs qui vont "tuer" un script sql!!)
Le jour où le php group, dans son infinie sagesse, se décidera enfin à interdire totalement register_globals à On et le fera disparaître des paramètres de php.ini, modulo le temps (au moins 2 à 3 ans) qu'il faudra pour que les anciennes configurations se mettent à jour, alors on pourra dire "la faille potentielle a définitivement été résolue par la plateforme php". TOUT A FAIT! C'est ce que je voulais dire, le flag à On est une grosse
connerie qui oblige beaucoup trop à sécuriser ses scripts. Le flag à Off, en offrant plus de "sécurité" permet de lacher du lest car un type ne peut plus initialiser tes variables en les ajoutants en paramètres (bien sur, on pouvait éviter cela en suivant tes recommendations et initialisant les variables au début de chaque script, mais justement, ce que je veux dire, c'est que cela n'est plus utile si c'est à OFF comme pour l'exemple de la base de données). De toute façon, ce flag à ON etait une aberration. Quel idée d'aller initialiser des variables!!
D'ici là, tout développeur qui n'initialise pas ses variables correctement s'expose à la faille. C'est cà, pour le moment c'est indispensable. (à moins d'utiliser le petit
script que je donnais plus haut et qui annule l'initialisation des variables)
Rod
tu as très
mal choisi ton exemple :-)
Exact, exemple assez moyen :(
Oui, il est débile de faire d'abord un SELECT pour savoir si on a déjà
l'enregistrement et faire un INSERT s'il existe pas et un UPDATE s'il
existe, parce que la base de données est PREVUE POUR LE GERER.
Tout à fait, c'est bien pour cela que j'ai choisi cet exemple ;)
On est d'accord qu'il est inutile de faire quelquechose dans la bd si celle
ci est prévue pour le gérer.
Pourquoi php ne pourrait -il pas gérer une partie de la sécurité?
Et si t'elle était le cas, pourquoi rajouter un niveau de sécurité au niveau
du code pour sécurise PLUS quelque chose qui l'est déjà?
(attention je parle de la faille qui consiste à initialiser des variables en
les passant en paramètres, pas de la faille qui consiste à initialiser des
champs de formulaires avec des valeurs qui vont "tuer" un script sql!!)
Le jour où le php group, dans son infinie sagesse, se décidera enfin à
interdire totalement register_globals à On et le fera disparaître des
paramètres de php.ini, modulo le temps (au moins 2 à 3 ans) qu'il faudra
pour que les anciennes configurations se mettent à jour, alors on pourra
dire "la faille potentielle a définitivement été résolue par la plateforme
php".
TOUT A FAIT! C'est ce que je voulais dire, le flag à On est une grosse
connerie qui oblige beaucoup trop à sécuriser ses scripts.
Le flag à Off, en offrant plus de "sécurité" permet de lacher du lest car un
type ne peut plus initialiser tes variables en les ajoutants en paramètres
(bien sur, on pouvait éviter cela en suivant tes recommendations et
initialisant les variables au début de chaque script, mais justement, ce que
je veux dire, c'est que cela n'est plus utile si c'est à OFF comme pour
l'exemple de la base de données).
De toute façon, ce flag à ON etait une aberration.
Quel idée d'aller initialiser des variables!!
D'ici là, tout développeur qui n'initialise pas ses variables
correctement s'expose à la faille.
C'est cà, pour le moment c'est indispensable. (à moins d'utiliser le petit
script que je donnais plus haut et qui annule l'initialisation des
variables)
tu as très mal choisi ton exemple :-) Exact, exemple assez moyen :(
Oui, il est débile de faire d'abord un SELECT pour savoir si on a déjà l'enregistrement et faire un INSERT s'il existe pas et un UPDATE s'il existe, parce que la base de données est PREVUE POUR LE GERER. Tout à fait, c'est bien pour cela que j'ai choisi cet exemple ;)
On est d'accord qu'il est inutile de faire quelquechose dans la bd si celle ci est prévue pour le gérer. Pourquoi php ne pourrait -il pas gérer une partie de la sécurité? Et si t'elle était le cas, pourquoi rajouter un niveau de sécurité au niveau du code pour sécurise PLUS quelque chose qui l'est déjà? (attention je parle de la faille qui consiste à initialiser des variables en les passant en paramètres, pas de la faille qui consiste à initialiser des champs de formulaires avec des valeurs qui vont "tuer" un script sql!!)
Le jour où le php group, dans son infinie sagesse, se décidera enfin à interdire totalement register_globals à On et le fera disparaître des paramètres de php.ini, modulo le temps (au moins 2 à 3 ans) qu'il faudra pour que les anciennes configurations se mettent à jour, alors on pourra dire "la faille potentielle a définitivement été résolue par la plateforme php". TOUT A FAIT! C'est ce que je voulais dire, le flag à On est une grosse
connerie qui oblige beaucoup trop à sécuriser ses scripts. Le flag à Off, en offrant plus de "sécurité" permet de lacher du lest car un type ne peut plus initialiser tes variables en les ajoutants en paramètres (bien sur, on pouvait éviter cela en suivant tes recommendations et initialisant les variables au début de chaque script, mais justement, ce que je veux dire, c'est que cela n'est plus utile si c'est à OFF comme pour l'exemple de la base de données). De toute façon, ce flag à ON etait une aberration. Quel idée d'aller initialiser des variables!!
D'ici là, tout développeur qui n'initialise pas ses variables correctement s'expose à la faille. C'est cà, pour le moment c'est indispensable. (à moins d'utiliser le petit
script que je donnais plus haut et qui annule l'initialisation des variables)
Rod
WebRod
Non, pas plus propre : insensible à l'injection de variables php. Mais la méthode est en effet intéressante en pis-aller.
JG
en effet je me suis mal exprimé. Le code n'est pas plus propre. Si l'on parle de code "propre", il est évident qu'il vaut mieux déclarer et initialiser TOUTES ses variables AVANT de les utiliser.
Je voulais en fait dire qu'il n'y avait plus de message d'erreur provoqués par l'initialisation sauvage des variables du fait du flag à ON!!
Rod
Non, pas plus propre : insensible à l'injection de variables php. Mais la
méthode est en effet intéressante en pis-aller.
JG
en effet je me suis mal exprimé.
Le code n'est pas plus propre.
Si l'on parle de code "propre", il est évident qu'il vaut mieux déclarer et
initialiser TOUTES ses variables AVANT de les utiliser.
Je voulais en fait dire qu'il n'y avait plus de message d'erreur provoqués
par l'initialisation sauvage des variables du fait du flag à ON!!
Non, pas plus propre : insensible à l'injection de variables php. Mais la méthode est en effet intéressante en pis-aller.
JG
en effet je me suis mal exprimé. Le code n'est pas plus propre. Si l'on parle de code "propre", il est évident qu'il vaut mieux déclarer et initialiser TOUTES ses variables AVANT de les utiliser.
Je voulais en fait dire qu'il n'y avait plus de message d'erreur provoqués par l'initialisation sauvage des variables du fait du flag à ON!!
Rod
WebRod
Plus besoin d'avoir de champs du type "unique" puisqu'il suffit que le développeur vérifie l'unicité avant de créer l'enregistrement.
Les champs de types uniques sont une fonctionalité visant à justement ne pas avoir à verifié l'unicité avant en s'embrarassant de transactions ou de lock sur les tables.
Euh...c'est ce que je viens de dire! Ces champs visent à ne pas vérifier l'unicité dans le script! Donc on ne vérifie dans le script pas puisque la base va le faire. Et ma phrase disait que "en suivant son raisonnement" alors on supprimmERAIT la fonctionnalité dans la base de donnée puisqu'il est "p-o-s-s-i-b-l-e" de le faire dans le script. Et que bien sur la réponse est NON!!! Il est bien plus logique que ce soit la base qui le fasse, et non le script!! Ne serait-ce que pour enlever du travail au développeur ;)
Tout ca pour dire que ce n'est pas parceque on peut ajouter un niveau de sécurité dans un script qu'on le fait!! Si une application tierce le fait à quoi bon?
De plus les champs uniques sont trés utiles dans les indexes. Donc il ne s'agit pas seulement d'une fonctionalité de sécurité, mais d'une fonctionalité d'utilisation.
Euh ca aussi je les sais, je n'ai pris cet exemple que dans sa partie "sécurité" volontairement pour qu'il colle à ce que je voulais expliquer...
On ne va pas enlever la fonction quick_sort() sous pretexe que l'on peux faire là meme chose en 15 lignes ?
Ben non, encore une fois c'est EXACTEMENT le but de mon message ;) Incroyable, apparemment je m'exprime si mal?????? C'est tout à fait ce que je voulais dire "On ne va pas enlever la fonction quick_sort() sous pretexe que l'on peux faire là meme chose en 15 lignes ?" Et donc, on ne vas pas enlever la possibilité de mettre le flag à OFF sous pretexte qu'on peut corriger le problème en initialisant ses variables! Ton exemple est trés bien choisi (apparemment mieux que le mien avec la bd).
"Mettre register_globals à On n'a jamais été une faille " non, mais il en ouvre une. Mettre register_globals à Off offre une sécurité supplémentaire
Dans ce raisonement, oui? Le gros problème que souleve john c'est que en se croyant à l'abris de la faille, on se met à coder comme un goret.
Oui, il faut toujours penser à coder proprement, c'est une vérité reconnue de tous. Mais il ne faut pas devenir paranoiac et éviter les redondances. Et pour reprendre mon exemple à la BD, on pourrait reprendre ta phrase et dire que se croyant à l'abri des failles on n'oublie de vérifier l'unicité des enregistrements. Si la BS le fait, pas besoin de le faire. Si le flag est à OFF, pas besoin d'en rajouter non plus....
Rod
Plus besoin d'avoir de champs du type "unique" puisqu'il suffit que le
développeur vérifie l'unicité avant de créer l'enregistrement.
Les champs de types uniques sont une fonctionalité visant à justement ne
pas avoir à verifié l'unicité avant en s'embrarassant de transactions ou
de lock sur les tables.
Euh...c'est ce que je viens de dire!
Ces champs visent à ne pas vérifier l'unicité dans le script!
Donc on ne vérifie dans le script pas puisque la base va le faire.
Et ma phrase disait que "en suivant son raisonnement" alors on supprimmERAIT
la fonctionnalité dans la base de donnée puisqu'il est "p-o-s-s-i-b-l-e" de
le faire dans le script.
Et que bien sur la réponse est NON!!!
Il est bien plus logique que ce soit la base qui le fasse, et non le
script!! Ne serait-ce que pour enlever du travail au développeur ;)
Tout ca pour dire que ce n'est pas parceque on peut ajouter un niveau de
sécurité dans un script qu'on le fait!! Si une application tierce le fait à
quoi bon?
De plus les champs uniques sont trés utiles dans les indexes. Donc il ne
s'agit pas seulement d'une fonctionalité de sécurité, mais d'une
fonctionalité d'utilisation.
Euh ca aussi je les sais, je n'ai pris cet exemple que dans sa partie
"sécurité" volontairement pour qu'il colle à ce que je voulais expliquer...
On ne va pas enlever la fonction quick_sort() sous pretexe que l'on peux
faire là meme chose en 15 lignes ?
Ben non, encore une fois c'est EXACTEMENT le but de mon message ;)
Incroyable, apparemment je m'exprime si mal??????
C'est tout à fait ce que je voulais dire "On ne va pas enlever la fonction
quick_sort() sous pretexe que l'on peux faire là meme chose en 15 lignes ?"
Et donc, on ne vas pas enlever la possibilité de mettre le flag à OFF sous
pretexte qu'on peut corriger le problème en initialisant ses variables!
Ton exemple est trés bien choisi (apparemment mieux que le mien avec la bd).
"Mettre register_globals à On n'a jamais été une faille " non, mais il en
ouvre une.
Mettre register_globals à Off offre une sécurité supplémentaire
Dans ce raisonement, oui? Le gros problème que souleve john c'est que en
se croyant à l'abris de la faille, on se met à coder comme un goret.
Oui, il faut toujours penser à coder proprement, c'est une vérité reconnue
de tous. Mais il ne faut pas devenir paranoiac et éviter les redondances.
Et pour reprendre mon exemple à la BD, on pourrait reprendre ta phrase et
dire que se croyant à l'abri des failles on n'oublie de vérifier l'unicité
des enregistrements.
Si la BS le fait, pas besoin de le faire.
Si le flag est à OFF, pas besoin d'en rajouter non plus....
Plus besoin d'avoir de champs du type "unique" puisqu'il suffit que le développeur vérifie l'unicité avant de créer l'enregistrement.
Les champs de types uniques sont une fonctionalité visant à justement ne pas avoir à verifié l'unicité avant en s'embrarassant de transactions ou de lock sur les tables.
Euh...c'est ce que je viens de dire! Ces champs visent à ne pas vérifier l'unicité dans le script! Donc on ne vérifie dans le script pas puisque la base va le faire. Et ma phrase disait que "en suivant son raisonnement" alors on supprimmERAIT la fonctionnalité dans la base de donnée puisqu'il est "p-o-s-s-i-b-l-e" de le faire dans le script. Et que bien sur la réponse est NON!!! Il est bien plus logique que ce soit la base qui le fasse, et non le script!! Ne serait-ce que pour enlever du travail au développeur ;)
Tout ca pour dire que ce n'est pas parceque on peut ajouter un niveau de sécurité dans un script qu'on le fait!! Si une application tierce le fait à quoi bon?
De plus les champs uniques sont trés utiles dans les indexes. Donc il ne s'agit pas seulement d'une fonctionalité de sécurité, mais d'une fonctionalité d'utilisation.
Euh ca aussi je les sais, je n'ai pris cet exemple que dans sa partie "sécurité" volontairement pour qu'il colle à ce que je voulais expliquer...
On ne va pas enlever la fonction quick_sort() sous pretexe que l'on peux faire là meme chose en 15 lignes ?
Ben non, encore une fois c'est EXACTEMENT le but de mon message ;) Incroyable, apparemment je m'exprime si mal?????? C'est tout à fait ce que je voulais dire "On ne va pas enlever la fonction quick_sort() sous pretexe que l'on peux faire là meme chose en 15 lignes ?" Et donc, on ne vas pas enlever la possibilité de mettre le flag à OFF sous pretexte qu'on peut corriger le problème en initialisant ses variables! Ton exemple est trés bien choisi (apparemment mieux que le mien avec la bd).
"Mettre register_globals à On n'a jamais été une faille " non, mais il en ouvre une. Mettre register_globals à Off offre une sécurité supplémentaire
Dans ce raisonement, oui? Le gros problème que souleve john c'est que en se croyant à l'abris de la faille, on se met à coder comme un goret.
Oui, il faut toujours penser à coder proprement, c'est une vérité reconnue de tous. Mais il ne faut pas devenir paranoiac et éviter les redondances. Et pour reprendre mon exemple à la BD, on pourrait reprendre ta phrase et dire que se croyant à l'abri des failles on n'oublie de vérifier l'unicité des enregistrements. Si la BS le fait, pas besoin de le faire. Si le flag est à OFF, pas besoin d'en rajouter non plus....
