Quelqu'un a l"adresse d'un vrai formulaire mail - avec les bonnes vérifs
- en php ?
C'est pour un pote un peu débutant... et j'ai moyen le temps de lui en
faire un bien avec tout et tout.
FiLH
--
Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire
une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle.
Roland Barthes.
http://www.filh.org
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Olivier Miakinen
Quelqu'un a l"adresse d'un vrai formulaire mail - avec les bonnes vérifs - en php ?
Je n'en connais pas, mais voici les points essentiels à mon avis.
Tout d'abord, rappelons la syntaxe de la fonction mail : <cit. http://fr.php.net/manual/fr/function.mail.php> bool mail ( string to, string subject, string message [, string additional_headers [, string additional_parameters]] ) </cit.>
Les paramètres les plus dangereux à utiliser sont /to/, /subject/ et /additional_headers/ car, une fois détournés de leur fonction initiale, ils permettent d'ajouter des milliers d'adresses de destinataires, plus des entêtes MIME/Multipart, et enfin le message du spammeur, en cachant même le contenu du paramètre /message/.
Pour ces paramètres, il faut donc mettre une chaîne statique autant que possible. Si ce n'est pas possible et qu'il faut vraiment qu'une donnée vienne de l'utilisateur, alors la moindre des vérifications est que ce qui vient de l'utilisateur ne contienne aucun saut de ligne (r ou n), mais tu peux même vérifier qu'il n'y ait que des caractères ASCII compris entre l'espace et le tilde. Les caractères non-ASCII (éèàç etc.) sont censés être encodés, mais je n'ai pas de fonction toute prête pour faire ça.
Sinon, pour éviter des exploits dûs à des bugs, il serait bon de vérifier aussi, dans les entêtes comme dans le message lui-même, qu'aucune ligne ne dépasse 998 caractères...
Cordialement, -- Olivier Miakinen
Quelqu'un a l"adresse d'un vrai formulaire mail - avec les bonnes vérifs
- en php ?
Je n'en connais pas, mais voici les points essentiels à mon avis.
Tout d'abord, rappelons la syntaxe de la fonction mail :
<cit. http://fr.php.net/manual/fr/function.mail.php>
bool mail ( string to, string subject, string message [, string
additional_headers [, string additional_parameters]] )
</cit.>
Les paramètres les plus dangereux à utiliser sont /to/, /subject/ et
/additional_headers/ car, une fois détournés de leur fonction initiale,
ils permettent d'ajouter des milliers d'adresses de destinataires, plus
des entêtes MIME/Multipart, et enfin le message du spammeur, en cachant
même le contenu du paramètre /message/.
Pour ces paramètres, il faut donc mettre une chaîne statique autant que
possible. Si ce n'est pas possible et qu'il faut vraiment qu'une donnée
vienne de l'utilisateur, alors la moindre des vérifications est que ce
qui vient de l'utilisateur ne contienne aucun saut de ligne (r ou n),
mais tu peux même vérifier qu'il n'y ait que des caractères ASCII
compris entre l'espace et le tilde. Les caractères non-ASCII (éèàç etc.)
sont censés être encodés, mais je n'ai pas de fonction toute prête pour
faire ça.
Sinon, pour éviter des exploits dûs à des bugs, il serait bon de
vérifier aussi, dans les entêtes comme dans le message lui-même,
qu'aucune ligne ne dépasse 998 caractères...
Quelqu'un a l"adresse d'un vrai formulaire mail - avec les bonnes vérifs - en php ?
Je n'en connais pas, mais voici les points essentiels à mon avis.
Tout d'abord, rappelons la syntaxe de la fonction mail : <cit. http://fr.php.net/manual/fr/function.mail.php> bool mail ( string to, string subject, string message [, string additional_headers [, string additional_parameters]] ) </cit.>
Les paramètres les plus dangereux à utiliser sont /to/, /subject/ et /additional_headers/ car, une fois détournés de leur fonction initiale, ils permettent d'ajouter des milliers d'adresses de destinataires, plus des entêtes MIME/Multipart, et enfin le message du spammeur, en cachant même le contenu du paramètre /message/.
Pour ces paramètres, il faut donc mettre une chaîne statique autant que possible. Si ce n'est pas possible et qu'il faut vraiment qu'une donnée vienne de l'utilisateur, alors la moindre des vérifications est que ce qui vient de l'utilisateur ne contienne aucun saut de ligne (r ou n), mais tu peux même vérifier qu'il n'y ait que des caractères ASCII compris entre l'espace et le tilde. Les caractères non-ASCII (éèàç etc.) sont censés être encodés, mais je n'ai pas de fonction toute prête pour faire ça.
Sinon, pour éviter des exploits dûs à des bugs, il serait bon de vérifier aussi, dans les entêtes comme dans le message lui-même, qu'aucune ligne ne dépasse 998 caractères...
Cordialement, -- Olivier Miakinen
Jean-Francois Ortolo
Olivier Miakinen wrote:
Sinon, pour éviter des exploits dûs à des bugs, il serait bon de vérifier aussi, dans les entêtes comme dans le message lui-même, qu'aucune ligne ne dépasse 998 caractères...
Cordialement,
Bonjour Monsieur
Je croyais avoir lu dans le PHP Manual, que le corps du message ne devait pas comporter de lignes de plus de 72 caractères ?
Merci beaucoup de votre réponse.
Bien à vous. Amicalement.
Jean-François Ortolo
-- Visitez mon site gratuit donnant des Statistiques et des Historiques Graphiques sur les Courses de Chevaux: http://www.ortolojf-courses.com
Olivier Miakinen wrote:
Sinon, pour éviter des exploits dûs à des bugs, il serait bon de
vérifier aussi, dans les entêtes comme dans le message lui-même,
qu'aucune ligne ne dépasse 998 caractères...
Cordialement,
Bonjour Monsieur
Je croyais avoir lu dans le PHP Manual, que le corps du message ne
devait pas comporter de lignes de plus de 72 caractères ?
Merci beaucoup de votre réponse.
Bien à vous.
Amicalement.
Jean-François Ortolo
--
Visitez mon site gratuit donnant des Statistiques
et des Historiques Graphiques sur les Courses de Chevaux:
http://www.ortolojf-courses.com
Sinon, pour éviter des exploits dûs à des bugs, il serait bon de vérifier aussi, dans les entêtes comme dans le message lui-même, qu'aucune ligne ne dépasse 998 caractères...
Cordialement,
Bonjour Monsieur
Je croyais avoir lu dans le PHP Manual, que le corps du message ne devait pas comporter de lignes de plus de 72 caractères ?
Merci beaucoup de votre réponse.
Bien à vous. Amicalement.
Jean-François Ortolo
-- Visitez mon site gratuit donnant des Statistiques et des Historiques Graphiques sur les Courses de Chevaux: http://www.ortolojf-courses.com
Olivier Miakinen
Sinon, pour éviter des exploits dûs à des bugs, il serait bon de vérifier aussi, dans les entêtes comme dans le message lui-même, qu'aucune ligne ne dépasse 998 caractères...
Je croyais avoir lu dans le PHP Manual, que le corps du message ne devait pas comporter de lignes de plus de 72 caractères ?
998 est la limite technique que tout courrielleur est tenu d'accepter (ça fait 1000 en comptant CR+LF). Une limite de 78 est recommandée pour la lisibilité, que l'on abaisse en général à 72 pour les nouveaux messages, ce qui permet au texte d'être cité quatre fois avec "> " sans dépasser la limite conseillée. Mais ces limites de 78 et 72 n'ont rien d'obligatoire, et par exemple pour les URL il vaut mieux les laisser sur une seule ligne plutôt que les couper sauvagement comme le font certains proto-courrielleurs.
Sinon, pour éviter des exploits dûs à des bugs, il serait bon de
vérifier aussi, dans les entêtes comme dans le message lui-même,
qu'aucune ligne ne dépasse 998 caractères...
Je croyais avoir lu dans le PHP Manual, que le corps du message ne
devait pas comporter de lignes de plus de 72 caractères ?
998 est la limite technique que tout courrielleur est tenu d'accepter
(ça fait 1000 en comptant CR+LF). Une limite de 78 est recommandée pour
la lisibilité, que l'on abaisse en général à 72 pour les nouveaux
messages, ce qui permet au texte d'être cité quatre fois avec "> " sans
dépasser la limite conseillée. Mais ces limites de 78 et 72 n'ont rien
d'obligatoire, et par exemple pour les URL il vaut mieux les laisser sur
une seule ligne plutôt que les couper sauvagement comme le font certains
proto-courrielleurs.
Sinon, pour éviter des exploits dûs à des bugs, il serait bon de vérifier aussi, dans les entêtes comme dans le message lui-même, qu'aucune ligne ne dépasse 998 caractères...
Je croyais avoir lu dans le PHP Manual, que le corps du message ne devait pas comporter de lignes de plus de 72 caractères ?
998 est la limite technique que tout courrielleur est tenu d'accepter (ça fait 1000 en comptant CR+LF). Une limite de 78 est recommandée pour la lisibilité, que l'on abaisse en général à 72 pour les nouveaux messages, ce qui permet au texte d'être cité quatre fois avec "> " sans dépasser la limite conseillée. Mais ces limites de 78 et 72 n'ont rien d'obligatoire, et par exemple pour les URL il vaut mieux les laisser sur une seule ligne plutôt que les couper sauvagement comme le font certains proto-courrielleurs.
Jean-Francois Ortolo
Olivier Miakinen wrote:
998 est la limite technique que tout courrielleur est tenu d'accepter (ça fait 1000 en comptant CR+LF). Une limite de 78 est recommandée pour la lisibilité, que l'on abaisse en général à 72 pour les nouveaux messages, ce qui permet au texte d'être cité quatre fois avec "> " sans dépasser la limite conseillée. Mais ces limites de 78 et 72 n'ont rien d'obligatoire, et par exemple pour les URL il vaut mieux les laisser sur une seule ligne plutôt que les couper sauvagement comme le font certains proto-courrielleurs.
Bonjour Monsieur
Oki oki, merci beaucoup de votre avis.
Donc, cette limite de confort, ne serait due qu'au problème du client de messagerie récepteur, et non pas à la fonction mail(), dont il est vrai qu'on peut s'attendre, à ce qu'elle puisse contenir un peu n'importe quoi, de manière permissive.
C'est bon à savoir, surtout du fait que, quand le contenu d'une balise <textarea> est envoyé par la fonction mail(), j'ai constaté qu'il fallait laisser le texte tel quel, pour que son formattage soit respecté.
Si on se met à supprimer les n ou les r dans ce contenu, ça fout le souk.
Donc, je n'ai plus de regret pour le traitement des formulaires.
Génial, je commence enfin à avoir une petit expertise ( toute petite ), dans l'envoi automatisé des emails sur le web.
Me resterait à savoir comment envoyer des plâtrées d'emails, soit en grand nombre, soit à un grand nombre d'emails, mais c'est toujours risqué, quand l'hébergeur a une politique sécuritaire...
J'ai lu sur le PHP Manual, que la librairie Pear permet celà, mais je n'ai jamais réellement essayé ( pas de besoin pratique ), et je n'ai même pas regardé précisément l'utilisation de cette librairie.
Quand je pense à tout ce que je ne sais pas en PHP... ;)
Merci beaucoup pour votre réponse.
Bien à vous. Amicalement.
Jean-François Ortolo
-- Visitez mon site gratuit donnant des Statistiques et des Historiques Graphiques sur les Courses de Chevaux: http://www.ortolojf-courses.com
Olivier Miakinen wrote:
998 est la limite technique que tout courrielleur est tenu d'accepter
(ça fait 1000 en comptant CR+LF). Une limite de 78 est recommandée pour
la lisibilité, que l'on abaisse en général à 72 pour les nouveaux
messages, ce qui permet au texte d'être cité quatre fois avec "> " sans
dépasser la limite conseillée. Mais ces limites de 78 et 72 n'ont rien
d'obligatoire, et par exemple pour les URL il vaut mieux les laisser sur
une seule ligne plutôt que les couper sauvagement comme le font certains
proto-courrielleurs.
Bonjour Monsieur
Oki oki, merci beaucoup de votre avis.
Donc, cette limite de confort, ne serait due qu'au problème du client
de messagerie récepteur, et non pas à la fonction mail(), dont il est
vrai qu'on peut s'attendre, à ce qu'elle puisse contenir un peu
n'importe quoi, de manière permissive.
C'est bon à savoir, surtout du fait que, quand le contenu d'une
balise <textarea> est envoyé par la fonction mail(), j'ai constaté qu'il
fallait laisser le texte tel quel, pour que son formattage soit respecté.
Si on se met à supprimer les n ou les r dans ce contenu, ça fout le
souk.
Donc, je n'ai plus de regret pour le traitement des formulaires.
Génial, je commence enfin à avoir une petit expertise ( toute petite
), dans l'envoi automatisé des emails sur le web.
Me resterait à savoir comment envoyer des plâtrées d'emails, soit en
grand nombre, soit à un grand nombre d'emails, mais c'est toujours
risqué, quand l'hébergeur a une politique sécuritaire...
J'ai lu sur le PHP Manual, que la librairie Pear permet celà, mais je
n'ai jamais réellement essayé ( pas de besoin pratique ), et je n'ai
même pas regardé précisément l'utilisation de cette librairie.
Quand je pense à tout ce que je ne sais pas en PHP... ;)
Merci beaucoup pour votre réponse.
Bien à vous.
Amicalement.
Jean-François Ortolo
--
Visitez mon site gratuit donnant des Statistiques
et des Historiques Graphiques sur les Courses de Chevaux:
http://www.ortolojf-courses.com
998 est la limite technique que tout courrielleur est tenu d'accepter (ça fait 1000 en comptant CR+LF). Une limite de 78 est recommandée pour la lisibilité, que l'on abaisse en général à 72 pour les nouveaux messages, ce qui permet au texte d'être cité quatre fois avec "> " sans dépasser la limite conseillée. Mais ces limites de 78 et 72 n'ont rien d'obligatoire, et par exemple pour les URL il vaut mieux les laisser sur une seule ligne plutôt que les couper sauvagement comme le font certains proto-courrielleurs.
Bonjour Monsieur
Oki oki, merci beaucoup de votre avis.
Donc, cette limite de confort, ne serait due qu'au problème du client de messagerie récepteur, et non pas à la fonction mail(), dont il est vrai qu'on peut s'attendre, à ce qu'elle puisse contenir un peu n'importe quoi, de manière permissive.
C'est bon à savoir, surtout du fait que, quand le contenu d'une balise <textarea> est envoyé par la fonction mail(), j'ai constaté qu'il fallait laisser le texte tel quel, pour que son formattage soit respecté.
Si on se met à supprimer les n ou les r dans ce contenu, ça fout le souk.
Donc, je n'ai plus de regret pour le traitement des formulaires.
Génial, je commence enfin à avoir une petit expertise ( toute petite ), dans l'envoi automatisé des emails sur le web.
Me resterait à savoir comment envoyer des plâtrées d'emails, soit en grand nombre, soit à un grand nombre d'emails, mais c'est toujours risqué, quand l'hébergeur a une politique sécuritaire...
J'ai lu sur le PHP Manual, que la librairie Pear permet celà, mais je n'ai jamais réellement essayé ( pas de besoin pratique ), et je n'ai même pas regardé précisément l'utilisation de cette librairie.
Quand je pense à tout ce que je ne sais pas en PHP... ;)
Merci beaucoup pour votre réponse.
Bien à vous. Amicalement.
Jean-François Ortolo
-- Visitez mon site gratuit donnant des Statistiques et des Historiques Graphiques sur les Courses de Chevaux: http://www.ortolojf-courses.com
Eric Vialle
On 20 juin, 06:13, (FiLH) wrote:
Quelqu'un a l"adresse d'un vrai formulaire mail - avec les bonnes vérifs - en php ?
Salut!
Es tu allé voir le site: http://www.phpscripts-fr.net/scripts/scripts.php?cat=Formulaires+%2F+Email Ou encore http://www.hotscripts.com/PHP/ ...
Je pense que tu trouveras ton bonheur...
Eric
On 20 juin, 06:13, f...@filh.orgie (FiLH) wrote:
Quelqu'un a l"adresse d'un vrai formulaire mail - avec les bonnes vérifs
- en php ?
Salut!
Es tu allé voir le site: http://www.phpscripts-fr.net/scripts/scripts.php?cat=Formulaires+%2F+Email
Ou encore http://www.hotscripts.com/PHP/ ...
Quelqu'un a l"adresse d'un vrai formulaire mail - avec les bonnes vérifs - en php ?
Salut!
Es tu allé voir le site: http://www.phpscripts-fr.net/scripts/scripts.php?cat=Formulaires+%2F+Email Ou encore http://www.hotscripts.com/PHP/ ...
Je pense que tu trouveras ton bonheur...
Eric
Antoine Polatouche
Les paramètres les plus dangereux à utiliser sont /to/, /subject/ et /additional_headers/ car, une fois détournés de leur fonction initiale, ils permettent d'ajouter des milliers d'adresses de destinataires, plus des entêtes MIME/Multipart, et enfin le message du spammeur, en cachant même le contenu du paramètre /message/.
Vrai pour les versions de php: PHP 4 <= 4.4.6 et PHP 5 <= 5.2.1
Les paramètres les plus dangereux à utiliser sont /to/, /subject/ et
/additional_headers/ car, une fois détournés de leur fonction initiale,
ils permettent d'ajouter des milliers d'adresses de destinataires, plus
des entêtes MIME/Multipart, et enfin le message du spammeur, en cachant
même le contenu du paramètre /message/.
Vrai pour les versions de php: PHP 4 <= 4.4.6 et PHP 5 <= 5.2.1
Les paramètres les plus dangereux à utiliser sont /to/, /subject/ et /additional_headers/ car, une fois détournés de leur fonction initiale, ils permettent d'ajouter des milliers d'adresses de destinataires, plus des entêtes MIME/Multipart, et enfin le message du spammeur, en cachant même le contenu du paramètre /message/.
Vrai pour les versions de php: PHP 4 <= 4.4.6 et PHP 5 <= 5.2.1
filh
Eric Vialle wrote:
On 20 juin, 06:13, (FiLH) wrote:
Quelqu'un a l"adresse d'un vrai formulaire mail - avec les bonnes vérifs - en php ?
Salut!
Es tu allé voir le site: http://www.phpscripts-fr.net/scripts/scripts.php?cat=Formulaires+%2F+Ema
il
Ou encore http://www.hotscripts.com/PHP/ ...
Je pense que tu trouveras ton bonheur...
Je vais aller voir merci
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
Eric Vialle <eric.vialle@gmail.com> wrote:
On 20 juin, 06:13, f...@filh.orgie (FiLH) wrote:
Quelqu'un a l"adresse d'un vrai formulaire mail - avec les bonnes vérifs
- en php ?
Salut!
Es tu allé voir le site:
http://www.phpscripts-fr.net/scripts/scripts.php?cat=Formulaires+%2F+Ema
il
Ou encore http://www.hotscripts.com/PHP/ ...
Je pense que tu trouveras ton bonheur...
Je vais aller voir merci
FiLH
--
Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire
une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle.
Roland Barthes.
http://www.filh.org
Quelqu'un a l"adresse d'un vrai formulaire mail - avec les bonnes vérifs - en php ?
Salut!
Es tu allé voir le site: http://www.phpscripts-fr.net/scripts/scripts.php?cat=Formulaires+%2F+Ema
il
Ou encore http://www.hotscripts.com/PHP/ ...
Je pense que tu trouveras ton bonheur...
Je vais aller voir merci
FiLH
-- Le fondement du constat bourgeois, c'est le bon sens, c'est-à-dire une vérité qui s'arrête sur l'ordre arbitraire de celui qui la parle. Roland Barthes. http://www.filh.org
Olivier Miakinen
Le 20/06/2007 18:40, Antoine Polatouche m'a répondu :
Les paramètres les plus dangereux à utiliser sont /to/, /subject/ et /additional_headers/ car, une fois détournés de leur fonction initiale, ils permettent d'ajouter des milliers d'adresses de destinataires, plus des entêtes MIME/Multipart, et enfin le message du spammeur, en cachant même le contenu du paramètre /message/.
Vrai pour les versions de php: PHP 4 <= 4.4.6 et PHP 5 <= 5.2.1
Je suppose que tu veux dire que c'est devenu faux pour PHP 4 > 4.4.6 et PHP 5 > 5.2.1 (donc que ces versions sont sûres), mais je ne vois rien dans la doc, y compris en anglais, à propos du changement dans ces versions. Il me semble qu'on en avait déjà parlé ici mais j'ai la mémoire qui flanche... tu peux donner des précisions ?
Ces précisions me semblent d'autant plus nécessaires que, même si je vois assez facilement quel genre de vérification ils ont pu faire pour les paramètres /to/ et /subject/, je ne vois pas comment il serait possible de « sécuriser » /additional_headers/ sans couper à la hache dans les fonctionnalités !
Le 20/06/2007 18:40, Antoine Polatouche m'a répondu :
Les paramètres les plus dangereux à utiliser sont /to/, /subject/ et
/additional_headers/ car, une fois détournés de leur fonction initiale,
ils permettent d'ajouter des milliers d'adresses de destinataires, plus
des entêtes MIME/Multipart, et enfin le message du spammeur, en cachant
même le contenu du paramètre /message/.
Vrai pour les versions de php: PHP 4 <= 4.4.6 et PHP 5 <= 5.2.1
Je suppose que tu veux dire que c'est devenu faux pour PHP 4 > 4.4.6 et
PHP 5 > 5.2.1 (donc que ces versions sont sûres), mais je ne vois rien
dans la doc, y compris en anglais, à propos du changement dans ces
versions. Il me semble qu'on en avait déjà parlé ici mais j'ai la
mémoire qui flanche... tu peux donner des précisions ?
Ces précisions me semblent d'autant plus nécessaires que, même si je
vois assez facilement quel genre de vérification ils ont pu faire pour
les paramètres /to/ et /subject/, je ne vois pas comment il serait
possible de « sécuriser » /additional_headers/ sans couper à la hache
dans les fonctionnalités !
Le 20/06/2007 18:40, Antoine Polatouche m'a répondu :
Les paramètres les plus dangereux à utiliser sont /to/, /subject/ et /additional_headers/ car, une fois détournés de leur fonction initiale, ils permettent d'ajouter des milliers d'adresses de destinataires, plus des entêtes MIME/Multipart, et enfin le message du spammeur, en cachant même le contenu du paramètre /message/.
Vrai pour les versions de php: PHP 4 <= 4.4.6 et PHP 5 <= 5.2.1
Je suppose que tu veux dire que c'est devenu faux pour PHP 4 > 4.4.6 et PHP 5 > 5.2.1 (donc que ces versions sont sûres), mais je ne vois rien dans la doc, y compris en anglais, à propos du changement dans ces versions. Il me semble qu'on en avait déjà parlé ici mais j'ai la mémoire qui flanche... tu peux donner des précisions ?
Ces précisions me semblent d'autant plus nécessaires que, même si je vois assez facilement quel genre de vérification ils ont pu faire pour les paramètres /to/ et /subject/, je ne vois pas comment il serait possible de « sécuriser » /additional_headers/ sans couper à la hache dans les fonctionnalités !
Antoine Polatouche
Je suppose que tu veux dire que c'est devenu faux pour PHP 4 > 4.4.6 et PHP 5 > 5.2.1 (donc que ces versions sont sûres),
oui
mais je ne vois rien dans la doc, y compris en anglais, à propos du changement dans ces versions. Il me semble qu'on en avait déjà parlé ici mais j'ai la mémoire qui flanche... tu peux donner des précisions ?
j'ai trouvé ça après de vaines tentatives pour voir comment mettre à mal la fonction mail():
Ces précisions me semblent d'autant plus nécessaires que, même si je vois assez facilement quel genre de vérification ils ont pu faire pour les paramètres /to/ et /subject/, je ne vois pas comment il serait possible de « sécuriser » /additional_headers/ sans couper à la hache dans les fonctionnalités !
Je ne sais pas si les additional_headers ont été sécurisés, l'idée ne me serait même pas venue d'y mettre quelquechose venant d'un utilisateur! ;-)
Je suppose que tu veux dire que c'est devenu faux pour PHP 4 > 4.4.6 et
PHP 5 > 5.2.1 (donc que ces versions sont sûres),
oui
mais je ne vois rien
dans la doc, y compris en anglais, à propos du changement dans ces
versions. Il me semble qu'on en avait déjà parlé ici mais j'ai la
mémoire qui flanche... tu peux donner des précisions ?
j'ai trouvé ça après de vaines tentatives pour voir comment mettre à mal
la fonction mail():
Ces précisions me semblent d'autant plus nécessaires que, même si je
vois assez facilement quel genre de vérification ils ont pu faire pour
les paramètres /to/ et /subject/, je ne vois pas comment il serait
possible de « sécuriser » /additional_headers/ sans couper à la hache
dans les fonctionnalités !
Je ne sais pas si les additional_headers ont été sécurisés, l'idée ne me
serait même pas venue d'y mettre quelquechose venant d'un utilisateur! ;-)
Je suppose que tu veux dire que c'est devenu faux pour PHP 4 > 4.4.6 et PHP 5 > 5.2.1 (donc que ces versions sont sûres),
oui
mais je ne vois rien dans la doc, y compris en anglais, à propos du changement dans ces versions. Il me semble qu'on en avait déjà parlé ici mais j'ai la mémoire qui flanche... tu peux donner des précisions ?
j'ai trouvé ça après de vaines tentatives pour voir comment mettre à mal la fonction mail():
Ces précisions me semblent d'autant plus nécessaires que, même si je vois assez facilement quel genre de vérification ils ont pu faire pour les paramètres /to/ et /subject/, je ne vois pas comment il serait possible de « sécuriser » /additional_headers/ sans couper à la hache dans les fonctionnalités !
Je ne sais pas si les additional_headers ont été sécurisés, l'idée ne me serait même pas venue d'y mettre quelquechose venant d'un utilisateur! ;-)
Olivier Miakinen
Je suppose que tu veux dire que c'est devenu faux pour PHP 4 > 4.4.6 et PHP 5 > 5.2.1 (donc que ces versions sont sûres),
oui
mais je ne vois rien dans la doc, y compris en anglais, à propos du changement dans ces versions. Il me semble qu'on en avait déjà parlé ici mais j'ai la mémoire qui flanche... tu peux donner des précisions ?
j'ai trouvé ça après de vaines tentatives pour voir comment mettre à mal la fonction mail():
Merci. Tous deux indiquent des failles dont je ne vois pas si elles ont été ou non corrigées, mais le premier lien (MOPB-34-2007) montre bien que quelque chose effectivement a déjà été fait pour les paramètres To et Subject.
Ces précisions me semblent d'autant plus nécessaires que, même si je vois assez facilement quel genre de vérification ils ont pu faire pour les paramètres /to/ et /subject/, je ne vois pas comment il serait possible de « sécuriser » /additional_headers/ sans couper à la hache dans les fonctionnalités !
Je ne sais pas si les additional_headers ont été sécurisés,
Comme je le disais, par nature il est impossible d'interdire d'y mettre plusieurs entêtes puisque justement c'est fait pour gérer tous les entêtes autres que To et Subject. Par exemple, pour un message autre qu'en "text/plain; charset=us-ascii", il faut au moins trois entêtes pour MIME. Plus un pour le From si ce n'est pas celui renseigné dans le fichier .ini .
l'idée ne me serait même pas venue d'y mettre quelque chose venant d'un utilisateur! ;-)
Je suppose que tu veux dire que c'est devenu faux pour PHP 4 > 4.4.6 et
PHP 5 > 5.2.1 (donc que ces versions sont sûres),
oui
mais je ne vois rien
dans la doc, y compris en anglais, à propos du changement dans ces
versions. Il me semble qu'on en avait déjà parlé ici mais j'ai la
mémoire qui flanche... tu peux donner des précisions ?
j'ai trouvé ça après de vaines tentatives pour voir comment mettre à mal
la fonction mail():
Merci. Tous deux indiquent des failles dont je ne vois pas si elles ont
été ou non corrigées, mais le premier lien (MOPB-34-2007) montre bien
que quelque chose effectivement a déjà été fait pour les paramètres To
et Subject.
Ces précisions me semblent d'autant plus nécessaires que, même si je
vois assez facilement quel genre de vérification ils ont pu faire pour
les paramètres /to/ et /subject/, je ne vois pas comment il serait
possible de « sécuriser » /additional_headers/ sans couper à la hache
dans les fonctionnalités !
Je ne sais pas si les additional_headers ont été sécurisés,
Comme je le disais, par nature il est impossible d'interdire d'y mettre
plusieurs entêtes puisque justement c'est fait pour gérer tous les
entêtes autres que To et Subject. Par exemple, pour un message autre
qu'en "text/plain; charset=us-ascii", il faut au moins trois entêtes
pour MIME. Plus un pour le From si ce n'est pas celui renseigné dans
le fichier .ini .
l'idée ne me
serait même pas venue d'y mettre quelque chose venant d'un utilisateur! ;-)
Je suppose que tu veux dire que c'est devenu faux pour PHP 4 > 4.4.6 et PHP 5 > 5.2.1 (donc que ces versions sont sûres),
oui
mais je ne vois rien dans la doc, y compris en anglais, à propos du changement dans ces versions. Il me semble qu'on en avait déjà parlé ici mais j'ai la mémoire qui flanche... tu peux donner des précisions ?
j'ai trouvé ça après de vaines tentatives pour voir comment mettre à mal la fonction mail():
Merci. Tous deux indiquent des failles dont je ne vois pas si elles ont été ou non corrigées, mais le premier lien (MOPB-34-2007) montre bien que quelque chose effectivement a déjà été fait pour les paramètres To et Subject.
Ces précisions me semblent d'autant plus nécessaires que, même si je vois assez facilement quel genre de vérification ils ont pu faire pour les paramètres /to/ et /subject/, je ne vois pas comment il serait possible de « sécuriser » /additional_headers/ sans couper à la hache dans les fonctionnalités !
Je ne sais pas si les additional_headers ont été sécurisés,
Comme je le disais, par nature il est impossible d'interdire d'y mettre plusieurs entêtes puisque justement c'est fait pour gérer tous les entêtes autres que To et Subject. Par exemple, pour un message autre qu'en "text/plain; charset=us-ascii", il faut au moins trois entêtes pour MIME. Plus un pour le From si ce n'est pas celui renseigné dans le fichier .ini .
l'idée ne me serait même pas venue d'y mettre quelque chose venant d'un utilisateur! ;-)
