"Denis Beauregard" a écrit dans le message de news:
C'est possible seulement quand le traducteur php tombe en panne.
Si le traducteur php tombe en panne??? c'est quoi cette blague ?
c'est pas une voiture ;) je pense que c'etait de l'humour...
Etienne
PS : Pour compléter ta réponse, c'est aussi possible : - si tu laisses trainer tes codes d'accès a ton serveur FTP ou SSH - si tes sources sont sous un system d'exploitation digne d'une passoire (no comment !!!) - si tu imprimes tes sources et que tu le jettes dans la poubelle sans les avoir passé au broyeur. - si tu les envoie par mail sans les crypter. - si quelqu'un a installé un snort sur ton réseau. - si t'as mis une webcam devant ton ecran. - si tu laisse jouer ton petit frere au freesbee avec tes CD rom de backup. - si ton hebergeur n'est pas sympa ;) - si tu est hebergé sur un serveur mutualisé mal configuré (comme le sont la plupart des serveurs mutualisé) - si tu oublie tous les <? - ...
"Denis Beauregard" <no@nospam.com.invalid> a écrit dans le message de news:
tsv2a09fggcpvp3iknfkkh29qdtnidcbhi@4ax.com...
C'est possible seulement quand le traducteur php tombe en panne.
Si le traducteur php tombe en panne???
c'est quoi cette blague ?
c'est pas une voiture ;)
je pense que c'etait de l'humour...
Etienne
PS : Pour compléter ta réponse, c'est aussi possible :
- si tu laisses trainer tes codes d'accès a ton serveur FTP ou SSH
- si tes sources sont sous un system d'exploitation digne d'une passoire (no
comment !!!)
- si tu imprimes tes sources et que tu le jettes dans la poubelle sans les
avoir passé au broyeur.
- si tu les envoie par mail sans les crypter.
- si quelqu'un a installé un snort sur ton réseau.
- si t'as mis une webcam devant ton ecran.
- si tu laisse jouer ton petit frere au freesbee avec tes CD rom de backup.
- si ton hebergeur n'est pas sympa ;)
- si tu est hebergé sur un serveur mutualisé mal configuré (comme le sont la
plupart des serveurs mutualisé)
- si tu oublie tous les <?
- ...
"Denis Beauregard" a écrit dans le message de news:
C'est possible seulement quand le traducteur php tombe en panne.
Si le traducteur php tombe en panne??? c'est quoi cette blague ?
c'est pas une voiture ;) je pense que c'etait de l'humour...
Etienne
PS : Pour compléter ta réponse, c'est aussi possible : - si tu laisses trainer tes codes d'accès a ton serveur FTP ou SSH - si tes sources sont sous un system d'exploitation digne d'une passoire (no comment !!!) - si tu imprimes tes sources et que tu le jettes dans la poubelle sans les avoir passé au broyeur. - si tu les envoie par mail sans les crypter. - si quelqu'un a installé un snort sur ton réseau. - si t'as mis une webcam devant ton ecran. - si tu laisse jouer ton petit frere au freesbee avec tes CD rom de backup. - si ton hebergeur n'est pas sympa ;) - si tu est hebergé sur un serveur mutualisé mal configuré (comme le sont la plupart des serveurs mutualisé) - si tu oublie tous les <? - ...
Sam
"Denis Beauregard" a écrit
- si l'usager a laissé traîner un script PHP permettant d'exécuter des commandes
Egalement si mauvais codage d'un "forçage de téléchargement", qui permetrait de télécharger les fichiers php ou de passwords...
exemple : http://www.monserveur.com/download.php?file=.htpassword (vous voyez ou je veux en venir ?)
"Denis Beauregard" a écrit
- si l'usager a laissé traîner un script PHP permettant d'exécuter
des commandes
Egalement si mauvais codage d'un "forçage de téléchargement", qui permetrait
de télécharger les fichiers php ou de passwords...
exemple : http://www.monserveur.com/download.php?file=.htpassword (vous
voyez ou je veux en venir ?)
Le 13 May 2004 07:41:55 GMT, Etienne SOBOLE écrivait dans fr.comp.lang.php:
"Denis Beauregard" a écrit dans le message de news:
C'est possible seulement quand le traducteur php tombe en panne.
Si le traducteur php tombe en panne??? c'est quoi cette blague ?
C'est une façon de parler.
Denis
cmoietvous
Ce qui veut dire que si j'accède par un script php à ma base de données, en laissant par conséquent mon user et mon password dans ce script, personne ne pourra lire ce script et de ce fait avoir mon user et mon password?
Ce qui veut dire que si j'accède par un script php à ma base de données, en
laissant par conséquent mon user et mon password dans ce script, personne ne
pourra lire ce script et de ce fait avoir mon user et mon password?
Ce qui veut dire que si j'accède par un script php à ma base de données, en laissant par conséquent mon user et mon password dans ce script, personne ne pourra lire ce script et de ce fait avoir mon user et mon password?
Denis Beauregard
Le 17 May 2004 21:58:25 GMT, cmoietvous écrivait dans fr.comp.lang.php:
Ce qui veut dire que si j'accède par un script php à ma base de données, en laissant par conséquent mon user et mon password dans ce script, personne ne pourra lire ce script et de ce fait avoir mon user et mon password?
Normalement, le mot de passe de la base sera différent de celui du compte. Par exemple, l'hébergeur installera SQL avec le mot de passe courant et te demandera de le remplacer le plus tôt possible.
Mais c'est toujours possible que quelqu'un réussisse à lire le mot de passe. Le coder ne servirait pas à grand chose vu qu'il y a nécessairement un moment où le mot de passe est lisible, et le pirate n'a qu'à recopier tous les scripts s'il réussit à avoir accès au code interne (il suffirait d'ajouter une ligne juste avant la fonction qui utilise le mot de passe).
Je pense que du moment qu'on utilise un hébergeur extérieur, il y a nécessairement un risque. Il faut donc faire attention aux données critiques.
Denis
Le 17 May 2004 21:58:25 GMT, cmoietvous <cmoietvousospam@free.fr>
écrivait dans fr.comp.lang.php:
Ce qui veut dire que si j'accède par un script php à ma base de données, en
laissant par conséquent mon user et mon password dans ce script, personne ne
pourra lire ce script et de ce fait avoir mon user et mon password?
Normalement, le mot de passe de la base sera différent de celui du
compte. Par exemple, l'hébergeur installera SQL avec le mot de passe
courant et te demandera de le remplacer le plus tôt possible.
Mais c'est toujours possible que quelqu'un réussisse à lire le mot
de passe. Le coder ne servirait pas à grand chose vu qu'il y a
nécessairement un moment où le mot de passe est lisible, et le
pirate n'a qu'à recopier tous les scripts s'il réussit à avoir
accès au code interne (il suffirait d'ajouter une ligne juste avant
la fonction qui utilise le mot de passe).
Je pense que du moment qu'on utilise un hébergeur extérieur, il y a
nécessairement un risque. Il faut donc faire attention aux données
critiques.
Le 17 May 2004 21:58:25 GMT, cmoietvous écrivait dans fr.comp.lang.php:
Ce qui veut dire que si j'accède par un script php à ma base de données, en laissant par conséquent mon user et mon password dans ce script, personne ne pourra lire ce script et de ce fait avoir mon user et mon password?
Normalement, le mot de passe de la base sera différent de celui du compte. Par exemple, l'hébergeur installera SQL avec le mot de passe courant et te demandera de le remplacer le plus tôt possible.
Mais c'est toujours possible que quelqu'un réussisse à lire le mot de passe. Le coder ne servirait pas à grand chose vu qu'il y a nécessairement un moment où le mot de passe est lisible, et le pirate n'a qu'à recopier tous les scripts s'il réussit à avoir accès au code interne (il suffirait d'ajouter une ligne juste avant la fonction qui utilise le mot de passe).
Je pense que du moment qu'on utilise un hébergeur extérieur, il y a nécessairement un risque. Il faut donc faire attention aux données critiques.
Denis
Antoine Dinimant
Ce qui veut dire que si j'accède par un script php à ma base de données, en laissant par conséquent mon user et mon password dans ce script, personne ne pourra lire ce script et de ce fait avoir mon user et mon password?
Normalement, le mot de passe de la base sera différent de celui du compte. Par exemple, l'hébergeur installera SQL avec le mot de passe courant et te demandera de le remplacer le plus tôt possible.
perso, je stocke les paramètres de connexion BDD dans un sous-répertoire. Dans ce sous-rep, je mets un fichier .htaccess contenant la seule ligne "deny from all" (c'est une directive Apache, donc ça ne marcherait pas sur un autre serveur, même si l'équivalent doit exister).
Ainsi, même si le moteur PHP est en panne, mes paramètres sont inaccessibles en HTTP. Pour les lire, il faut avoir les paramètres de connexion FTP du site, qui eux n'apparaissent nulle part (et puis si qqn de malintentionné peut faire du FTP sur ton site, tu es grillé de toute façon ;-)
Ce qui veut dire que si j'accède par un script php à ma base de données, en
laissant par conséquent mon user et mon password dans ce script, personne ne
pourra lire ce script et de ce fait avoir mon user et mon password?
Normalement, le mot de passe de la base sera différent de celui du
compte. Par exemple, l'hébergeur installera SQL avec le mot de passe
courant et te demandera de le remplacer le plus tôt possible.
perso, je stocke les paramètres de connexion BDD dans un
sous-répertoire. Dans ce sous-rep, je mets un fichier .htaccess
contenant la seule ligne "deny from all" (c'est une directive Apache,
donc ça ne marcherait pas sur un autre serveur, même si l'équivalent
doit exister).
Ainsi, même si le moteur PHP est en panne, mes paramètres sont
inaccessibles en HTTP. Pour les lire, il faut avoir les paramètres de
connexion FTP du site, qui eux n'apparaissent nulle part (et puis si qqn
de malintentionné peut faire du FTP sur ton site, tu es grillé de toute
façon ;-)
Ce qui veut dire que si j'accède par un script php à ma base de données, en laissant par conséquent mon user et mon password dans ce script, personne ne pourra lire ce script et de ce fait avoir mon user et mon password?
Normalement, le mot de passe de la base sera différent de celui du compte. Par exemple, l'hébergeur installera SQL avec le mot de passe courant et te demandera de le remplacer le plus tôt possible.
perso, je stocke les paramètres de connexion BDD dans un sous-répertoire. Dans ce sous-rep, je mets un fichier .htaccess contenant la seule ligne "deny from all" (c'est une directive Apache, donc ça ne marcherait pas sur un autre serveur, même si l'équivalent doit exister).
Ainsi, même si le moteur PHP est en panne, mes paramètres sont inaccessibles en HTTP. Pour les lire, il faut avoir les paramètres de connexion FTP du site, qui eux n'apparaissent nulle part (et puis si qqn de malintentionné peut faire du FTP sur ton site, tu es grillé de toute façon ;-)
