dans un formulaire, dont les infos sont envoyées par courrier, j'ai
une zone de commentaires
le message est envoyé par la fonction suivante :
function MAIL_NVLP($fromname, $fromaddress, $toname, $toaddress,
$subject, $message)
{
// Copyright 2005 ECRIA LLC, http://www.ECRIA.com
// Please use or modify for any purpose but leave this notice unchanged.
$headers = "MIME-Version: 1.0\n";
$headers .= "Content-type: text/plain; charset=iso-8859-1\n";
$headers .= "X-Priority: 3\n";
$headers .= "X-MSMail-Priority: Normal\n";
$headers .= "X-Mailer: php\n";
$headers .= "From: \"".$fromname."\" <".$fromaddress.">\n";
return mail($toaddress, $subject, $message, $headers);
}
pas de problèmes à l'arrivéeavec les caractères accentués ou spéciaux
.. tout s'affiche comme il faut,
MAIS dès qu'il y a un apostrophe (') celui-ci apparait avec un Escape
(\) devant...
Il y a-t-il un moyen de faire disparaitre ce caractère affiché à l'arriivée ?
sûrement un paramètre à donner dans $headers , mais lequel ?
dans un formulaire, dont les infos sont envoyées par courrier, j'ai une zone de commentaires MAIS dès qu'il y a un apostrophe (') celui-ci apparait avec un Escape () devant...
Je serais malpoli, je te dirais... RTFM! Mais comme je suis poli, je te dis RTFM la: <http://fr.php.net/manual/fr/function.stripslashes.php>
-- Aide informatique: http://help-info.forumactif.com Humour: http://www.chatfou.com Tchattez en liberté: http://www.crazy-irc.net
Josselin wrote:
dans un formulaire, dont les infos sont envoyées par courrier, j'ai
une zone de commentaires
MAIS dès qu'il y a un apostrophe (') celui-ci apparait avec un Escape
() devant...
Je serais malpoli, je te dirais... RTFM!
Mais comme je suis poli, je te dis RTFM la:
<http://fr.php.net/manual/fr/function.stripslashes.php>
--
Aide informatique: http://help-info.forumactif.com
Humour: http://www.chatfou.com
Tchattez en liberté: http://www.crazy-irc.net
dans un formulaire, dont les infos sont envoyées par courrier, j'ai une zone de commentaires MAIS dès qu'il y a un apostrophe (') celui-ci apparait avec un Escape () devant...
Je serais malpoli, je te dirais... RTFM! Mais comme je suis poli, je te dis RTFM la: <http://fr.php.net/manual/fr/function.stripslashes.php>
-- Aide informatique: http://help-info.forumactif.com Humour: http://www.chatfou.com Tchattez en liberté: http://www.crazy-irc.net
Florian Sinatra
*Josselin* @ 06/03/2006 13:49 :
pas de problèmes à l'arrivée avec les caractères accentués ou spéciaux .. tout s'affiche comme il faut, MAIS dès qu'il y a un apostrophe (') celui-ci apparait avec un Escape () devant... Il y a-t-il un moyen de faire disparaitre ce caractère affiché à l'arriivée ? sûrement un paramètre à donner dans $headers , mais lequel ?
C'est une *absurdité* de PHP qui a été implémentée pour les newbies "pour protéger le code contre les trous de sécurité". Mais personne n'avertit ces débutants que cette fonction est activée par défaut. Cela s'appelle les "guillemets magiques", et ca fait un addslashes sur tous les GET/COOKIE/POST automatiquement. Personnellement, j'ai passé toute une nuit en m'arrachant les cheveux en cherchant pourquoi mes données étaient toutes échappées. Pour finir, il n'est même pas possible de les désactiver pendant l'exécution. Il y bien sûr quelques bidouilles, que tu trouveras en RTFM :
pas de problèmes à l'arrivée avec les caractères accentués ou spéciaux
.. tout s'affiche comme il faut,
MAIS dès qu'il y a un apostrophe (') celui-ci apparait avec un Escape
() devant...
Il y a-t-il un moyen de faire disparaitre ce caractère affiché à l'arriivée ?
sûrement un paramètre à donner dans $headers , mais lequel ?
C'est une *absurdité* de PHP qui a été implémentée pour les newbies
"pour protéger le code contre les trous de sécurité". Mais personne
n'avertit ces débutants que cette fonction est activée par défaut. Cela
s'appelle les "guillemets magiques", et ca fait un addslashes sur tous
les GET/COOKIE/POST automatiquement. Personnellement, j'ai passé toute
une nuit en m'arrachant les cheveux en cherchant pourquoi mes données
étaient toutes échappées. Pour finir, il n'est même pas possible de les
désactiver pendant l'exécution. Il y bien sûr quelques bidouilles, que
tu trouveras en RTFM :
pas de problèmes à l'arrivée avec les caractères accentués ou spéciaux .. tout s'affiche comme il faut, MAIS dès qu'il y a un apostrophe (') celui-ci apparait avec un Escape () devant... Il y a-t-il un moyen de faire disparaitre ce caractère affiché à l'arriivée ? sûrement un paramètre à donner dans $headers , mais lequel ?
C'est une *absurdité* de PHP qui a été implémentée pour les newbies "pour protéger le code contre les trous de sécurité". Mais personne n'avertit ces débutants que cette fonction est activée par défaut. Cela s'appelle les "guillemets magiques", et ca fait un addslashes sur tous les GET/COOKIE/POST automatiquement. Personnellement, j'ai passé toute une nuit en m'arrachant les cheveux en cherchant pourquoi mes données étaient toutes échappées. Pour finir, il n'est même pas possible de les désactiver pendant l'exécution. Il y bien sûr quelques bidouilles, que tu trouveras en RTFM :
C'est une *absurdité* de PHP qui a été implémentée pour les newbies "pour protéger le code contre les trous de sécurité".
Qui a aussi un intérêt pour tous, à savoir la possibilité de ne pas provoquer d'erreurs lors d'une insertion dans une base de données de type mySQL.
Par ailleurs, lorsqu'on travaille avec la sus-dite base et que l'on veut faire un affichage, on est *obligé* de faire un stripslashes, donc autant prendre l'habitude de toujours le faire.
Je ne vois d'ailleurs pas en quoi c'est une absurdité.
-- Aide informatique: http://help-info.forumactif.com Humour: http://www.chatfou.com Tchattez en liberté: http://www.crazy-irc.net
Florian Sinatra wrote:
C'est une *absurdité* de PHP qui a été implémentée pour les newbies
"pour protéger le code contre les trous de sécurité".
Qui a aussi un intérêt pour tous, à savoir la possibilité de ne pas
provoquer d'erreurs lors d'une insertion dans une base de données de
type mySQL.
Par ailleurs, lorsqu'on travaille avec la sus-dite base et que l'on veut
faire un affichage, on est *obligé* de faire un stripslashes, donc
autant prendre l'habitude de toujours le faire.
Je ne vois d'ailleurs pas en quoi c'est une absurdité.
--
Aide informatique: http://help-info.forumactif.com
Humour: http://www.chatfou.com
Tchattez en liberté: http://www.crazy-irc.net
C'est une *absurdité* de PHP qui a été implémentée pour les newbies "pour protéger le code contre les trous de sécurité".
Qui a aussi un intérêt pour tous, à savoir la possibilité de ne pas provoquer d'erreurs lors d'une insertion dans une base de données de type mySQL.
Par ailleurs, lorsqu'on travaille avec la sus-dite base et que l'on veut faire un affichage, on est *obligé* de faire un stripslashes, donc autant prendre l'habitude de toujours le faire.
Je ne vois d'ailleurs pas en quoi c'est une absurdité.
-- Aide informatique: http://help-info.forumactif.com Humour: http://www.chatfou.com Tchattez en liberté: http://www.crazy-irc.net
Marc
Florian Sinatra wrote:
C'est une *absurdité* de PHP qui a été implémentée pour les newbies "pour protéger le code contre les trous de sécurité". Mais personne n'avertit ces débutants que cette fonction est activée par défaut. Cela s'appelle les "guillemets magiques", et ca fait un addslashes sur tous les GET/COOKIE/POST automatiquement. Personnellement, j'ai passé toute une nuit en m'arrachant les cheveux en cherchant pourquoi mes données étaient toutes échappées. Pour finir, il n'est même pas possible de les désactiver pendant l'exécution. Il y bien sûr quelques bidouilles, que tu trouveras en RTFM :
- qu'est-ce que tu proposes a la place ? - avec cette petite astuce, il devient difficile de faire de l'injection SQL. Est-ce impossible ? je ne sais pas.
si tu es si pro que ce que ton message veut bien le laisse entendre, il existe des hebergements pro ou tu peux deactiver cette option. Bon courage pour la securité ...
Florian Sinatra wrote:
C'est une *absurdité* de PHP qui a été implémentée pour les newbies
"pour protéger le code contre les trous de sécurité". Mais personne
n'avertit ces débutants que cette fonction est activée par défaut. Cela
s'appelle les "guillemets magiques", et ca fait un addslashes sur tous
les GET/COOKIE/POST automatiquement. Personnellement, j'ai passé toute
une nuit en m'arrachant les cheveux en cherchant pourquoi mes données
étaient toutes échappées. Pour finir, il n'est même pas possible de les
désactiver pendant l'exécution. Il y bien sûr quelques bidouilles, que
tu trouveras en RTFM :
- qu'est-ce que tu proposes a la place ?
- avec cette petite astuce, il devient difficile de faire de l'injection SQL.
Est-ce impossible ? je ne sais pas.
si tu es si pro que ce que ton message veut bien le laisse entendre, il existe
des hebergements pro ou tu peux deactiver cette option. Bon courage pour la
securité ...
C'est une *absurdité* de PHP qui a été implémentée pour les newbies "pour protéger le code contre les trous de sécurité". Mais personne n'avertit ces débutants que cette fonction est activée par défaut. Cela s'appelle les "guillemets magiques", et ca fait un addslashes sur tous les GET/COOKIE/POST automatiquement. Personnellement, j'ai passé toute une nuit en m'arrachant les cheveux en cherchant pourquoi mes données étaient toutes échappées. Pour finir, il n'est même pas possible de les désactiver pendant l'exécution. Il y bien sûr quelques bidouilles, que tu trouveras en RTFM :
- qu'est-ce que tu proposes a la place ? - avec cette petite astuce, il devient difficile de faire de l'injection SQL. Est-ce impossible ? je ne sais pas.
si tu es si pro que ce que ton message veut bien le laisse entendre, il existe des hebergements pro ou tu peux deactiver cette option. Bon courage pour la securité ...
Bruno Baguette
Florian Sinatra wrote:
C'est une *absurdité* de PHP qui a été implémentée pour les newbies "pour protéger le code contre les trous de sécurité".
Qui a aussi un intérêt pour tous, à savoir la possibilité de ne pas provoquer d'erreurs lors d'une insertion dans une base de données de type mySQL.
Euh, bof. Il y a des fonctions pour échapper les caractères spéciaux qui sont prévues pour chaque SGBD (ex. pg_escape_string(), mysql_real_escape_string(),...).
Ces fonctions sont nettement plus indiquées qu'un magic quote !
Par ailleurs, lorsqu'on travaille avec la sus-dite base et que l'on veut faire un affichage, on est *obligé* de faire un stripslashes, donc autant prendre l'habitude de toujours le faire.
Si vous êtes obligé de faire un stripslashes quand vous affichez une donnée qui vient de votre base de données, ce n'est pas normal.
Quand vous insérez des données, les caractères d'échappement servent uniquement pour la requête d'insertion/mise à jour. Les données dans la base de données ne doivent PAS avoir ces caractères d'échappement.
Je ne vois d'ailleurs pas en quoi c'est une absurdité.
Parce qu'il y a autre chose des bases de données en PHP. Donc autant laisser sagement les magic_quotes à OFF et échapper les données uniquement quand cela est nécessaire.
De toutes manières, il ne faut jamais supposer que magic_quotes est à ON ou OFF, l'idéal étant de vérifier lors de l'exécution du script, s'il faut virer les quotes parasites. Pour cela, la fonction get_magic_quotes_gpc() est toute indiquée pour voir si un nettoyage des données dans les variables est nécessaire avant de continuer l'exécution du script.
En espérant que ca aide,
-- Bruno BAGUETTE -
"Nous n'avons pas à garantir la sécurité des produits alimentaires génétiquement modifiés (OGM). Notre intérêt est d'en vendre le plus possible."
Propos de Monsanto, in le Monde Diplomatique, Décembre 98.
Florian Sinatra wrote:
C'est une *absurdité* de PHP qui a été implémentée pour les newbies
"pour protéger le code contre les trous de sécurité".
Qui a aussi un intérêt pour tous, à savoir la possibilité de ne pas
provoquer d'erreurs lors d'une insertion dans une base de données de
type mySQL.
Euh, bof. Il y a des fonctions pour échapper les caractères spéciaux qui
sont prévues pour chaque SGBD (ex. pg_escape_string(),
mysql_real_escape_string(),...).
Ces fonctions sont nettement plus indiquées qu'un magic quote !
Par ailleurs, lorsqu'on travaille avec la sus-dite base et que l'on veut
faire un affichage, on est *obligé* de faire un stripslashes, donc
autant prendre l'habitude de toujours le faire.
Si vous êtes obligé de faire un stripslashes quand vous affichez une
donnée qui vient de votre base de données, ce n'est pas normal.
Quand vous insérez des données, les caractères d'échappement servent
uniquement pour la requête d'insertion/mise à jour. Les données dans la
base de données ne doivent PAS avoir ces caractères d'échappement.
Je ne vois d'ailleurs pas en quoi c'est une absurdité.
Parce qu'il y a autre chose des bases de données en PHP. Donc autant
laisser sagement les magic_quotes à OFF et échapper les données
uniquement quand cela est nécessaire.
De toutes manières, il ne faut jamais supposer que magic_quotes est à ON
ou OFF, l'idéal étant de vérifier lors de l'exécution du script, s'il
faut virer les quotes parasites. Pour cela, la fonction
get_magic_quotes_gpc() est toute indiquée pour voir si un nettoyage des
données dans les variables est nécessaire avant de continuer l'exécution
du script.
En espérant que ca aide,
--
Bruno BAGUETTE - bouchon@alussinan.org
"Nous n'avons pas à garantir la sécurité des
produits alimentaires génétiquement modifiés (OGM).
Notre intérêt est d'en vendre le plus possible."
Propos de Monsanto, in le Monde Diplomatique, Décembre 98.
C'est une *absurdité* de PHP qui a été implémentée pour les newbies "pour protéger le code contre les trous de sécurité".
Qui a aussi un intérêt pour tous, à savoir la possibilité de ne pas provoquer d'erreurs lors d'une insertion dans une base de données de type mySQL.
Euh, bof. Il y a des fonctions pour échapper les caractères spéciaux qui sont prévues pour chaque SGBD (ex. pg_escape_string(), mysql_real_escape_string(),...).
Ces fonctions sont nettement plus indiquées qu'un magic quote !
Par ailleurs, lorsqu'on travaille avec la sus-dite base et que l'on veut faire un affichage, on est *obligé* de faire un stripslashes, donc autant prendre l'habitude de toujours le faire.
Si vous êtes obligé de faire un stripslashes quand vous affichez une donnée qui vient de votre base de données, ce n'est pas normal.
Quand vous insérez des données, les caractères d'échappement servent uniquement pour la requête d'insertion/mise à jour. Les données dans la base de données ne doivent PAS avoir ces caractères d'échappement.
Je ne vois d'ailleurs pas en quoi c'est une absurdité.
Parce qu'il y a autre chose des bases de données en PHP. Donc autant laisser sagement les magic_quotes à OFF et échapper les données uniquement quand cela est nécessaire.
De toutes manières, il ne faut jamais supposer que magic_quotes est à ON ou OFF, l'idéal étant de vérifier lors de l'exécution du script, s'il faut virer les quotes parasites. Pour cela, la fonction get_magic_quotes_gpc() est toute indiquée pour voir si un nettoyage des données dans les variables est nécessaire avant de continuer l'exécution du script.
En espérant que ca aide,
-- Bruno BAGUETTE -
"Nous n'avons pas à garantir la sécurité des produits alimentaires génétiquement modifiés (OGM). Notre intérêt est d'en vendre le plus possible."
Propos de Monsanto, in le Monde Diplomatique, Décembre 98.
Patrick Mevzek
- avec cette petite astuce, il devient difficile de faire de l'injection SQL.
Ah ca y est, ca recommence. Ca faisait longtemps que cette (fausse) idée n'était pas revenue...
Même avec magic_quotes on peut faire des injections SQL. Ca dépend des requêtes, de la façon dont le programme travaille et du SGBDR.
Utiliser magic_quotes pour régler ce problème est une mauvaise façon de penser. De celle qui donne une impression de sécurité à la place de la sécurité, bref la pire chose qu'on puisse imaginer.
Sans compter les effets de bord risibles quand on ne maîtrise pas le phénomène, mais qu'on observe sur de nombreux sites...
-- 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>
- avec cette petite astuce, il devient difficile de faire de l'injection SQL.
Ah ca y est, ca recommence. Ca faisait longtemps que cette (fausse) idée
n'était pas revenue...
Même avec magic_quotes on peut faire des injections SQL. Ca dépend des
requêtes, de la façon dont le programme travaille et du SGBDR.
Utiliser magic_quotes pour régler ce problème est une mauvaise façon de
penser. De celle qui donne une impression de sécurité à la place de la
sécurité, bref la pire chose qu'on puisse imaginer.
Sans compter les effets de bord risibles quand on ne maîtrise pas le
phénomène, mais qu'on observe sur de nombreux sites...
--
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>
- avec cette petite astuce, il devient difficile de faire de l'injection SQL.
Ah ca y est, ca recommence. Ca faisait longtemps que cette (fausse) idée n'était pas revenue...
Même avec magic_quotes on peut faire des injections SQL. Ca dépend des requêtes, de la façon dont le programme travaille et du SGBDR.
Utiliser magic_quotes pour régler ce problème est une mauvaise façon de penser. De celle qui donne une impression de sécurité à la place de la sécurité, bref la pire chose qu'on puisse imaginer.
Sans compter les effets de bord risibles quand on ne maîtrise pas le phénomène, mais qu'on observe sur de nombreux sites...
-- 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>
Florian Sinatra
*CrazyCat* @ 07/03/2006 18:23 :
Je ne vois d'ailleurs pas en quoi c'est une absurdité.
* Elle est faite pour les débutants, mais ce sont ces mêmes débutants (dont je fais partie) qui ignorent son existence et s'arrachent les cheveux. * Elle est activée par défaut, et impossible de la désactiver proprement à l'exécution. * Et surtout, elle délègue le rôle de sécuriser ses données à l'interpréteur. Or, c'est précisément partie du boulot du développeur. Un interpréteur est fait pour interpréter, pas pour échapper les données.
-- _flo_
*CrazyCat* @ 07/03/2006 18:23 :
Je ne vois d'ailleurs pas en quoi c'est une absurdité.
* Elle est faite pour les débutants, mais ce sont ces mêmes débutants
(dont je fais partie) qui ignorent son existence et s'arrachent les
cheveux.
* Elle est activée par défaut, et impossible de la désactiver proprement
à l'exécution.
* Et surtout, elle délègue le rôle de sécuriser ses données à
l'interpréteur. Or, c'est précisément partie du boulot du développeur.
Un interpréteur est fait pour interpréter, pas pour échapper les
données.
Je ne vois d'ailleurs pas en quoi c'est une absurdité.
* Elle est faite pour les débutants, mais ce sont ces mêmes débutants (dont je fais partie) qui ignorent son existence et s'arrachent les cheveux. * Elle est activée par défaut, et impossible de la désactiver proprement à l'exécution. * Et surtout, elle délègue le rôle de sécuriser ses données à l'interpréteur. Or, c'est précisément partie du boulot du développeur. Un interpréteur est fait pour interpréter, pas pour échapper les données.
-- _flo_
Florian Sinatra
*Marc* @ 07/03/2006 18:27 :
- qu'est-ce que tu proposes a la place ? En un mot : *rien* car c'est au développeur de développer son
application en fonction des données. Un interpréteur n'est pas fait pour çela.
- avec cette petite astuce, il devient difficile de faire de l'injection SQL. Est-ce impossible ? je ne sais pas. Cf le message de Patrick Mevzek.
si tu es si pro que ce que ton message veut bien le laisse entendre, il existe Je ne suis absolument pas pro. Je suis autodidacte (depuis 5 ans), c'est
une passion et je m'efforce de la faire bien, et d'écrire le plus concisément et correctement possible.
des hebergements pro ou tu peux deactiver cette option. Bon courage pour la securité ... Si tu t'en remets aux magic_quotes pour ta sécurité, si tu crois que
cela suffit, et qu'en leur absence ton appli souffrira d'un trou de sécurité, le seul trou de sécurité à chercher se trouve entre le clavier et la chaise.
Sur ce, bonne soirée :-) -- _flo_
*Marc* @ 07/03/2006 18:27 :
- qu'est-ce que tu proposes a la place ?
En un mot : *rien* car c'est au développeur de développer son
application en fonction des données. Un interpréteur n'est pas fait pour
çela.
- avec cette petite astuce, il devient difficile de faire de l'injection SQL.
Est-ce impossible ? je ne sais pas.
Cf le message de Patrick Mevzek.
si tu es si pro que ce que ton message veut bien le laisse entendre, il existe
Je ne suis absolument pas pro. Je suis autodidacte (depuis 5 ans), c'est
une passion et je m'efforce de la faire bien, et d'écrire le plus
concisément et correctement possible.
des hebergements pro ou tu peux deactiver cette option. Bon courage pour la
securité ...
Si tu t'en remets aux magic_quotes pour ta sécurité, si tu crois que
cela suffit, et qu'en leur absence ton appli souffrira d'un trou de
sécurité, le seul trou de sécurité à chercher se trouve entre le clavier
et la chaise.
- qu'est-ce que tu proposes a la place ? En un mot : *rien* car c'est au développeur de développer son
application en fonction des données. Un interpréteur n'est pas fait pour çela.
- avec cette petite astuce, il devient difficile de faire de l'injection SQL. Est-ce impossible ? je ne sais pas. Cf le message de Patrick Mevzek.
si tu es si pro que ce que ton message veut bien le laisse entendre, il existe Je ne suis absolument pas pro. Je suis autodidacte (depuis 5 ans), c'est
une passion et je m'efforce de la faire bien, et d'écrire le plus concisément et correctement possible.
des hebergements pro ou tu peux deactiver cette option. Bon courage pour la securité ... Si tu t'en remets aux magic_quotes pour ta sécurité, si tu crois que
cela suffit, et qu'en leur absence ton appli souffrira d'un trou de sécurité, le seul trou de sécurité à chercher se trouve entre le clavier et la chaise.
Sur ce, bonne soirée :-) -- _flo_
Marc
Patrick Mevzek wrote:
- avec cette petite astuce, il devient difficile de faire de l'injection SQL.
Ah ca y est, ca recommence. Ca faisait longtemps que cette (fausse) idée n'était pas revenue...
si tu veux faire la synthèse ou nous passer une adresse.
Même avec magic_quotes on peut faire des injections SQL. Ca dépend des requêtes, de la façon dont le programme travaille et du SGBDR.
Utiliser magic_quotes pour régler ce problème est une mauvaise façon de penser. De celle qui donne une impression de sécurité à la place de la sécurité, bref la pire chose qu'on puisse imaginer.
je suis plutot d'accord ; magic_quote_gpc n'est pas la panacée. Ce qu'il faut c'est une fonction spécialisée pour chaque SGBD et par type de données manipulées.
ex :
mysql_quote_string($var); mysql_quote_int($var);
j'ai pas l'impression que la fonction sans le type soit suffisante. Il reste d'autres types (enum, bool).
qu'en pensez vous ?
Patrick Mevzek wrote:
- avec cette petite astuce, il devient difficile de faire de l'injection SQL.
Ah ca y est, ca recommence. Ca faisait longtemps que cette (fausse) idée
n'était pas revenue...
si tu veux faire la synthèse ou nous passer une adresse.
Même avec magic_quotes on peut faire des injections SQL. Ca dépend des
requêtes, de la façon dont le programme travaille et du SGBDR.
Utiliser magic_quotes pour régler ce problème est une mauvaise façon de
penser. De celle qui donne une impression de sécurité à la place de la
sécurité, bref la pire chose qu'on puisse imaginer.
je suis plutot d'accord ; magic_quote_gpc n'est pas la panacée. Ce
qu'il faut c'est une fonction spécialisée pour chaque SGBD et par
type de données manipulées.
ex :
mysql_quote_string($var);
mysql_quote_int($var);
j'ai pas l'impression que la fonction sans le type soit suffisante. Il
reste d'autres types (enum, bool).
- avec cette petite astuce, il devient difficile de faire de l'injection SQL.
Ah ca y est, ca recommence. Ca faisait longtemps que cette (fausse) idée n'était pas revenue...
si tu veux faire la synthèse ou nous passer une adresse.
Même avec magic_quotes on peut faire des injections SQL. Ca dépend des requêtes, de la façon dont le programme travaille et du SGBDR.
Utiliser magic_quotes pour régler ce problème est une mauvaise façon de penser. De celle qui donne une impression de sécurité à la place de la sécurité, bref la pire chose qu'on puisse imaginer.
je suis plutot d'accord ; magic_quote_gpc n'est pas la panacée. Ce qu'il faut c'est une fonction spécialisée pour chaque SGBD et par type de données manipulées.
ex :
mysql_quote_string($var); mysql_quote_int($var);
j'ai pas l'impression que la fonction sans le type soit suffisante. Il reste d'autres types (enum, bool).
qu'en pensez vous ?
Patrick Mevzek
Ah ca y est, ca recommence. Ca faisait longtemps que cette (fausse) idée n'était pas revenue...
si tu veux faire la synthèse ou nous passer une adresse.
Il me semble que ca a été répété des milliers de fois dans les archives ici (ou je mélange avec un autre groupe), et c'est dans tous les (bons) cours. En septembre à la mairie de Paris par exemple :-)
Alternativement, pour les anglophones, j'ai cette très bonne référence : Innocent Code : A Security Wake-Up Call for Web Programmers Sverre H. Huseby Publisher: John Wiley & Sons (February 5, 2004) ISBN: 0470857447
Même si je ne suis pas d'accord avec absolument tout, c'est un excellent traité, uniquement consacré à la sécurité, qui est malheureusement trop souvent reléguée dans les appendices des livres, ou dans les 10 minutes avant de livrer un programme au client.
Il manquerait juste un bouquin qui détaille plus la façon de penser, vue rarement, qui part du postulat que ce sont les fusions de contexte qui génèrent les failles. Sur un plan théorique, je pense que ca permettrait d'expliquer pas mal de choses (déjà toutes les injections).
Même avec magic_quotes on peut faire des injections SQL. Ca dépend des requêtes, de la façon dont le programme travaille et du SGBDR.
Utiliser magic_quotes pour régler ce problème est une mauvaise façon de penser. De celle qui donne une impression de sécurité à la place de la sécurité, bref la pire chose qu'on puisse imaginer.
je suis plutot d'accord ; magic_quote_gpc n'est pas la panacée. Ce qu'il faut c'est une fonction spécialisée pour chaque SGBD et par type de données manipulées.
Mais non (sauf si fonction par type de données manipulées = filtrage sur le type comme je le décris plus bas)
D'une main: SELECT 1 FROM acl WHERE is_admin=TRUE AND user_id=$id De l'autre: $id='0 OR 1'
La chaîne «0 OR 1» ne sera jamais modifiée par aucun magic_quotes, addslashes, jeprotegedelamortquitue, car il n'y aucun caractère «suspicieux» dedans. Il n'en reste pas moins que la fusion des deux entraîne une injection SQL. Et non, je court-circuite tout de suite : la solution n'est pas la réécriture de la requête SQL.
Les vraies bonnes pratiques sont 1) filtrer, filtrer, filtrer sur le format/longueur/cohérence (ici: vérifier que $id est un entier, ce qu'on peut faire dans tout langage de programmation)
2) utiliser les «prepared statements»
3) utiliser une bibliothèque d'abstraction qui fait le quote() comme il faut pour vous, pour le bon SGBDR.
2) tout seul suffit normalement, sauf si le SGBDR ne supporte pas et que c'est émulé par la bibliothèque, auquel cas il vaut mieux espérer qu'elle tienne la route et que 3) soit au point. Quant à 1), il permet déjà de virer tous les cas triviaux et d'éviter de déranger le SGBDR pour rien. Mais il est redondant si 2) fonctionne correctement (si ce n'est sur la longueur, pour éviter d'envoyer 100Mo au SGBDR pour rien...), cependant les bases de la sécurité veulent qu'on ait toujours plusieurs lignes de défense.
-- 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>
Ah ca y est, ca recommence. Ca faisait longtemps que cette (fausse) idée
n'était pas revenue...
si tu veux faire la synthèse ou nous passer une adresse.
Il me semble que ca a été répété des milliers de fois dans les archives
ici (ou je mélange avec un autre groupe), et c'est dans tous les (bons)
cours. En septembre à la mairie de Paris par exemple :-)
Alternativement, pour les anglophones, j'ai cette très
bonne référence :
Innocent Code : A Security Wake-Up Call for Web Programmers
Sverre H. Huseby
Publisher: John Wiley & Sons (February 5, 2004)
ISBN: 0470857447
Même si je ne suis pas d'accord avec absolument tout, c'est un excellent
traité, uniquement consacré à la sécurité, qui est malheureusement
trop souvent reléguée dans les appendices des livres, ou dans les 10
minutes avant de livrer un programme au client.
Il manquerait juste un bouquin qui détaille plus la façon de penser,
vue rarement, qui part du postulat que ce sont les fusions de contexte qui
génèrent les failles. Sur un plan théorique, je pense que ca
permettrait d'expliquer pas mal de choses (déjà toutes les injections).
Même avec magic_quotes on peut faire des injections SQL. Ca dépend
des requêtes, de la façon dont le programme travaille et du SGBDR.
Utiliser magic_quotes pour régler ce problème est une mauvaise façon
de penser. De celle qui donne une impression de sécurité à la place
de la sécurité, bref la pire chose qu'on puisse imaginer.
je suis plutot d'accord ; magic_quote_gpc n'est pas la panacée. Ce
qu'il faut c'est une fonction spécialisée pour chaque SGBD et par type
de données manipulées.
Mais non (sauf si fonction par type de données manipulées = filtrage sur
le type comme je le décris plus bas)
D'une main:
SELECT 1 FROM acl WHERE is_admin=TRUE AND user_id=$id
De l'autre:
$id='0 OR 1'
La chaîne «0 OR 1» ne sera jamais modifiée par aucun magic_quotes,
addslashes, jeprotegedelamortquitue, car il n'y aucun caractère
«suspicieux» dedans.
Il n'en reste pas moins que la fusion des deux entraîne une injection SQL.
Et non, je court-circuite tout de suite : la solution n'est pas la
réécriture de la requête SQL.
Les vraies bonnes pratiques sont
1) filtrer, filtrer, filtrer sur le format/longueur/cohérence
(ici: vérifier que $id est un entier, ce qu'on peut faire dans tout
langage de programmation)
2) utiliser les «prepared statements»
3) utiliser une bibliothèque d'abstraction qui fait le quote() comme il
faut pour vous, pour le bon SGBDR.
2) tout seul suffit normalement, sauf si le SGBDR ne supporte pas et que
c'est émulé par la bibliothèque, auquel cas il vaut mieux espérer
qu'elle tienne la route et que 3) soit au point.
Quant à 1), il permet déjà de virer tous les cas triviaux et d'éviter
de déranger le SGBDR pour rien. Mais il est redondant si 2) fonctionne
correctement (si ce n'est sur la longueur, pour éviter d'envoyer 100Mo au
SGBDR pour rien...), cependant les bases de la sécurité veulent qu'on
ait toujours plusieurs lignes de défense.
--
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>
Ah ca y est, ca recommence. Ca faisait longtemps que cette (fausse) idée n'était pas revenue...
si tu veux faire la synthèse ou nous passer une adresse.
Il me semble que ca a été répété des milliers de fois dans les archives ici (ou je mélange avec un autre groupe), et c'est dans tous les (bons) cours. En septembre à la mairie de Paris par exemple :-)
Alternativement, pour les anglophones, j'ai cette très bonne référence : Innocent Code : A Security Wake-Up Call for Web Programmers Sverre H. Huseby Publisher: John Wiley & Sons (February 5, 2004) ISBN: 0470857447
Même si je ne suis pas d'accord avec absolument tout, c'est un excellent traité, uniquement consacré à la sécurité, qui est malheureusement trop souvent reléguée dans les appendices des livres, ou dans les 10 minutes avant de livrer un programme au client.
Il manquerait juste un bouquin qui détaille plus la façon de penser, vue rarement, qui part du postulat que ce sont les fusions de contexte qui génèrent les failles. Sur un plan théorique, je pense que ca permettrait d'expliquer pas mal de choses (déjà toutes les injections).
Même avec magic_quotes on peut faire des injections SQL. Ca dépend des requêtes, de la façon dont le programme travaille et du SGBDR.
Utiliser magic_quotes pour régler ce problème est une mauvaise façon de penser. De celle qui donne une impression de sécurité à la place de la sécurité, bref la pire chose qu'on puisse imaginer.
je suis plutot d'accord ; magic_quote_gpc n'est pas la panacée. Ce qu'il faut c'est une fonction spécialisée pour chaque SGBD et par type de données manipulées.
Mais non (sauf si fonction par type de données manipulées = filtrage sur le type comme je le décris plus bas)
D'une main: SELECT 1 FROM acl WHERE is_admin=TRUE AND user_id=$id De l'autre: $id='0 OR 1'
La chaîne «0 OR 1» ne sera jamais modifiée par aucun magic_quotes, addslashes, jeprotegedelamortquitue, car il n'y aucun caractère «suspicieux» dedans. Il n'en reste pas moins que la fusion des deux entraîne une injection SQL. Et non, je court-circuite tout de suite : la solution n'est pas la réécriture de la requête SQL.
Les vraies bonnes pratiques sont 1) filtrer, filtrer, filtrer sur le format/longueur/cohérence (ici: vérifier que $id est un entier, ce qu'on peut faire dans tout langage de programmation)
2) utiliser les «prepared statements»
3) utiliser une bibliothèque d'abstraction qui fait le quote() comme il faut pour vous, pour le bon SGBDR.
2) tout seul suffit normalement, sauf si le SGBDR ne supporte pas et que c'est émulé par la bibliothèque, auquel cas il vaut mieux espérer qu'elle tienne la route et que 3) soit au point. Quant à 1), il permet déjà de virer tous les cas triviaux et d'éviter de déranger le SGBDR pour rien. Mais il est redondant si 2) fonctionne correctement (si ce n'est sur la longueur, pour éviter d'envoyer 100Mo au SGBDR pour rien...), cependant les bases de la sécurité veulent qu'on ait toujours plusieurs lignes de défense.
-- 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>
