Je recherche un hébèrgeur (éventuellement mutualisé) qui offre toutes les
fonctions et modules existants. Je pense entre autres à register_globals...
La solution d'un serveur dédié sera étudiée en dernier recours parce que
c'est coûteux.
dans (in) fr.reseaux.internet.hebergement, GPLHost ecrivait (wrote) :
Bonjour,
Entièrement d'accord, mais ça n'inclus pas le register_global qui peut et doit etre configurable (ce qui ne remet PAS en cause la sécurité global du service, mais juste la qualité du script qui a besoin de cette option, (j'insiste lourdement...)).
« 6.8 Utilisation des variables super-globales
L'une des évolutions les plus controversées de PHP a été le changement de valeur par défaut de la directive PHP register_globals , qui est passée de On à Off en PHP 4.2.0 . Beaucoup d'applications dépendaient de cette directive, et de nombreux programmeurs ne savaient même pas qu'elle existait, et supposait que c'était le fonctionnement normal de PHP. Cette page explique comment on peut écrire du code peu sécuritaire en utilisant cette directive. Gardez bien en tête que cette directive, par elle-même, n'est pas un trou de sécurité, mais qu'elle facilite leur création. »
Je te concède que ce n'est effectivement pas un trou de sécurité « en soi », mais je reste sur ma position : l'autoriser dans un environnement mutualisé, même bien configuré comme c'est, j'imagine, la cas chez vous et chez nous, constitue une source d'ennuis potentiels que nous préférons éviter.
Effet de bord non négligeable, cela oblige à programmer plus proprement, et compte tenu du niveau général, ce n'est pas du luxe...
Mais bon, chacun fait comme il le souhaite chez lui, hein :)
-- Eric Demeester - http://www.galacsys.net
dans (in) fr.reseaux.internet.hebergement, GPLHost
<nospam@nospam.gplhost.com> ecrivait (wrote) :
Bonjour,
Entièrement d'accord, mais ça n'inclus pas le register_global qui peut
et doit etre configurable (ce qui ne remet PAS en cause la sécurité
global du service, mais juste la qualité du script qui a besoin de cette
option, (j'insiste lourdement...)).
« 6.8 Utilisation des variables super-globales
L'une des évolutions les plus controversées de PHP a été le
changement de valeur par défaut de la directive PHP register_globals
, qui est passée de On à Off en PHP 4.2.0 . Beaucoup d'applications
dépendaient de cette directive, et de nombreux programmeurs ne
savaient même pas qu'elle existait, et supposait que c'était le
fonctionnement normal de PHP. Cette page explique comment on peut
écrire du code peu sécuritaire en utilisant cette directive. Gardez
bien en tête que cette directive, par elle-même, n'est pas un trou de
sécurité, mais qu'elle facilite leur création. »
Je te concède que ce n'est effectivement pas un trou de sécurité « en
soi », mais je reste sur ma position : l'autoriser dans un environnement
mutualisé, même bien configuré comme c'est, j'imagine, la cas chez vous
et chez nous, constitue une source d'ennuis potentiels que nous
préférons éviter.
Effet de bord non négligeable, cela oblige à programmer plus proprement,
et compte tenu du niveau général, ce n'est pas du luxe...
Mais bon, chacun fait comme il le souhaite chez lui, hein :)
dans (in) fr.reseaux.internet.hebergement, GPLHost ecrivait (wrote) :
Bonjour,
Entièrement d'accord, mais ça n'inclus pas le register_global qui peut et doit etre configurable (ce qui ne remet PAS en cause la sécurité global du service, mais juste la qualité du script qui a besoin de cette option, (j'insiste lourdement...)).
« 6.8 Utilisation des variables super-globales
L'une des évolutions les plus controversées de PHP a été le changement de valeur par défaut de la directive PHP register_globals , qui est passée de On à Off en PHP 4.2.0 . Beaucoup d'applications dépendaient de cette directive, et de nombreux programmeurs ne savaient même pas qu'elle existait, et supposait que c'était le fonctionnement normal de PHP. Cette page explique comment on peut écrire du code peu sécuritaire en utilisant cette directive. Gardez bien en tête que cette directive, par elle-même, n'est pas un trou de sécurité, mais qu'elle facilite leur création. »
Je te concède que ce n'est effectivement pas un trou de sécurité « en soi », mais je reste sur ma position : l'autoriser dans un environnement mutualisé, même bien configuré comme c'est, j'imagine, la cas chez vous et chez nous, constitue une source d'ennuis potentiels que nous préférons éviter.
Effet de bord non négligeable, cela oblige à programmer plus proprement, et compte tenu du niveau général, ce n'est pas du luxe...
Mais bon, chacun fait comme il le souhaite chez lui, hein :)
-- Eric Demeester - http://www.galacsys.net
Patrick Mevzek
Alors là, tu vas trop loin. register_global est peut-etre une mauvaise habitude, ou quelque chose QUI PEUT provoquer des erreurs, des bugs ou des trous de sécu. Mais en soit CE N'EST PAS une faille de sécurité,
Si (sauf si votre programme n'utilise *aucune* variable, ce qui me paraît plus probable).
De nombreuses failles de sécurité sont dûes à une fusion/un changement de contexte. C'est le cas de toutes les injections, où des caractères perdent/acquièrent un sens particulier en changeant de contexte.
Toute pratique qui vise à faire fusionner des contextes ne peut donc que générer des failles et fait partie donc intégrante de la faille, surtout quand cela relève de l'option de configuration globable, qui plus est activée par défaut (jusqu'aux versions 4.3)
Comparez, par exemple, avec la fonctionnalité de taint checking d'un autre langage en P, qui fait justement ce qu'il faut, à savoir séparer encore davantage les contextes, et refuser le passage d'informations d'un contexte à un autre.
-- 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>
Alors là, tu vas trop loin. register_global est peut-etre une mauvaise
habitude, ou quelque chose QUI PEUT provoquer des erreurs, des bugs ou
des trous de sécu. Mais en soit CE N'EST PAS une faille de sécurité,
Si (sauf si votre programme n'utilise *aucune* variable, ce qui me
paraît plus probable).
De nombreuses failles de sécurité sont dûes à une fusion/un changement
de contexte. C'est le cas de toutes les injections, où des caractères
perdent/acquièrent un sens particulier en changeant de contexte.
Toute pratique qui vise à faire fusionner des contextes ne peut donc que
générer des failles et fait partie donc intégrante de la faille,
surtout quand cela relève de l'option de configuration globable, qui plus
est activée par défaut (jusqu'aux versions 4.3)
Comparez, par exemple, avec la fonctionnalité de taint checking d'un
autre langage en P, qui fait justement ce qu'il faut, à savoir séparer
encore davantage les contextes, et refuser le passage d'informations d'un
contexte à un autre.
--
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>
Alors là, tu vas trop loin. register_global est peut-etre une mauvaise habitude, ou quelque chose QUI PEUT provoquer des erreurs, des bugs ou des trous de sécu. Mais en soit CE N'EST PAS une faille de sécurité,
Si (sauf si votre programme n'utilise *aucune* variable, ce qui me paraît plus probable).
De nombreuses failles de sécurité sont dûes à une fusion/un changement de contexte. C'est le cas de toutes les injections, où des caractères perdent/acquièrent un sens particulier en changeant de contexte.
Toute pratique qui vise à faire fusionner des contextes ne peut donc que générer des failles et fait partie donc intégrante de la faille, surtout quand cela relève de l'option de configuration globable, qui plus est activée par défaut (jusqu'aux versions 4.3)
Comparez, par exemple, avec la fonctionnalité de taint checking d'un autre langage en P, qui fait justement ce qu'il faut, à savoir séparer encore davantage les contextes, et refuser le passage d'informations d'un contexte à un autre.
-- 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>
Eric Demeester
dans (in) fr.reseaux.internet.hebergement, GPLHost ecrivait (wrote) :
Bonsoir Thomas,
Alors là, tu vas trop loin. register_global est peut-etre une mauvaise habitude, ou quelque chose QUI PEUT provoquer des erreurs, des bugs ou des trous de sécu. Mais en soit CE N'EST PAS une faille de sécurité, c'est juste qu'il est très facile d'oublier des cas.
CQFD. Pour moi, désolé, mais quelque chose QUI PEUT provoquer des problèmes, même indirectement, et où comme tu le dis toi-même « il est très facile d'oublier des cas », ça s'appelle une faille de sécurité quand tu proposes un service à des clients qui ne savent pas ou mal (je ne dis pas que c'est de leur faute) programmer proprement et justement faire attention à ces problèmes.
Il faut arreter de dire n'importe quoi, j'ai l'impression que tu n'as jamais écrit de script php pour poster un truc comme ça...
Je ne suis pas un cador en PHP, c'est vrai, je ne le pratique que depuis deux ans, parce que j'ai eu besoin de me plonger dedans.
Par contre je programme en divers langages depuis 1979 (c'est malin, maintenant tout le monde va savoir que je suis un vieux con :) ), j'ai vu l'apparition des virus sous Ms-Dos, j'ai été régulièrement confronté à des problèmes de sécurité dont mes clients étaient victimes, je les ai le plus souvent résolus (il faut dire que ce n'était pas bien compliqué en général).
Donc, je défends notre choix qui est de ne pas autoriser « registrar_globals on » en hébergement mutualisé. Les clients sont prévenus, le phpinfo() est disponible publiquement, et s'ils jugent cette mesure trop restrictive, nous les invitons à aller voir ailleurs.
-- Eric Demeester - http://www.galacsys.net
dans (in) fr.reseaux.internet.hebergement, GPLHost
<nospam@nospam.gplhost.com> ecrivait (wrote) :
Bonsoir Thomas,
Alors là, tu vas trop loin. register_global est peut-etre une mauvaise
habitude, ou quelque chose QUI PEUT provoquer des erreurs, des bugs ou
des trous de sécu. Mais en soit CE N'EST PAS une faille de sécurité,
c'est juste qu'il est très facile d'oublier des cas.
CQFD. Pour moi, désolé, mais quelque chose QUI PEUT provoquer des
problèmes, même indirectement, et où comme tu le dis toi-même « il est
très facile d'oublier des cas », ça s'appelle une faille de sécurité
quand tu proposes un service à des clients qui ne savent pas ou mal (je
ne dis pas que c'est de leur faute) programmer proprement et justement
faire attention à ces problèmes.
Il faut arreter de dire n'importe quoi, j'ai l'impression que tu n'as
jamais écrit de script php pour poster un truc comme ça...
Je ne suis pas un cador en PHP, c'est vrai, je ne le pratique que depuis
deux ans, parce que j'ai eu besoin de me plonger dedans.
Par contre je programme en divers langages depuis 1979 (c'est malin,
maintenant tout le monde va savoir que je suis un vieux con :) ), j'ai
vu l'apparition des virus sous Ms-Dos, j'ai été régulièrement confronté
à des problèmes de sécurité dont mes clients étaient victimes, je les ai
le plus souvent résolus (il faut dire que ce n'était pas bien compliqué
en général).
Donc, je défends notre choix qui est de ne pas autoriser
« registrar_globals on » en hébergement mutualisé. Les clients sont
prévenus, le phpinfo() est disponible publiquement, et s'ils jugent
cette mesure trop restrictive, nous les invitons à aller voir ailleurs.
dans (in) fr.reseaux.internet.hebergement, GPLHost ecrivait (wrote) :
Bonsoir Thomas,
Alors là, tu vas trop loin. register_global est peut-etre une mauvaise habitude, ou quelque chose QUI PEUT provoquer des erreurs, des bugs ou des trous de sécu. Mais en soit CE N'EST PAS une faille de sécurité, c'est juste qu'il est très facile d'oublier des cas.
CQFD. Pour moi, désolé, mais quelque chose QUI PEUT provoquer des problèmes, même indirectement, et où comme tu le dis toi-même « il est très facile d'oublier des cas », ça s'appelle une faille de sécurité quand tu proposes un service à des clients qui ne savent pas ou mal (je ne dis pas que c'est de leur faute) programmer proprement et justement faire attention à ces problèmes.
Il faut arreter de dire n'importe quoi, j'ai l'impression que tu n'as jamais écrit de script php pour poster un truc comme ça...
Je ne suis pas un cador en PHP, c'est vrai, je ne le pratique que depuis deux ans, parce que j'ai eu besoin de me plonger dedans.
Par contre je programme en divers langages depuis 1979 (c'est malin, maintenant tout le monde va savoir que je suis un vieux con :) ), j'ai vu l'apparition des virus sous Ms-Dos, j'ai été régulièrement confronté à des problèmes de sécurité dont mes clients étaient victimes, je les ai le plus souvent résolus (il faut dire que ce n'était pas bien compliqué en général).
Donc, je défends notre choix qui est de ne pas autoriser « registrar_globals on » en hébergement mutualisé. Les clients sont prévenus, le phpinfo() est disponible publiquement, et s'ils jugent cette mesure trop restrictive, nous les invitons à aller voir ailleurs.
-- Eric Demeester - http://www.galacsys.net
GPLHost
Eric Demeester wrote:
dans (in) fr.reseaux.internet.hebergement, GPLHost ecrivait (wrote) :
Bonsoir Thomas,
Alors là, tu vas trop loin. register_global est peut-etre une mauvaise habitude, ou quelque chose QUI PEUT provoquer des erreurs, des bugs ou des trous de sécu. Mais en soit CE N'EST PAS une faille de sécurité, c'est juste qu'il est très facile d'oublier des cas.
CQFD. Pour moi, désolé, mais quelque chose QUI PEUT provoquer des problèmes, même indirectement, et où comme tu le dis toi-même « il est très facile d'oublier des cas », ça s'appelle une faille de sécurité quand tu proposes un service à des clients qui ne savent pas ou mal (je ne dis pas que c'est de leur faute) programmer proprement et justement faire attention à ces problèmes.
C'est pour ça que PAR DEFAUT, c'est a OFF chez moi. Généralement, les clients qui ont besoin de le repasser a ON savent ce qu'ils font, pas besoin de warning.
Pour le "QUI PEUT", c'était a comprendre "qui peut si on programme mal", le register global permet juste d'éviter des oublis, et ajoute de la lisibilité dans le code (lire $_REQUEST["toto"] on comprend direct que ça vient de GET/POST, alors que $toto non...).
Thomas
Eric Demeester wrote:
dans (in) fr.reseaux.internet.hebergement, GPLHost
<nospam@nospam.gplhost.com> ecrivait (wrote) :
Bonsoir Thomas,
Alors là, tu vas trop loin. register_global est peut-etre une mauvaise
habitude, ou quelque chose QUI PEUT provoquer des erreurs, des bugs ou
des trous de sécu. Mais en soit CE N'EST PAS une faille de sécurité,
c'est juste qu'il est très facile d'oublier des cas.
CQFD. Pour moi, désolé, mais quelque chose QUI PEUT provoquer des
problèmes, même indirectement, et où comme tu le dis toi-même « il est
très facile d'oublier des cas », ça s'appelle une faille de sécurité
quand tu proposes un service à des clients qui ne savent pas ou mal (je
ne dis pas que c'est de leur faute) programmer proprement et justement
faire attention à ces problèmes.
C'est pour ça que PAR DEFAUT, c'est a OFF chez moi. Généralement, les
clients qui ont besoin de le repasser a ON savent ce qu'ils font, pas
besoin de warning.
Pour le "QUI PEUT", c'était a comprendre "qui peut si on programme mal",
le register global permet juste d'éviter des oublis, et ajoute de la
lisibilité dans le code (lire $_REQUEST["toto"] on comprend direct que
ça vient de GET/POST, alors que $toto non...).
dans (in) fr.reseaux.internet.hebergement, GPLHost ecrivait (wrote) :
Bonsoir Thomas,
Alors là, tu vas trop loin. register_global est peut-etre une mauvaise habitude, ou quelque chose QUI PEUT provoquer des erreurs, des bugs ou des trous de sécu. Mais en soit CE N'EST PAS une faille de sécurité, c'est juste qu'il est très facile d'oublier des cas.
CQFD. Pour moi, désolé, mais quelque chose QUI PEUT provoquer des problèmes, même indirectement, et où comme tu le dis toi-même « il est très facile d'oublier des cas », ça s'appelle une faille de sécurité quand tu proposes un service à des clients qui ne savent pas ou mal (je ne dis pas que c'est de leur faute) programmer proprement et justement faire attention à ces problèmes.
C'est pour ça que PAR DEFAUT, c'est a OFF chez moi. Généralement, les clients qui ont besoin de le repasser a ON savent ce qu'ils font, pas besoin de warning.
Pour le "QUI PEUT", c'était a comprendre "qui peut si on programme mal", le register global permet juste d'éviter des oublis, et ajoute de la lisibilité dans le code (lire $_REQUEST["toto"] on comprend direct que ça vient de GET/POST, alors que $toto non...).
Thomas
Stephane Kanschine
On Sun, 23 Oct 2005 04:51:21 +0200, GPLHost wrote:
parce que l'autoriser en mutualisé constituerait une faille de sécurité de classe Tsunami :) NON ! Ce n'est PAS une faille de sécurité. C'est juste une mauvaise
habitude de programmation qui PEUT mener à des problèmes, mais en soit cela remet en cause le script qui a besoin de register_global a on, mais ça ne remet pas en cause la sécurité du serveur lui-meme si tout est bien configuré.
+1
-- Stephane Kanschine
On Sun, 23 Oct 2005 04:51:21 +0200, GPLHost wrote:
parce que l'autoriser en mutualisé constituerait une faille de
sécurité de classe Tsunami :)
NON ! Ce n'est PAS une faille de sécurité. C'est juste une mauvaise
habitude de programmation qui PEUT mener à des problèmes, mais en soit
cela remet en cause le script qui a besoin de register_global a on, mais
ça ne remet pas en cause la sécurité du serveur lui-meme si tout est
bien configuré.
On Sun, 23 Oct 2005 04:51:21 +0200, GPLHost wrote:
parce que l'autoriser en mutualisé constituerait une faille de sécurité de classe Tsunami :) NON ! Ce n'est PAS une faille de sécurité. C'est juste une mauvaise
habitude de programmation qui PEUT mener à des problèmes, mais en soit cela remet en cause le script qui a besoin de register_global a on, mais ça ne remet pas en cause la sécurité du serveur lui-meme si tout est bien configuré.
+1
-- Stephane Kanschine
Stephane Kanschine
On Sat, 22 Oct 2005 00:14:55 +0200, Spyou wrote:
Spyou, sors de ce corps. Nan eh, j'ai arreté de posseder l'esprit des gens le jour ou j'ai arreter
les jeux de role
C'est possible d'arrêter les jeux de rôle ?
PS : notre interface d'admin mutu est une mouise, malgré le fait que beaucoup de gens nous qualifient d'hebergeur "digne de ce nom"
T'avais pas parlé d'embaucher des développeurs ? :-)
-- Stephane Kanschine
On Sat, 22 Oct 2005 00:14:55 +0200, Spyou wrote:
Spyou, sors de ce corps.
Nan eh, j'ai arreté de posseder l'esprit des gens le jour ou j'ai arreter
les jeux de role
C'est possible d'arrêter les jeux de rôle ?
PS : notre interface d'admin mutu est une mouise, malgré le fait que
beaucoup de gens nous qualifient d'hebergeur "digne de ce nom"
T'avais pas parlé d'embaucher des développeurs ? :-)
