je m'étais fait il y a un bon moment un petite formulaire en php pour
que des gens puissent me contacter via mon site web.
Il se trouve que ce formulaire est sans arrêt la proie de scripts qui
tentent de faire déborder les données contenus dans le champ "votre
adresse électronique", pour insérer des destinataires autres que ceux
qui sont fixés "en dûr".
En effet, si on ne fait pas gaffe, y mettre quelque chose comme :
mon@adresse.invalide\nCc: adresse@a.spammer.invalid pourrait marcher
en mettant dans l'entête courrier adresse@a.spammer.invalid comme
destinataire.
Donc je suis au courant et j'ai programmé le formulaire en
conséquence, mais...
Du coup, je reçois très fréquemment des courriers électroniques de
test à cause de gens essayant de détourner l'utilisation du
formulaire. Avec des scripts testant automatiquement le formulaire, je
suppose (ils semblent en plus rajouter un champ Bcc pour avoir un
retour sur la possibilité de détourner le formulaire).
Comme j'en ai un peu assez, je me demandais ce qui faisait, dans ce
formulaire, qu'il était la proie de scripts ?
La partie "visible" et "utile" du formulaire est la suivante ;
Le simple fait d'avoir nommé les variables "mailAuthor" et "mailBody"
peut-il suffire à attirer les scripts comme des mouches ? Et à repérer
que c'est spécifiquement dans "mailAuthor" qu'il faut faire déborder
le formulaire ?
Merci pour vos réponses et vos pistes.
C'est plus pour éviter que ces tentatives se répètent sans cesse : la
faille qu'on tente d'exploiter, elle, n'existe pas.
dans (in) fr.comp.securite, Vincent Hiribarren ecrivait (wrote) :
Bonjour,
Il se trouve que ce formulaire est sans arrêt la proie de scripts qui tentent de faire déborder les données contenus dans le champ "votre adresse électronique", pour insérer des destinataires autres que ceux qui sont fixés "en dûr".
C'est un grand classique, lié au fait que les gens programment souvent (pour rester courtois) fort mal en PHP et que l'injection de scripts dans des champs de formulaires mal contrôlés, en particulier ceux où on est sensé inscrire son adresse mail, sont pain béni pour les spammers et autres nuisibles.
En effet, si on ne fait pas gaffe, y mettre quelque chose comme :
: pourrait marcher en mettant dans l'entête courrier comme destinataire.
Première règle dans un tel champ, analyser son contenu de façon à s'assurer au minimum que :
- l'adresse inscrite est syntaxiquement correcte ; - que le champ ne peut contenir qu'une adresse mail à la fois ; - que les passages à la ligne sont interdits.
J'utilise souvent ça, mais on doit probablement pouvoir trouver mieux :
...................................................................... function verif_email($email) { // champ vide ? if ($email == "") { $err_email = "Merci d'indiquer votre adresse électronique :"; } else { if (eregi("^[_.0-9a-z-]+@([0-9a-z-]+.)+[a-z]{2,4}$",$email)) { // L'adresse email est valide et unique $err_email = ""; } else { // L'adresse email n'est pas valide, des caractères interdits // tels cr/lf y ont été introduits, etc... $err_email = "adresse invalide, vérifiez la syntaxe..."; } } return $err_email; } ......................................................................
Tu peux affiner en mettant un timer entre le moment ou le formulaire est validé et celui ou il est effectivement expédié, le fin du fin étant d'augmenter le temps de latence au fur et à mesure (du premier au 5ème mail 5 minutes, du 6ème au 10ème 10 minutes, etc) envoyés epuis la même IP. Ca permet de monitorer, de voir venir et le cas échéant de nettoyer la file d'attente avant envoi.
Du coup, je reçois très fréquemment des courriers électroniques de test à cause de gens essayant de détourner l'utilisation du formulaire. Avec des scripts testant automatiquement le formulaire, je
Oui, cf ci-dessus, c'est un des moyens les plus à la mode pour balancer du spam...
suppose (ils semblent en plus rajouter un champ Bcc pour avoir un retour sur la possibilité de détourner le formulaire).
Si ton formulaire est correctement écrit, je ne vois pas bien comment le script appelant pourrait ajouter un Bcc dans ton formulaire à l'insu de ton plein gré...
Comme j'en ai un peu assez, je me demandais ce qui faisait, dans ce formulaire, qu'il était la proie de scripts ?
La popularité de ton site ? :)
Plus sérieusement, étant hébergeur et amené à superviser les sites de mes clients, qu'ils soient en dédié ou en mutualisé, je constate que tous les formulaires permettant d'envoyer des mails sont scannés et testés en permanence à la recherche de failles permettant d'envoyer des cochonneries (spams, virus, backdoors...) pas leur intermédiaire.
C'est plus pour éviter que ces tentatives se répètent sans cesse : la faille qu'on tente d'exploiter, elle, n'existe pas.
Les robots scannent tout en permanence à la recherche de failles, tu n'y peux rien, ni personne. Assure-toi que tes formulaires sont bien protégés et arrête de lire tes logs :)
-- Eric Demeester - http://www.galacsys.net
dans (in) fr.comp.securite, Vincent Hiribarren <vynce@alea.invalid>
ecrivait (wrote) :
Bonjour,
Il se trouve que ce formulaire est sans arrêt la proie de scripts qui
tentent de faire déborder les données contenus dans le champ "votre
adresse électronique", pour insérer des destinataires autres que ceux
qui sont fixés "en dûr".
C'est un grand classique, lié au fait que les gens programment souvent
(pour rester courtois) fort mal en PHP et que l'injection de scripts
dans des champs de formulaires mal contrôlés, en particulier ceux où on
est sensé inscrire son adresse mail, sont pain béni pour les spammers et
autres nuisibles.
En effet, si on ne fait pas gaffe, y mettre quelque chose comme :
mon@adresse.invalidenCc: adresse@a.spammer.invalid pourrait marcher
en mettant dans l'entête courrier adresse@a.spammer.invalid comme
destinataire.
Première règle dans un tel champ, analyser son contenu de façon à
s'assurer au minimum que :
- l'adresse inscrite est syntaxiquement correcte ;
- que le champ ne peut contenir qu'une adresse mail à la fois ;
- que les passages à la ligne sont interdits.
J'utilise souvent ça, mais on doit probablement pouvoir trouver mieux :
......................................................................
function verif_email($email) {
// champ vide ?
if ($email == "") {
$err_email = "Merci d'indiquer votre adresse électronique :";
}
else {
if (eregi("^[_.0-9a-z-]+@([0-9a-z-]+.)+[a-z]{2,4}$",$email)) {
// L'adresse email est valide et unique
$err_email = "";
}
else {
// L'adresse email n'est pas valide, des caractères interdits
// tels cr/lf y ont été introduits, etc...
$err_email = "adresse invalide, vérifiez la syntaxe...";
}
}
return $err_email;
}
......................................................................
Tu peux affiner en mettant un timer entre le moment ou le formulaire est
validé et celui ou il est effectivement expédié, le fin du fin étant
d'augmenter le temps de latence au fur et à mesure (du premier au 5ème
mail 5 minutes, du 6ème au 10ème 10 minutes, etc) envoyés epuis la même
IP. Ca permet de monitorer, de voir venir et le cas échéant de nettoyer
la file d'attente avant envoi.
Du coup, je reçois très fréquemment des courriers électroniques de
test à cause de gens essayant de détourner l'utilisation du
formulaire. Avec des scripts testant automatiquement le formulaire, je
Oui, cf ci-dessus, c'est un des moyens les plus à la mode pour balancer
du spam...
suppose (ils semblent en plus rajouter un champ Bcc pour avoir un
retour sur la possibilité de détourner le formulaire).
Si ton formulaire est correctement écrit, je ne vois pas bien comment le
script appelant pourrait ajouter un Bcc dans ton formulaire à l'insu de
ton plein gré...
Comme j'en ai un peu assez, je me demandais ce qui faisait, dans ce
formulaire, qu'il était la proie de scripts ?
La popularité de ton site ? :)
Plus sérieusement, étant hébergeur et amené à superviser les sites de
mes clients, qu'ils soient en dédié ou en mutualisé, je constate que
tous les formulaires permettant d'envoyer des mails sont scannés et
testés en permanence à la recherche de failles permettant d'envoyer des
cochonneries (spams, virus, backdoors...) pas leur intermédiaire.
C'est plus pour éviter que ces tentatives se répètent sans cesse : la
faille qu'on tente d'exploiter, elle, n'existe pas.
Les robots scannent tout en permanence à la recherche de failles, tu n'y
peux rien, ni personne. Assure-toi que tes formulaires sont bien
protégés et arrête de lire tes logs :)
dans (in) fr.comp.securite, Vincent Hiribarren ecrivait (wrote) :
Bonjour,
Il se trouve que ce formulaire est sans arrêt la proie de scripts qui tentent de faire déborder les données contenus dans le champ "votre adresse électronique", pour insérer des destinataires autres que ceux qui sont fixés "en dûr".
C'est un grand classique, lié au fait que les gens programment souvent (pour rester courtois) fort mal en PHP et que l'injection de scripts dans des champs de formulaires mal contrôlés, en particulier ceux où on est sensé inscrire son adresse mail, sont pain béni pour les spammers et autres nuisibles.
En effet, si on ne fait pas gaffe, y mettre quelque chose comme :
: pourrait marcher en mettant dans l'entête courrier comme destinataire.
Première règle dans un tel champ, analyser son contenu de façon à s'assurer au minimum que :
- l'adresse inscrite est syntaxiquement correcte ; - que le champ ne peut contenir qu'une adresse mail à la fois ; - que les passages à la ligne sont interdits.
J'utilise souvent ça, mais on doit probablement pouvoir trouver mieux :
...................................................................... function verif_email($email) { // champ vide ? if ($email == "") { $err_email = "Merci d'indiquer votre adresse électronique :"; } else { if (eregi("^[_.0-9a-z-]+@([0-9a-z-]+.)+[a-z]{2,4}$",$email)) { // L'adresse email est valide et unique $err_email = ""; } else { // L'adresse email n'est pas valide, des caractères interdits // tels cr/lf y ont été introduits, etc... $err_email = "adresse invalide, vérifiez la syntaxe..."; } } return $err_email; } ......................................................................
Tu peux affiner en mettant un timer entre le moment ou le formulaire est validé et celui ou il est effectivement expédié, le fin du fin étant d'augmenter le temps de latence au fur et à mesure (du premier au 5ème mail 5 minutes, du 6ème au 10ème 10 minutes, etc) envoyés epuis la même IP. Ca permet de monitorer, de voir venir et le cas échéant de nettoyer la file d'attente avant envoi.
Du coup, je reçois très fréquemment des courriers électroniques de test à cause de gens essayant de détourner l'utilisation du formulaire. Avec des scripts testant automatiquement le formulaire, je
Oui, cf ci-dessus, c'est un des moyens les plus à la mode pour balancer du spam...
suppose (ils semblent en plus rajouter un champ Bcc pour avoir un retour sur la possibilité de détourner le formulaire).
Si ton formulaire est correctement écrit, je ne vois pas bien comment le script appelant pourrait ajouter un Bcc dans ton formulaire à l'insu de ton plein gré...
Comme j'en ai un peu assez, je me demandais ce qui faisait, dans ce formulaire, qu'il était la proie de scripts ?
La popularité de ton site ? :)
Plus sérieusement, étant hébergeur et amené à superviser les sites de mes clients, qu'ils soient en dédié ou en mutualisé, je constate que tous les formulaires permettant d'envoyer des mails sont scannés et testés en permanence à la recherche de failles permettant d'envoyer des cochonneries (spams, virus, backdoors...) pas leur intermédiaire.
C'est plus pour éviter que ces tentatives se répètent sans cesse : la faille qu'on tente d'exploiter, elle, n'existe pas.
Les robots scannent tout en permanence à la recherche de failles, tu n'y peux rien, ni personne. Assure-toi que tes formulaires sont bien protégés et arrête de lire tes logs :)
-- Eric Demeester - http://www.galacsys.net
Vincent Hiribarren
Eric Demeester <eric+ writes:
suppose (ils semblent en plus rajouter un champ Bcc pour avoir un retour sur la possibilité de détourner le formulaire).
Si ton formulaire est correctement écrit, je ne vois pas bien comment le script appelant pourrait ajouter un Bcc dans ton formulaire à l'insu de ton plein gré...
Ah mais justement, il ne peut pas. Je ne sais plus comment j'ai programmé mon bibule (et flemme de jeter un coup d'oeil), mais en gros ça se retrouve de toute manière dans le corps du message, en fait. Ce qui fait que je vois ce que les crétins tente de faire.
Habituellement c'est des salves de trois messages, avec des tentatives différentes.
Comme j'en ai un peu assez, je me demandais ce qui faisait, dans ce formulaire, qu'il était la proie de scripts ?
La popularité de ton site ? :)
(Ben ça, une fois j'avais mis un lien bien voyant sur cette page, je devais bien avoir une question tous les deux jours relativement à Usenet par des gens qui croyaient que je gérais tous ces forums ; amusant au début, mais vite lassant, j'ai enlevé le lien trop voyant).
Plus sérieusement, étant hébergeur et amené à superviser les sites de mes clients, qu'ils soient en dédié ou en mutualisé, je constate que tous les formulaires permettant d'envoyer des mails sont scannés et testés en permanence à la recherche de failles permettant d'envoyer des cochonneries (spams, virus, backdoors...) pas leur intermédiaire.
En fait ce qui m'intéresse surtout de savoir, c'est comment ces formulaires sont "découverts" par les scripts.
Bref, comment faire en sorte que les scripts arrêtent d'y faire des tests. Enlever dans les noms des variables (ou je ne sais plus comment ça s'appelle dans les formulaires HTML) les mots "mail", "from", "body", "author"... pour les remplacer par des mots plus neutres suffira-t-il ?
Ou en fait c'est vraiment des tests aveugles, et parfois des formulaires qui n'ont rien à voir avec les e-mails sont aussi touchés ? J'ai un autre formulaire sur le site, il n'a jamais eu de problèmes, lui, comme des entrées parasites à cause d'un script.
C'est plus pour éviter que ces tentatives se répètent sans cesse : la faille qu'on tente d'exploiter, elle, n'existe pas.
Les robots scannent tout en permanence à la recherche de failles, tu n'y peux rien, ni personne. Assure-toi que tes formulaires sont bien protégés et arrête de lire tes logs :)
Oh ils sont protégés. C'est juste que ça me rajouter du "spam" en plus dans ma boite à lettre, puisque je suis destinataire de chaque message (ce formulaire est fait pour me contacter...)
Quant aux logs, ne t'inquiètes pas, je sais ce qu'il y a dedans : j'ai fait un exposé à des collègues sur les précautions à prendre quand on met un serveur "personnel" sur Internet, en prenant comme source mes logs :-)
Je crois qu'ils ont tous eu peur et ne veulent plus gérer de serveurs eux-mêmes :-)
-- Hum, j'ai du courrier en retard moi.
Eric Demeester <eric+usenet@galacsys.net> writes:
suppose (ils semblent en plus rajouter un champ Bcc pour avoir un
retour sur la possibilité de détourner le formulaire).
Si ton formulaire est correctement écrit, je ne vois pas bien comment le
script appelant pourrait ajouter un Bcc dans ton formulaire à l'insu de
ton plein gré...
Ah mais justement, il ne peut pas. Je ne sais plus comment j'ai
programmé mon bibule (et flemme de jeter un coup d'oeil), mais en gros
ça se retrouve de toute manière dans le corps du message, en fait. Ce
qui fait que je vois ce que les crétins tente de faire.
Habituellement c'est des salves de trois messages, avec des tentatives
différentes.
Comme j'en ai un peu assez, je me demandais ce qui faisait, dans ce
formulaire, qu'il était la proie de scripts ?
La popularité de ton site ? :)
(Ben ça, une fois j'avais mis un lien bien voyant sur cette page, je
devais bien avoir une question tous les deux jours relativement à
Usenet par des gens qui croyaient que je gérais tous ces forums ;
amusant au début, mais vite lassant, j'ai enlevé le lien trop voyant).
Plus sérieusement, étant hébergeur et amené à superviser les sites de
mes clients, qu'ils soient en dédié ou en mutualisé, je constate que
tous les formulaires permettant d'envoyer des mails sont scannés et
testés en permanence à la recherche de failles permettant d'envoyer des
cochonneries (spams, virus, backdoors...) pas leur intermédiaire.
En fait ce qui m'intéresse surtout de savoir, c'est comment ces
formulaires sont "découverts" par les scripts.
Bref, comment faire en sorte que les scripts arrêtent d'y faire des
tests. Enlever dans les noms des variables (ou je ne sais plus comment
ça s'appelle dans les formulaires HTML) les mots "mail", "from",
"body", "author"... pour les remplacer par des mots plus neutres
suffira-t-il ?
Ou en fait c'est vraiment des tests aveugles, et parfois des
formulaires qui n'ont rien à voir avec les e-mails sont aussi
touchés ? J'ai un autre formulaire sur le site, il n'a jamais eu
de problèmes, lui, comme des entrées parasites à cause d'un script.
C'est plus pour éviter que ces tentatives se répètent sans cesse : la
faille qu'on tente d'exploiter, elle, n'existe pas.
Les robots scannent tout en permanence à la recherche de failles, tu n'y
peux rien, ni personne. Assure-toi que tes formulaires sont bien
protégés et arrête de lire tes logs :)
Oh ils sont protégés. C'est juste que ça me rajouter du "spam" en plus
dans ma boite à lettre, puisque je suis destinataire de chaque
message (ce formulaire est fait pour me contacter...)
Quant aux logs, ne t'inquiètes pas, je sais ce qu'il y a dedans : j'ai
fait un exposé à des collègues sur les précautions à prendre quand on
met un serveur "personnel" sur Internet, en prenant comme source mes
logs :-)
Je crois qu'ils ont tous eu peur et ne veulent plus gérer de serveurs
eux-mêmes :-)
suppose (ils semblent en plus rajouter un champ Bcc pour avoir un retour sur la possibilité de détourner le formulaire).
Si ton formulaire est correctement écrit, je ne vois pas bien comment le script appelant pourrait ajouter un Bcc dans ton formulaire à l'insu de ton plein gré...
Ah mais justement, il ne peut pas. Je ne sais plus comment j'ai programmé mon bibule (et flemme de jeter un coup d'oeil), mais en gros ça se retrouve de toute manière dans le corps du message, en fait. Ce qui fait que je vois ce que les crétins tente de faire.
Habituellement c'est des salves de trois messages, avec des tentatives différentes.
Comme j'en ai un peu assez, je me demandais ce qui faisait, dans ce formulaire, qu'il était la proie de scripts ?
La popularité de ton site ? :)
(Ben ça, une fois j'avais mis un lien bien voyant sur cette page, je devais bien avoir une question tous les deux jours relativement à Usenet par des gens qui croyaient que je gérais tous ces forums ; amusant au début, mais vite lassant, j'ai enlevé le lien trop voyant).
Plus sérieusement, étant hébergeur et amené à superviser les sites de mes clients, qu'ils soient en dédié ou en mutualisé, je constate que tous les formulaires permettant d'envoyer des mails sont scannés et testés en permanence à la recherche de failles permettant d'envoyer des cochonneries (spams, virus, backdoors...) pas leur intermédiaire.
En fait ce qui m'intéresse surtout de savoir, c'est comment ces formulaires sont "découverts" par les scripts.
Bref, comment faire en sorte que les scripts arrêtent d'y faire des tests. Enlever dans les noms des variables (ou je ne sais plus comment ça s'appelle dans les formulaires HTML) les mots "mail", "from", "body", "author"... pour les remplacer par des mots plus neutres suffira-t-il ?
Ou en fait c'est vraiment des tests aveugles, et parfois des formulaires qui n'ont rien à voir avec les e-mails sont aussi touchés ? J'ai un autre formulaire sur le site, il n'a jamais eu de problèmes, lui, comme des entrées parasites à cause d'un script.
C'est plus pour éviter que ces tentatives se répètent sans cesse : la faille qu'on tente d'exploiter, elle, n'existe pas.
Les robots scannent tout en permanence à la recherche de failles, tu n'y peux rien, ni personne. Assure-toi que tes formulaires sont bien protégés et arrête de lire tes logs :)
Oh ils sont protégés. C'est juste que ça me rajouter du "spam" en plus dans ma boite à lettre, puisque je suis destinataire de chaque message (ce formulaire est fait pour me contacter...)
Quant aux logs, ne t'inquiètes pas, je sais ce qu'il y a dedans : j'ai fait un exposé à des collègues sur les précautions à prendre quand on met un serveur "personnel" sur Internet, en prenant comme source mes logs :-)
Je crois qu'ils ont tous eu peur et ne veulent plus gérer de serveurs eux-mêmes :-)
-- Hum, j'ai du courrier en retard moi.
Patrick Mevzek
- l'adresse inscrite est syntaxiquement correcte ;
[..]
if (eregi("^[_.0-9a-z-]+@([0-9a-z-]+.)+[a-z]{2,4}$",$email)) { // L'adresse email est valide et unique $err_email = ""; } else { // L'adresse email n'est pas valide, des caractères interdits // tels cr/lf y ont été introduits, etc... $err_email = "adresse invalide, vérifiez la syntaxe..."; }
Malheureusement, c'est l'expression régulière qui est incorrecte. Deux exemples: - on peut avoir un + à gauche du @, c'est tout à fait autorisé. - certains TLDs ont plus de 4 caractères (MUSEUM, TRAVEL, etc...)
Olivier Miakinen a lancé un thread à ce sujet récemment sur fr.comp.mail.serveurs
-- 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>
- l'adresse inscrite est syntaxiquement correcte ;
[..]
if (eregi("^[_.0-9a-z-]+@([0-9a-z-]+.)+[a-z]{2,4}$",$email)) {
// L'adresse email est valide et unique
$err_email = "";
}
else {
// L'adresse email n'est pas valide, des caractères interdits
// tels cr/lf y ont été introduits, etc...
$err_email = "adresse invalide, vérifiez la syntaxe...";
}
Malheureusement, c'est l'expression régulière qui est incorrecte.
Deux exemples:
- on peut avoir un + à gauche du @, c'est tout à fait autorisé.
- certains TLDs ont plus de 4 caractères (MUSEUM, TRAVEL, etc...)
Olivier Miakinen a lancé un thread à ce sujet récemment sur
fr.comp.mail.serveurs
--
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>
- l'adresse inscrite est syntaxiquement correcte ;
[..]
if (eregi("^[_.0-9a-z-]+@([0-9a-z-]+.)+[a-z]{2,4}$",$email)) { // L'adresse email est valide et unique $err_email = ""; } else { // L'adresse email n'est pas valide, des caractères interdits // tels cr/lf y ont été introduits, etc... $err_email = "adresse invalide, vérifiez la syntaxe..."; }
Malheureusement, c'est l'expression régulière qui est incorrecte. Deux exemples: - on peut avoir un + à gauche du @, c'est tout à fait autorisé. - certains TLDs ont plus de 4 caractères (MUSEUM, TRAVEL, etc...)
Olivier Miakinen a lancé un thread à ce sujet récemment sur fr.comp.mail.serveurs
-- 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>
Delf
Vincent Hiribarren wrote:
Le simple fait d'avoir nommé les variables "mailAuthor" et "mailBody" peut-il suffire à attirer les scripts comme des mouches ? Et à repérer que c'est spécifiquement dans "mailAuthor" qu'il faut faire déborder le formulaire ?
Les variables ne sont pas connues côté client.
-- Delf Do not use this email in Cc!
Vincent Hiribarren wrote:
Le simple fait d'avoir nommé les variables "mailAuthor" et "mailBody"
peut-il suffire à attirer les scripts comme des mouches ? Et à repérer
que c'est spécifiquement dans "mailAuthor" qu'il faut faire déborder le
formulaire ?
Le simple fait d'avoir nommé les variables "mailAuthor" et "mailBody" peut-il suffire à attirer les scripts comme des mouches ? Et à repérer que c'est spécifiquement dans "mailAuthor" qu'il faut faire déborder le formulaire ?
Les variables ne sont pas connues côté client.
-- Delf Do not use this email in Cc!
Olivier Croquette
Patrick Mevzek wrote:
if (eregi("^[_.0-9a-z-]+@([0-9a-z-]+.)+[a-z]{2,4}$",$email)) { // L'adresse email est valide et unique $err_email = ""; }
Malheureusement, c'est l'expression régulière qui est incorrecte. Deux exemples: - on peut avoir un + à gauche du @, c'est tout à fait autorisé. - certains TLDs ont plus de 4 caractères (MUSEUM, TRAVEL, etc...)
Un troisième: - le nom d'utilisateur ne peut se terminer par un point: "" est invalide
Construire une expression régulière pour vérifier des adresses email n'est pas une tâche facile.
Olivier Miakinen a lancé un thread à ce sujet récemment sur fr.comp.mail.serveurs
Tu aurais un "message-id" plutôt?
Patrick Mevzek wrote:
if (eregi("^[_.0-9a-z-]+@([0-9a-z-]+.)+[a-z]{2,4}$",$email)) {
// L'adresse email est valide et unique
$err_email = "";
}
Malheureusement, c'est l'expression régulière qui est incorrecte.
Deux exemples:
- on peut avoir un + à gauche du @, c'est tout à fait autorisé.
- certains TLDs ont plus de 4 caractères (MUSEUM, TRAVEL, etc...)
Un troisième:
- le nom d'utilisateur ne peut se terminer par un point:
"test.@test.abc" est invalide
Construire une expression régulière pour vérifier des adresses email
n'est pas une tâche facile.
Olivier Miakinen a lancé un thread à ce sujet récemment sur
fr.comp.mail.serveurs
if (eregi("^[_.0-9a-z-]+@([0-9a-z-]+.)+[a-z]{2,4}$",$email)) { // L'adresse email est valide et unique $err_email = ""; }
Malheureusement, c'est l'expression régulière qui est incorrecte. Deux exemples: - on peut avoir un + à gauche du @, c'est tout à fait autorisé. - certains TLDs ont plus de 4 caractères (MUSEUM, TRAVEL, etc...)
Un troisième: - le nom d'utilisateur ne peut se terminer par un point: "" est invalide
Construire une expression régulière pour vérifier des adresses email n'est pas une tâche facile.
Olivier Miakinen a lancé un thread à ce sujet récemment sur fr.comp.mail.serveurs
Tu aurais un "message-id" plutôt?
Vincent Hiribarren
Delf writes:
Vincent Hiribarren wrote:
Le simple fait d'avoir nommé les variables "mailAuthor" et "mailBody" peut-il suffire à attirer les scripts comme des mouches ? Et à repérer que c'est spécifiquement dans "mailAuthor" qu'il faut faire déborder le formulaire ?
Les variables ne sont pas connues côté client.
La dénomination de "variable" n'était peut-être pas très bonne, mais je pensais que les lignes données du formulaire étaient explicites :
Les couples clef/valeur si vous préférez, mais ça ne change rien qu'au bout du compte, les identifiants qualifiés de "name" permettent de récupérer des valeurs qui varieront selon ce qui est entré par les utilisateurs.
Bref, c'est bien des sortes de variable sur lesquelles les "attaquants" agissent, et qui sont tout à fait connues côtés client. D'où ma dénomination, peut-être un peu hâtive, mais logique.
-- -+- http://www.alea.net/usenet/ -+-
Delf <no-one@nowhere.no> writes:
Vincent Hiribarren wrote:
Le simple fait d'avoir nommé les variables "mailAuthor" et
"mailBody" peut-il suffire à attirer les scripts comme des mouches ?
Et à repérer que c'est spécifiquement dans "mailAuthor" qu'il faut
faire déborder le formulaire ?
Les variables ne sont pas connues côté client.
La dénomination de "variable" n'était peut-être pas très bonne, mais
je pensais que les lignes données du formulaire étaient explicites :
Les couples clef/valeur si vous préférez, mais ça ne change rien qu'au
bout du compte, les identifiants qualifiés de "name" permettent de
récupérer des valeurs qui varieront selon ce qui est entré par les
utilisateurs.
Bref, c'est bien des sortes de variable sur lesquelles les "attaquants"
agissent, et qui sont tout à fait connues côtés client. D'où ma
dénomination, peut-être un peu hâtive, mais logique.
Le simple fait d'avoir nommé les variables "mailAuthor" et "mailBody" peut-il suffire à attirer les scripts comme des mouches ? Et à repérer que c'est spécifiquement dans "mailAuthor" qu'il faut faire déborder le formulaire ?
Les variables ne sont pas connues côté client.
La dénomination de "variable" n'était peut-être pas très bonne, mais je pensais que les lignes données du formulaire étaient explicites :
Les couples clef/valeur si vous préférez, mais ça ne change rien qu'au bout du compte, les identifiants qualifiés de "name" permettent de récupérer des valeurs qui varieront selon ce qui est entré par les utilisateurs.
Bref, c'est bien des sortes de variable sur lesquelles les "attaquants" agissent, et qui sont tout à fait connues côtés client. D'où ma dénomination, peut-être un peu hâtive, mais logique.
-- -+- http://www.alea.net/usenet/ -+-
Fabien LE LEZ
On 13 Mar 2006 21:49:05 GMT, Olivier Croquette :
Construire une expression régulière pour vérifier des adresses email n'est pas une tâche facile.
Disons qu'il faut suivre à la lettre la RFC qui va bien...
On 13 Mar 2006 21:49:05 GMT, Olivier Croquette
<ocroquette@ocroquette.free.fr>:
Construire une expression régulière pour vérifier des adresses email
n'est pas une tâche facile.
Disons qu'il faut suivre à la lettre la RFC qui va bien...
Construire une expression régulière pour vérifier des adresses email n'est pas une tâche facile.
Disons qu'il faut suivre à la lettre la RFC qui va bien...
Thierry Thomas
Lundi 13 mars 2006 à 21:49 GMT, Olivier Croquette a écrit :
Construire une expression régulière pour vérifier des adresses email n'est pas une tâche facile.
Olivier Miakinen a lancé un thread à ce sujet récemment sur fr.comp.mail.serveurs
Faut pas réinventer la poudre... Dans ce cas, on avait du PHP, alors il vaut mieux utiliser la classe Mail_RFC822 qui vient avec Mail de Pear. -- Th. Thomas.
Lundi 13 mars 2006 à 21:49 GMT, Olivier Croquette a écrit :
Construire une expression régulière pour vérifier des adresses email
n'est pas une tâche facile.
Olivier Miakinen a lancé un thread à ce sujet récemment sur
fr.comp.mail.serveurs
Faut pas réinventer la poudre... Dans ce cas, on avait du PHP, alors il
vaut mieux utiliser la classe Mail_RFC822 qui vient avec Mail de Pear.
--
Th. Thomas.
Lundi 13 mars 2006 à 21:49 GMT, Olivier Croquette a écrit :
Construire une expression régulière pour vérifier des adresses email n'est pas une tâche facile.
Olivier Miakinen a lancé un thread à ce sujet récemment sur fr.comp.mail.serveurs
Faut pas réinventer la poudre... Dans ce cas, on avait du PHP, alors il vaut mieux utiliser la classe Mail_RFC822 qui vient avec Mail de Pear. -- Th. Thomas.
Patrick Mevzek
Le simple fait d'avoir nommé les variables "mailAuthor" et "mailBody" peut-il suffire à attirer les scripts comme des mouches ? Et à repérer que c'est spécifiquement dans "mailAuthor" qu'il faut faire déborder le formulaire ?
Les variables ne sont pas connues côté client.
C'est juste le nom des champs du formulaire... (vive[1] PHP register_globals)
[1] c'est ironique
-- 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>
Le simple fait d'avoir nommé les variables "mailAuthor" et "mailBody"
peut-il suffire à attirer les scripts comme des mouches ? Et à repérer
que c'est spécifiquement dans "mailAuthor" qu'il faut faire déborder le
formulaire ?
Les variables ne sont pas connues côté client.
C'est juste le nom des champs du formulaire...
(vive[1] PHP register_globals)
[1] c'est ironique
--
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>
Le simple fait d'avoir nommé les variables "mailAuthor" et "mailBody" peut-il suffire à attirer les scripts comme des mouches ? Et à repérer que c'est spécifiquement dans "mailAuthor" qu'il faut faire déborder le formulaire ?
Les variables ne sont pas connues côté client.
C'est juste le nom des champs du formulaire... (vive[1] PHP register_globals)
[1] c'est ironique
-- 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>
Eric Demeester
dans (in) fr.comp.securite, Olivier Croquette ecrivait (wrote) :
Bonjour,
Patrick Mevzek wrote:
Malheureusement, c'est l'expression régulière qui est incorrecte. Deux exemples: - on peut avoir un + à gauche du @, c'est tout à fait autorisé. - certains TLDs ont plus de 4 caractères (MUSEUM, TRAVEL, etc...)
Un troisième: - le nom d'utilisateur ne peut se terminer par un point: "" est invalide
Arg! J'en déduis néanmoins que plutôt qu'incorrecte, mon expression rationnelle est trop restrictive ? Si tel est le cas c'est un moindre mal, mais bon, c'est embêtant quand même.
Construire une expression régulière pour vérifier des adresses email n'est pas une tâche facile.
Je suis preneur d'une meilleure que la mienne, je suis une bille en la matière et je crains n'avoir fait que recopier bêtement un exemple trouvé sur un site :)
Olivier Miakinen a lancé un thread à ce sujet récemment sur fr.comp.mail.serveurs
Tu aurais un "message-id" plutôt?
Je viens de jeter un coup d'oeil et je ne trouve aucune trace d'un article d'Olivier dans ce groupe...
-- Eric Demeester - http://www.galacsys.net
dans (in) fr.comp.securite, Olivier Croquette
<ocroquette@ocroquette.free.fr> ecrivait (wrote) :
Bonjour,
Patrick Mevzek wrote:
Malheureusement, c'est l'expression régulière qui est incorrecte.
Deux exemples:
- on peut avoir un + à gauche du @, c'est tout à fait autorisé.
- certains TLDs ont plus de 4 caractères (MUSEUM, TRAVEL, etc...)
Un troisième:
- le nom d'utilisateur ne peut se terminer par un point:
"test.@test.abc" est invalide
Arg! J'en déduis néanmoins que plutôt qu'incorrecte, mon expression
rationnelle est trop restrictive ? Si tel est le cas c'est un moindre
mal, mais bon, c'est embêtant quand même.
Construire une expression régulière pour vérifier des adresses email
n'est pas une tâche facile.
Je suis preneur d'une meilleure que la mienne, je suis une bille en la
matière et je crains n'avoir fait que recopier bêtement un exemple
trouvé sur un site :)
Olivier Miakinen a lancé un thread à ce sujet récemment sur
fr.comp.mail.serveurs
Tu aurais un "message-id" plutôt?
Je viens de jeter un coup d'oeil et je ne trouve aucune trace d'un
article d'Olivier dans ce groupe...
dans (in) fr.comp.securite, Olivier Croquette ecrivait (wrote) :
Bonjour,
Patrick Mevzek wrote:
Malheureusement, c'est l'expression régulière qui est incorrecte. Deux exemples: - on peut avoir un + à gauche du @, c'est tout à fait autorisé. - certains TLDs ont plus de 4 caractères (MUSEUM, TRAVEL, etc...)
Un troisième: - le nom d'utilisateur ne peut se terminer par un point: "" est invalide
Arg! J'en déduis néanmoins que plutôt qu'incorrecte, mon expression rationnelle est trop restrictive ? Si tel est le cas c'est un moindre mal, mais bon, c'est embêtant quand même.
Construire une expression régulière pour vérifier des adresses email n'est pas une tâche facile.
Je suis preneur d'une meilleure que la mienne, je suis une bille en la matière et je crains n'avoir fait que recopier bêtement un exemple trouvé sur un site :)
Olivier Miakinen a lancé un thread à ce sujet récemment sur fr.comp.mail.serveurs
Tu aurais un "message-id" plutôt?
Je viens de jeter un coup d'oeil et je ne trouve aucune trace d'un article d'Olivier dans ce groupe...
