vrai formaire de mail

Le
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

--
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
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Olivier Miakinen
Le #44729

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 :
bool mail ( string to, string subject, string message [, string
additional_headers [, string additional_parameters]] )

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
Le #44725
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
Le #44724

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
Le #44299
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

Eric Vialle
Le #44300
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

Antoine Polatouche
Le #44302
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
Le #44296
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+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 #43853
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
Le #43852
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():

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


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
Le #43851

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():

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.

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! ;-)


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

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

Et paf !


Publicité
Poster une réponse
Anonyme