Bonjour
J'ai un souci de spamm qui se répète sur plusieurs de mes sites.
Je viens de lancer le nom de domaine synthese-prod.com à 15h.
A 15h10, je reçois déjà du spamm (qui ressemble à celui reçu que un
autre de mes sites). Je m'inquiete donc, pour plusieurs raisons:
Ci dessous le détail du mail reçu.
- à la validation du formulaire, je teste en javascript que des champs
sont bien enregistrés. je les récupères en post et les affiche dans le
mail. Ici tous les champs sont bien remplis, mais la dernière fois le
"robots" a réussi a valider le form sans les éléments essentiels...
- j'utilise les classes phpmailer couplé à une classe smtp. vous pensez
que cela puisse venir de là?
- je ne crois pas aux coincidences ! Et vous?
Merci de votre réponse.
***************************************************************************
Nom : jmhfhf@synthese-prod.com
Prénom: jmhfhf@synthese-prod.com
Courriel : jmhfhf@synthese-prod.com
Téléphone : jmhfhf@synthese-prod.com Content-Type: multipart/mixed;
boundary="===============0727823555==" MIME-Version: 1.0 Subject:
b7fd7fed To: jmhfhf@synthese-prod.com bcc: PeiCanteenMc@aol.com From:
jmhfhf@synthese-prod.com This is a multi-part message in MIME format.
--===============0727823555== Content-Type: text/plain;
charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit
vksxqhrw --===============0727823555==--
Société : jmhfhf@synthese-prod.com
Précision : jmhfhf@synthese-prod.com
******************************************************************************
Message: jmhfhf@synthese-prod.com
Bonjour J'ai un souci de spamm qui se répète sur plusieurs de mes sites.
C'est assez courant en ce moment. Cf. par exemple : http://www.mcgwebdevelopment.com/blog/2005/09/php-mail-form-email-injection-hijack/
- à la validation du formulaire, je teste en javascript que des champs sont bien enregistrés. je les récupères en post et les affiche dans le mail. Ici tous les champs sont bien remplis, mais la dernière fois le "robots" a réussi a valider le form sans les éléments essentiels...
Les robots ne voient pas le javascript, ils peuvent donc passer outre ta protection et attaquer directement la page suivante du form.
-- Jérôme
J.Trotoux wrote:
Bonjour
J'ai un souci de spamm qui se répète sur plusieurs de mes sites.
C'est assez courant en ce moment.
Cf. par exemple :
http://www.mcgwebdevelopment.com/blog/2005/09/php-mail-form-email-injection-hijack/
- à la validation du formulaire, je teste en javascript que des champs
sont bien enregistrés. je les récupères en post et les affiche dans le
mail. Ici tous les champs sont bien remplis, mais la dernière fois le
"robots" a réussi a valider le form sans les éléments essentiels...
Les robots ne voient pas le javascript, ils peuvent donc passer outre ta
protection et attaquer directement la page suivante du form.
Bonjour J'ai un souci de spamm qui se répète sur plusieurs de mes sites.
C'est assez courant en ce moment. Cf. par exemple : http://www.mcgwebdevelopment.com/blog/2005/09/php-mail-form-email-injection-hijack/
- à la validation du formulaire, je teste en javascript que des champs sont bien enregistrés. je les récupères en post et les affiche dans le mail. Ici tous les champs sont bien remplis, mais la dernière fois le "robots" a réussi a valider le form sans les éléments essentiels...
Les robots ne voient pas le javascript, ils peuvent donc passer outre ta protection et attaquer directement la page suivante du form.
-- Jérôme
Denis Beauregard
Le Tue, 20 Sep 2005 16:03:39 +0200, Jerome écrivait dans fr.comp.infosystemes.www.auteurs:
J.Trotoux wrote:
Bonjour J'ai un souci de spamm qui se répète sur plusieurs de mes sites.
C'est assez courant en ce moment. Cf. par exemple : http://www.mcgwebdevelopment.com/blog/2005/09/php-mail-form-email-injection-hijack/
- à la validation du formulaire, je teste en javascript que des champs sont bien enregistrés. je les récupères en post et les affiche dans le mail. Ici tous les champs sont bien remplis, mais la dernière fois le "robots" a réussi a valider le form sans les éléments essentiels...
Les robots ne voient pas le javascript, ils peuvent donc passer outre ta protection et attaquer directement la page suivante du form.
Il faudrait que le bouton "envoi" n'apparaisse que si le javascript est activé.
Denis
Le Tue, 20 Sep 2005 16:03:39 +0200, Jerome <jerome347@chez.com>
écrivait dans fr.comp.infosystemes.www.auteurs:
J.Trotoux wrote:
Bonjour
J'ai un souci de spamm qui se répète sur plusieurs de mes sites.
C'est assez courant en ce moment.
Cf. par exemple :
http://www.mcgwebdevelopment.com/blog/2005/09/php-mail-form-email-injection-hijack/
- à la validation du formulaire, je teste en javascript que des champs
sont bien enregistrés. je les récupères en post et les affiche dans le
mail. Ici tous les champs sont bien remplis, mais la dernière fois le
"robots" a réussi a valider le form sans les éléments essentiels...
Les robots ne voient pas le javascript, ils peuvent donc passer outre ta
protection et attaquer directement la page suivante du form.
Il faudrait que le bouton "envoi" n'apparaisse que si le javascript
est activé.
Le Tue, 20 Sep 2005 16:03:39 +0200, Jerome écrivait dans fr.comp.infosystemes.www.auteurs:
J.Trotoux wrote:
Bonjour J'ai un souci de spamm qui se répète sur plusieurs de mes sites.
C'est assez courant en ce moment. Cf. par exemple : http://www.mcgwebdevelopment.com/blog/2005/09/php-mail-form-email-injection-hijack/
- à la validation du formulaire, je teste en javascript que des champs sont bien enregistrés. je les récupères en post et les affiche dans le mail. Ici tous les champs sont bien remplis, mais la dernière fois le "robots" a réussi a valider le form sans les éléments essentiels...
Les robots ne voient pas le javascript, ils peuvent donc passer outre ta protection et attaquer directement la page suivante du form.
Il faudrait que le bouton "envoi" n'apparaisse que si le javascript est activé.
Denis
O.L.
Denis Beauregard vient de nous annoncer :
Le Tue, 20 Sep 2005 16:03:39 +0200, Jerome écrivait dans fr.comp.infosystemes.www.auteurs:
J.Trotoux wrote:
Bonjour J'ai un souci de spamm qui se répète sur plusieurs de mes sites.
C'est assez courant en ce moment. Cf. par exemple : http://www.mcgwebdevelopment.com/blog/2005/09/php-mail-form-email-injection-hijack/
- à la validation du formulaire, je teste en javascript que des champs sont bien enregistrés. je les récupères en post et les affiche dans le mail. Ici tous les champs sont bien remplis, mais la dernière fois le "robots" a réussi a valider le form sans les éléments essentiels...
Les robots ne voient pas le javascript, ils peuvent donc passer outre ta protection et attaquer directement la page suivante du form.
Il faudrait que le bouton "envoi" n'apparaisse que si le javascript est activé.
Denis
Ou bien tu met un champ hidden qui sera "activé" par JavaScript et sans lequel ton script PHP devra refuser de faire quoi que ce soit. Ou bien au lieu d'utiliser une balise FORM, tu utilises JS pour changer de page et appeler ton script avec comme paramètres les valeurs de tes champs. Ou bien tu met par défaut une fausse adresse cible pour ton FORM, et tu la corrige avec un script JS : le robot ne lira pas le JS, et ira se planter sur une erreur 404.
...
Mais attention, un utilisateur qui n'aurait pas activé JS ... boum ! :-/
@+ Olivier
Denis Beauregard vient de nous annoncer :
Le Tue, 20 Sep 2005 16:03:39 +0200, Jerome <jerome347@chez.com>
écrivait dans fr.comp.infosystemes.www.auteurs:
J.Trotoux wrote:
Bonjour
J'ai un souci de spamm qui se répète sur plusieurs de mes sites.
C'est assez courant en ce moment.
Cf. par exemple :
http://www.mcgwebdevelopment.com/blog/2005/09/php-mail-form-email-injection-hijack/
- à la validation du formulaire, je teste en javascript que des champs
sont bien enregistrés. je les récupères en post et les affiche dans le
mail. Ici tous les champs sont bien remplis, mais la dernière fois le
"robots" a réussi a valider le form sans les éléments essentiels...
Les robots ne voient pas le javascript, ils peuvent donc passer outre ta
protection et attaquer directement la page suivante du form.
Il faudrait que le bouton "envoi" n'apparaisse que si le javascript
est activé.
Denis
Ou bien tu met un champ hidden qui sera "activé" par JavaScript et sans
lequel ton script PHP devra refuser de faire quoi que ce soit.
Ou bien au lieu d'utiliser une balise FORM, tu utilises JS pour changer
de page et appeler ton script avec comme paramètres les valeurs de tes
champs.
Ou bien tu met par défaut une fausse adresse cible pour ton FORM, et tu
la corrige avec un script JS : le robot ne lira pas le JS, et ira se
planter sur une erreur 404.
...
Mais attention, un utilisateur qui n'aurait pas activé JS ... boum !
:-/
Le Tue, 20 Sep 2005 16:03:39 +0200, Jerome écrivait dans fr.comp.infosystemes.www.auteurs:
J.Trotoux wrote:
Bonjour J'ai un souci de spamm qui se répète sur plusieurs de mes sites.
C'est assez courant en ce moment. Cf. par exemple : http://www.mcgwebdevelopment.com/blog/2005/09/php-mail-form-email-injection-hijack/
- à la validation du formulaire, je teste en javascript que des champs sont bien enregistrés. je les récupères en post et les affiche dans le mail. Ici tous les champs sont bien remplis, mais la dernière fois le "robots" a réussi a valider le form sans les éléments essentiels...
Les robots ne voient pas le javascript, ils peuvent donc passer outre ta protection et attaquer directement la page suivante du form.
Il faudrait que le bouton "envoi" n'apparaisse que si le javascript est activé.
Denis
Ou bien tu met un champ hidden qui sera "activé" par JavaScript et sans lequel ton script PHP devra refuser de faire quoi que ce soit. Ou bien au lieu d'utiliser une balise FORM, tu utilises JS pour changer de page et appeler ton script avec comme paramètres les valeurs de tes champs. Ou bien tu met par défaut une fausse adresse cible pour ton FORM, et tu la corrige avec un script JS : le robot ne lira pas le JS, et ira se planter sur une erreur 404.
...
Mais attention, un utilisateur qui n'aurait pas activé JS ... boum ! :-/
@+ Olivier
Jerome
Denis Beauregard wrote:
Il faudrait que le bouton "envoi" n'apparaisse que si le javascript est activé.
Et l'action du form aussi, sinon ça ne sert pas à grand chose :-)
Pour ma part j'ai "reglé" le problème en vérifiant (en php) que from != mail != telephone != ... Parce que les robots ne sont pas super imaginatifs :)
-- Jérôme
Denis Beauregard wrote:
Il faudrait que le bouton "envoi" n'apparaisse que si le javascript
est activé.
Et l'action du form aussi, sinon ça ne sert pas à grand chose :-)
Pour ma part j'ai "reglé" le problème en vérifiant (en php) que
from != mail != telephone != ...
Parce que les robots ne sont pas super imaginatifs :)
Il faudrait que le bouton "envoi" n'apparaisse que si le javascript est activé.
Et l'action du form aussi, sinon ça ne sert pas à grand chose :-)
Pour ma part j'ai "reglé" le problème en vérifiant (en php) que from != mail != telephone != ... Parce que les robots ne sont pas super imaginatifs :)
Bof, ils doivent bien pouvoir mettre des trucs aléatoires dans tes champs, non ?
Peter Pan
J.Trotoux a écrit :
Bonjour J'ai un souci de spamm qui se répète sur plusieurs de mes sites.
Même soucis depuis quelques semaines, sur plusieurs sites (chez OVH). Las, j'ai mis en place : http://dev.ppan.net/formulaire-anti-spam.php Plus aucun spam depuis.
PS : version avec librairie GD en préparation
-- Pierre http://www.1966.fr/
J.Trotoux a écrit :
Bonjour
J'ai un souci de spamm qui se répète sur plusieurs de mes sites.
Même soucis depuis quelques semaines, sur plusieurs sites (chez OVH).
Las, j'ai mis en place : http://dev.ppan.net/formulaire-anti-spam.php
Plus aucun spam depuis.
Bonjour J'ai un souci de spamm qui se répète sur plusieurs de mes sites.
Même soucis depuis quelques semaines, sur plusieurs sites (chez OVH). Las, j'ai mis en place : http://dev.ppan.net/formulaire-anti-spam.php Plus aucun spam depuis.
PS : version avec librairie GD en préparation
-- Pierre http://www.1966.fr/
Jerome
O.L. wrote:
Pour ma part j'ai "reglé" le problème en vérifiant (en php) que from != mail != telephone != ... Parce que les robots ne sont pas super imaginatifs :)
Bof, ils doivent bien pouvoir mettre des trucs aléatoires dans tes champs, non ?
Aléatoires oui mais toujours les mêmes entre le from, le téléphone et les autres champs, comme dans le mail cité dans le post d'origine :
Nom : Prénom: Courriel : ...
Donc en testant si (nom = prenom) ou si (nom = courriel) => on jette, ça suffit pour tout bloquer, sans bloquer ceux qui n'ont pas javascript.
-- Jérôme
O.L. wrote:
Pour ma part j'ai "reglé" le problème en vérifiant (en php) que
from != mail != telephone != ...
Parce que les robots ne sont pas super imaginatifs :)
Bof, ils doivent bien pouvoir mettre des trucs aléatoires dans tes
champs, non ?
Aléatoires oui mais toujours les mêmes entre le from, le téléphone et
les autres champs, comme dans le mail cité dans le post d'origine :
Nom : jmhfhf@synthese-prod.com
Prénom: jmhfhf@synthese-prod.com
Courriel : jmhfhf@synthese-prod.com
...
Donc en testant si (nom = prenom) ou si (nom = courriel) => on jette, ça
suffit pour tout bloquer, sans bloquer ceux qui n'ont pas javascript.
Pour ma part j'ai "reglé" le problème en vérifiant (en php) que from != mail != telephone != ... Parce que les robots ne sont pas super imaginatifs :)
Bof, ils doivent bien pouvoir mettre des trucs aléatoires dans tes champs, non ?
Aléatoires oui mais toujours les mêmes entre le from, le téléphone et les autres champs, comme dans le mail cité dans le post d'origine :
Nom : Prénom: Courriel : ...
Donc en testant si (nom = prenom) ou si (nom = courriel) => on jette, ça suffit pour tout bloquer, sans bloquer ceux qui n'ont pas javascript.
-- Jérôme
Peter Pan
Jerome a écrit :
Donc en testant si (nom = prenom) ou si (nom = courriel) => on jette, ça suffit pour tout bloquer, sans bloquer ceux qui n'ont pas javascript.
Sauf qu'on peut considérer ce nouveau pourrissage de formulaires comme la genèse d'autres. Mieux vaut, malheureusement, prendre les devants et protéger ses formulaires de façon plus étendue. Un test d'humanoïde s'avère, à mon sens, plus pérenne qu'un test de BAL. Quant au javascript, il est bien inutile dès lors que PHP est disponible.
-- Pierre http://www.1966.fr/
Jerome a écrit :
Donc en testant si (nom = prenom) ou si (nom = courriel) => on jette, ça
suffit pour tout bloquer, sans bloquer ceux qui n'ont pas javascript.
Sauf qu'on peut considérer ce nouveau pourrissage de formulaires comme
la genèse d'autres. Mieux vaut, malheureusement, prendre les devants et
protéger ses formulaires de façon plus étendue. Un test d'humanoïde
s'avère, à mon sens, plus pérenne qu'un test de BAL. Quant au
javascript, il est bien inutile dès lors que PHP est disponible.
Donc en testant si (nom = prenom) ou si (nom = courriel) => on jette, ça suffit pour tout bloquer, sans bloquer ceux qui n'ont pas javascript.
Sauf qu'on peut considérer ce nouveau pourrissage de formulaires comme la genèse d'autres. Mieux vaut, malheureusement, prendre les devants et protéger ses formulaires de façon plus étendue. Un test d'humanoïde s'avère, à mon sens, plus pérenne qu'un test de BAL. Quant au javascript, il est bien inutile dès lors que PHP est disponible.
-- Pierre http://www.1966.fr/
Jerome
Peter Pan wrote:
Jerome a écrit :
Donc en testant si (nom = prenom) ou si (nom = courriel) => on jette, ça suffit pour tout bloquer, sans bloquer ceux qui n'ont pas javascript.
Sauf qu'on peut considérer ce nouveau pourrissage de formulaires comme la genèse d'autres. Mieux vaut, malheureusement, prendre les devants et protéger ses formulaires de façon plus étendue. Un test d'humanoïde s'avère, à mon sens, plus pérenne qu'un test de BAL.
Je pars du principe que ce n'est pas à mes clients de subir les désagréments des spammeurs en tapant un code de sécurité affiché dans une image mais à moi de m'adapter pour que mon formulaire soit le plus simple possible sans pourrir ma BAL.
Mais je suis d'accord sur le fait que c'est effectivement le plus simple et le plus utile sur du long terme, et que ma solution n'est viable que pour un formulaire de contact et non pas un formulaire d'inscription ou d'authentification.
javascript, il est bien inutile dès lors que PHP est disponible.
Là on est bien d'accord.
-- Jérôme
Peter Pan wrote:
Jerome a écrit :
Donc en testant si (nom = prenom) ou si (nom = courriel) => on jette,
ça suffit pour tout bloquer, sans bloquer ceux qui n'ont pas javascript.
Sauf qu'on peut considérer ce nouveau pourrissage de formulaires comme
la genèse d'autres. Mieux vaut, malheureusement, prendre les devants et
protéger ses formulaires de façon plus étendue. Un test d'humanoïde
s'avère, à mon sens, plus pérenne qu'un test de BAL.
Je pars du principe que ce n'est pas à mes clients de subir les
désagréments des spammeurs en tapant un code de sécurité affiché dans
une image mais à moi de m'adapter pour que mon formulaire soit le plus
simple possible sans pourrir ma BAL.
Mais je suis d'accord sur le fait que c'est effectivement le plus simple
et le plus utile sur du long terme, et que ma solution n'est viable que
pour un formulaire de contact et non pas un formulaire d'inscription ou
d'authentification.
javascript, il est bien inutile dès lors que PHP est disponible.
Donc en testant si (nom = prenom) ou si (nom = courriel) => on jette, ça suffit pour tout bloquer, sans bloquer ceux qui n'ont pas javascript.
Sauf qu'on peut considérer ce nouveau pourrissage de formulaires comme la genèse d'autres. Mieux vaut, malheureusement, prendre les devants et protéger ses formulaires de façon plus étendue. Un test d'humanoïde s'avère, à mon sens, plus pérenne qu'un test de BAL.
Je pars du principe que ce n'est pas à mes clients de subir les désagréments des spammeurs en tapant un code de sécurité affiché dans une image mais à moi de m'adapter pour que mon formulaire soit le plus simple possible sans pourrir ma BAL.
Mais je suis d'accord sur le fait que c'est effectivement le plus simple et le plus utile sur du long terme, et que ma solution n'est viable que pour un formulaire de contact et non pas un formulaire d'inscription ou d'authentification.
javascript, il est bien inutile dès lors que PHP est disponible.
Là on est bien d'accord.
-- Jérôme
lolo
Même soucis depuis quelques semaines, sur plusieurs sites (chez OVH). Las, j'ai mis en place : http://dev.ppan.net/formulaire-anti-spam.php Plus aucun spam depuis.
Perso je ne suis pas pour (en fait même contre) le fait de devoir saisir un numéro pour valider un mail. En effet, beaucoup de gens de le feront pas pour diverses raisons (pénible, temps, plusieurs essais car on lit mal certains caractères). Le résultat est que l'on risque de perdre des clients(s'il s'agit d'un site commercial) ou autre. J'en ai même vu qui mettait ces images lors de l'inscription pour acheter et là c'est une cata : je ne sais pas le nombre de commandes non validées juste pour ça.
Même soucis depuis quelques semaines, sur plusieurs sites (chez OVH).
Las, j'ai mis en place : http://dev.ppan.net/formulaire-anti-spam.php
Plus aucun spam depuis.
Perso je ne suis pas pour (en fait même contre) le fait de devoir saisir un
numéro pour valider un mail. En effet, beaucoup de gens de le feront pas
pour diverses raisons (pénible, temps, plusieurs essais car on lit mal
certains caractères). Le résultat est que l'on risque de perdre des
clients(s'il s'agit d'un site commercial) ou autre. J'en ai même vu qui
mettait ces images lors de l'inscription pour acheter et là c'est une cata :
je ne sais pas le nombre de commandes non validées juste pour ça.
Même soucis depuis quelques semaines, sur plusieurs sites (chez OVH). Las, j'ai mis en place : http://dev.ppan.net/formulaire-anti-spam.php Plus aucun spam depuis.
Perso je ne suis pas pour (en fait même contre) le fait de devoir saisir un numéro pour valider un mail. En effet, beaucoup de gens de le feront pas pour diverses raisons (pénible, temps, plusieurs essais car on lit mal certains caractères). Le résultat est que l'on risque de perdre des clients(s'il s'agit d'un site commercial) ou autre. J'en ai même vu qui mettait ces images lors de l'inscription pour acheter et là c'est une cata : je ne sais pas le nombre de commandes non validées juste pour ça.
