vrai formaire de mail

[FiLH]

Bonjour

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

[Olivier Miakinen]

Post by FiLH
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,

[Jean-Francois Ortolo]

Post by 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...
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

[Olivier Miakinen]

Post by Jean-Francois Ortolo

Post by 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.

[Jean-Francois Ortolo]

Post by Olivier Miakinen
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

[Antoine Polatouche]

Post by Olivier Miakinen
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

[Olivier Miakinen]

Post by Antoine Polatouche

Post by Olivier Miakinen
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]

Post by 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

Post by Olivier Miakinen
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():

http://www.php-security.org/MOPB/MOPB-34-2007.html
http://www.php-security.org/MOPB/MOPB-33-2007.html

Post by Olivier Miakinen
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]

Post by Antoine Polatouche

Post by 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

Post by Olivier Miakinen
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
http://www.php-security.org/MOPB/MOPB-34-2007.html
http://www.php-security.org/MOPB/MOPB-33-2007.html

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.

Post by Antoine Polatouche

Post by Olivier Miakinen
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 .

Post by Antoine Polatouche
l'idée ne me
serait même pas venue d'y mettre quelque chose venant d'un utilisateur! ;-)

Exemple (à ne *surtout* *pas* suivre) :

$add_headers = "MIME-Version: 1.0\n";
$add_headers .= "Content-Type: text/plain; charset=UTF-8\n";
$add_headers .= "Content-Transfer-Encoding: 8bit\n";
$add_headers .= "From: " . $_REQUEST['from'] . "\n";

Et paf !

[Eric Vialle]

Post by FiLH
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

[FiLH]

Post by Eric Vialle

Post by FiLH
Quelqu'un a l"adresse d'un vrai formulaire mail - avec les bonnes vérifs
- en php ?

Salut!

http://www.phpscripts-fr.net/scripts/scripts.php?cat=Formulaires+%2F+Ema
il

Post by Eric Vialle
Ou encore http://www.hotscripts.com/PHP/ ...
Je pense que tu trouveras ton bonheur...

Je vais aller voir merci

FiLH