existe-t-il un moyen pour éviter à un script de valider un formulaire
sur un site internet ? Je m'explique :
imaginez que j'ai un formulaire dont le résultat envoie un email
si quelqu'un utilise un script qui valide le formulaire en boucle infini
le serveur risque d'être mal...
En fait je souhaiterai garantir que le formulaire soit validé par un clic
"humain".
En fait je souhaiterai garantir que le formulaire soit validé par un clic "humain".
Merci d'avance
Philippe
Le truc utilise le plus souvent maintenant, c'est la recopie d'un texte affiche dans une image gif aleatoire. Si c'est valide, le formulaire est poste, sinon le formulaire est invalide.
-- HORUS
"Ce n'est pas a 10 ans de la retraite que je vais commencer a travailler "
Philippe <pschelte@NOSPAMopus67.fr> wrote in
news:41541723$0$7424$626a14ce@news.free.fr:
En fait je souhaiterai garantir que le formulaire soit validé par un clic
"humain".
Merci d'avance
Philippe
Le truc utilise le plus souvent maintenant, c'est la recopie d'un texte
affiche dans une image gif aleatoire.
Si c'est valide, le formulaire est poste, sinon le formulaire est invalide.
--
HORUS
"Ce n'est pas a 10 ans de la retraite que je vais commencer a travailler "
En fait je souhaiterai garantir que le formulaire soit validé par un clic "humain".
Merci d'avance
Philippe
Le truc utilise le plus souvent maintenant, c'est la recopie d'un texte affiche dans une image gif aleatoire. Si c'est valide, le formulaire est poste, sinon le formulaire est invalide.
-- HORUS
"Ce n'est pas a 10 ans de la retraite que je vais commencer a travailler "
Ganf
Le Fri, 24 Sep 2004 21:02:07 +0000, Philippe a écrit :
En fait je souhaiterai garantir que le formulaire soit validé par un clic "humain".
Actuellement la mode c'est envoyer une image avec un texte biscornu aléatoire (mal écrit, en biais, avec un fond assez dégueulasse pour pas qu'on puisse faire de l'OCR dessus) et demander à l'humain de recopier le contenu dans un champ. Pour ça un coup de GD peut facilement t'aider à commencer.
Le problème c'est que quelle que soit la méthode utilisée (y compris l'image), vouloir empêcher les robots veut dire exclure certaines personnes qui ne naviguent pas exactement comme toi (sans javascript, sans cookie, avec un petit écran, sans couleur, sur pda, avec un lecteur d'écran parce que aveugle ...). À toi de savoir si éthiquement tu te sens d'exclure des gens simplement parce qu'ils n'ont pas la chance de pouvoir naviguer comme le font 95% des autres.
La seule méthode qui va pouvoir te permettre de faire un tri correct c'est limiter le nombre de soumission. S'il y en a trop, ou trop rapides, ou trop fréquentes, ou à des horaires réguliers ... alors c'est probablement un robot et il faut bloquer.
-- Eric Daspet "PHP 5 avancé" aux éditions Eyrolles http://www.eyrolles.com/Informatique/Livre/9782212113235/livre-php-5
Le Fri, 24 Sep 2004 21:02:07 +0000, Philippe a écrit :
En fait je souhaiterai garantir que le formulaire soit validé par un
clic "humain".
Actuellement la mode c'est envoyer une image avec un texte biscornu
aléatoire (mal écrit, en biais, avec un fond assez dégueulasse pour pas
qu'on puisse faire de l'OCR dessus) et demander à l'humain de recopier le
contenu dans un champ. Pour ça un coup de GD peut facilement t'aider à
commencer.
Le problème c'est que quelle que soit la méthode utilisée (y compris
l'image), vouloir empêcher les robots veut dire exclure certaines
personnes qui ne naviguent pas exactement comme toi (sans javascript,
sans cookie, avec un petit écran, sans couleur, sur pda, avec un lecteur
d'écran parce que aveugle ...). À toi de savoir si éthiquement tu te
sens d'exclure des gens simplement parce qu'ils n'ont pas la chance
de pouvoir naviguer comme le font 95% des autres.
La seule méthode qui va pouvoir te permettre de faire un tri correct
c'est limiter le nombre de soumission. S'il y en a trop, ou trop rapides,
ou trop fréquentes, ou à des horaires réguliers ... alors c'est
probablement un robot et il faut bloquer.
--
Eric Daspet
"PHP 5 avancé" aux éditions Eyrolles
http://www.eyrolles.com/Informatique/Livre/9782212113235/livre-php-5
Le Fri, 24 Sep 2004 21:02:07 +0000, Philippe a écrit :
En fait je souhaiterai garantir que le formulaire soit validé par un clic "humain".
Actuellement la mode c'est envoyer une image avec un texte biscornu aléatoire (mal écrit, en biais, avec un fond assez dégueulasse pour pas qu'on puisse faire de l'OCR dessus) et demander à l'humain de recopier le contenu dans un champ. Pour ça un coup de GD peut facilement t'aider à commencer.
Le problème c'est que quelle que soit la méthode utilisée (y compris l'image), vouloir empêcher les robots veut dire exclure certaines personnes qui ne naviguent pas exactement comme toi (sans javascript, sans cookie, avec un petit écran, sans couleur, sur pda, avec un lecteur d'écran parce que aveugle ...). À toi de savoir si éthiquement tu te sens d'exclure des gens simplement parce qu'ils n'ont pas la chance de pouvoir naviguer comme le font 95% des autres.
La seule méthode qui va pouvoir te permettre de faire un tri correct c'est limiter le nombre de soumission. S'il y en a trop, ou trop rapides, ou trop fréquentes, ou à des horaires réguliers ... alors c'est probablement un robot et il faut bloquer.
-- Eric Daspet "PHP 5 avancé" aux éditions Eyrolles http://www.eyrolles.com/Informatique/Livre/9782212113235/livre-php-5
nano
Ganf wrote:
Le problème c'est que quelle que soit la méthode utilisée (y compris l'image), vouloir empêcher les robots veut dire exclure certaines personnes qui ne naviguent pas exactement comme toi (sans javascript, sans cookie, avec un petit écran, sans couleur, sur pda, avec un lecteur d'écran parce que aveugle ...). À toi de savoir si éthiquement tu te sens d'exclure des gens simplement parce qu'ils n'ont pas la chance de pouvoir naviguer comme le font 95% des autres.
Ganf,
Oui, la prudence s'impose.
On peut néanmoins faire quelque chose qui tienne compte du plus grand nombre de situations possibles, tout en gardant à l'esprit que, quelle que soit la technologie, elle est potentiellement inadaptée à une utilisation particulière.
Par exemple, on peut déjà résoudre beaucoup de problèmes en gérant tout ça côté serveur et en respectant les quelques recommandations du W3C à propos de l'accessibilité.
Personnellement, devant l'afflux croissant des spams, j'ai mis en place sur mon site un système de ce type, couplé à d'autres filtres, qui devrait être utilisable pour une très grande majorité, y compris par ceux qui ne peuvent pas voir l'image.
Encore une fois, ça ne prétend pas à l'universelle panacée, et je suis preneur de tout avis.
Le problème c'est que quelle que soit la méthode utilisée (y compris
l'image), vouloir empêcher les robots veut dire exclure certaines
personnes qui ne naviguent pas exactement comme toi (sans javascript,
sans cookie, avec un petit écran, sans couleur, sur pda, avec un lecteur
d'écran parce que aveugle ...). À toi de savoir si éthiquement tu te
sens d'exclure des gens simplement parce qu'ils n'ont pas la chance
de pouvoir naviguer comme le font 95% des autres.
Ganf,
Oui, la prudence s'impose.
On peut néanmoins faire quelque chose qui tienne compte du plus grand
nombre de situations possibles, tout en gardant à l'esprit que, quelle
que soit la technologie, elle est potentiellement inadaptée à une
utilisation particulière.
Par exemple, on peut déjà résoudre beaucoup de problèmes en gérant tout
ça côté serveur et en respectant les quelques recommandations du W3C à
propos de l'accessibilité.
Personnellement, devant l'afflux croissant des spams, j'ai mis en place
sur mon site un système de ce type, couplé à d'autres filtres, qui
devrait être utilisable pour une très grande majorité, y compris par
ceux qui ne peuvent pas voir l'image.
Encore une fois, ça ne prétend pas à l'universelle panacée, et je suis
preneur de tout avis.
Le problème c'est que quelle que soit la méthode utilisée (y compris l'image), vouloir empêcher les robots veut dire exclure certaines personnes qui ne naviguent pas exactement comme toi (sans javascript, sans cookie, avec un petit écran, sans couleur, sur pda, avec un lecteur d'écran parce que aveugle ...). À toi de savoir si éthiquement tu te sens d'exclure des gens simplement parce qu'ils n'ont pas la chance de pouvoir naviguer comme le font 95% des autres.
Ganf,
Oui, la prudence s'impose.
On peut néanmoins faire quelque chose qui tienne compte du plus grand nombre de situations possibles, tout en gardant à l'esprit que, quelle que soit la technologie, elle est potentiellement inadaptée à une utilisation particulière.
Par exemple, on peut déjà résoudre beaucoup de problèmes en gérant tout ça côté serveur et en respectant les quelques recommandations du W3C à propos de l'accessibilité.
Personnellement, devant l'afflux croissant des spams, j'ai mis en place sur mon site un système de ce type, couplé à d'autres filtres, qui devrait être utilisable pour une très grande majorité, y compris par ceux qui ne peuvent pas voir l'image.
Encore une fois, ça ne prétend pas à l'universelle panacée, et je suis preneur de tout avis.
La première chose à faire, c'est de savoir si l'appel du formulaire vient du site ou ailleurs. le referrer est déjà un moyen simple à faire. C'est suffisant pour les robots ou internautes quelconques Mais ce n'est pas fiable à 100%., pour des pirates.
Ceci dit, il existe des solutions un peu plus complexe, trop long à expliquer ici.
"Philippe" a écrit dans le message news: 41541723$0$7424$
Bonjour,
existe-t-il un moyen pour éviter à un script de valider un formulaire sur un site internet ? Je m'explique : imaginez que j'ai un formulaire dont le résultat envoie un email si quelqu'un utilise un script qui valide le formulaire en boucle infini le serveur risque d'être mal... En fait je souhaiterai garantir que le formulaire soit validé par un clic "humain".
Merci d'avance
Philippe
La première chose à faire, c'est de savoir si l'appel du formulaire vient du
site ou ailleurs.
le referrer est déjà un moyen simple à faire.
C'est suffisant pour les robots ou internautes quelconques
Mais ce n'est pas fiable à 100%., pour des pirates.
Ceci dit, il existe des solutions un peu plus complexe,
trop long à expliquer ici.
"Philippe" <pschelte@NOSPAMopus67.fr> a écrit dans le message news:
41541723$0$7424$626a14ce@news.free.fr...
Bonjour,
existe-t-il un moyen pour éviter à un script de valider un formulaire
sur un site internet ? Je m'explique :
imaginez que j'ai un formulaire dont le résultat envoie un email
si quelqu'un utilise un script qui valide le formulaire en boucle infini
le serveur risque d'être mal...
En fait je souhaiterai garantir que le formulaire soit validé par un clic
"humain".
La première chose à faire, c'est de savoir si l'appel du formulaire vient du site ou ailleurs. le referrer est déjà un moyen simple à faire. C'est suffisant pour les robots ou internautes quelconques Mais ce n'est pas fiable à 100%., pour des pirates.
Ceci dit, il existe des solutions un peu plus complexe, trop long à expliquer ici.
"Philippe" a écrit dans le message news: 41541723$0$7424$
Bonjour,
existe-t-il un moyen pour éviter à un script de valider un formulaire sur un site internet ? Je m'explique : imaginez que j'ai un formulaire dont le résultat envoie un email si quelqu'un utilise un script qui valide le formulaire en boucle infini le serveur risque d'être mal... En fait je souhaiterai garantir que le formulaire soit validé par un clic "humain".
Merci d'avance
Philippe
Ludovic LE MOAL
Ganf nous a schtroumfé :
La seule méthode qui va pouvoir te permettre de faire un tri correct c'est limiter le nombre de soumission. S'il y en a trop, ou trop rapides, ou trop fréquentes, ou à des horaires réguliers ... alors c'est probablement un robot et il faut bloquer.
Je suis confronté au même problème que Philippe : j'ai un site où des personnes peuvent écrire à d'autres personnes via un formulaire. Le problème, c'est qu'il y a toujours des robots ou des scripts. Par exemple, pas plus tard qu'avant-hier : 179 messages envoyés en même pas une heure.
J'ai déjà mis en place certaines mesures comme une liste de mots-clés qui permet de mettre en attente les messages « suspects » en attendant une validation humaine. Mais les scammeurs (ce sont souvent des scammeurs) sy' habituent... J'ai mis en place une liste noire également à partir de l'email déclarée.
J'avais pensé effectivement à la solution du chiffre et de l'image mais ça peut être inaccessible.
J'avais pensé à plusieurs solutions : - Mettre dans le Alt le chiffre en toutes lettres. Par exemple : l'image « 1234 » aurait comme alternative « un deux trois quatre ». Mais bon, les robots s'y adapteraient aussi. - Alterner les champs. Par exemple, au lieu de mettre automatiquement « Nom, email, sujet du message, corps du message », faire en sorte que les 3 premiers champs soient tirés au hasard. « Email, nom, sujet et corps » une fois, « Sujet, email, nom et corps » une autre fois, etc.
Mais je ne sais pas si ça marchera vu que je ne sais pas quels logiciels ils utilisent ni leur méthode.
Reste la solution de la base de données qui enregistrerait tous les courriers qui sortent avec email, date et heure d'envoi pour pouvoir analyser à chaque envoi de message si le rythme est celui d'un robot ou pas. Un peu lourd quoi...
N'hésitez pas à rediriger le message sur fr.usenet.abus.d ou fr.comp.securite s'il le faut... -- Ludovic LE MOAL
Ganf nous a schtroumfé :
La seule méthode qui va pouvoir te permettre de faire un tri correct
c'est limiter le nombre de soumission. S'il y en a trop, ou trop rapides,
ou trop fréquentes, ou à des horaires réguliers ... alors c'est
probablement un robot et il faut bloquer.
Je suis confronté au même problème que Philippe : j'ai un site où des
personnes peuvent écrire à d'autres personnes via un formulaire. Le
problème, c'est qu'il y a toujours des robots ou des scripts. Par exemple,
pas plus tard qu'avant-hier : 179 messages envoyés en même pas une heure.
J'ai déjà mis en place certaines mesures comme une liste de mots-clés qui
permet de mettre en attente les messages « suspects » en attendant une
validation humaine. Mais les scammeurs (ce sont souvent des scammeurs) sy'
habituent... J'ai mis en place une liste noire également à partir de
l'email déclarée.
J'avais pensé effectivement à la solution du chiffre et de l'image mais ça
peut être inaccessible.
J'avais pensé à plusieurs solutions :
- Mettre dans le Alt le chiffre en toutes lettres. Par exemple : l'image «
1234 » aurait comme alternative « un deux trois quatre ». Mais bon, les
robots s'y adapteraient aussi.
- Alterner les champs. Par exemple, au lieu de mettre automatiquement «
Nom, email, sujet du message, corps du message », faire en sorte que les 3
premiers champs soient tirés au hasard. « Email, nom, sujet et corps » une
fois, « Sujet, email, nom et corps » une autre fois, etc.
Mais je ne sais pas si ça marchera vu que je ne sais pas quels logiciels
ils utilisent ni leur méthode.
Reste la solution de la base de données qui enregistrerait tous les
courriers qui sortent avec email, date et heure d'envoi pour pouvoir
analyser à chaque envoi de message si le rythme est celui d'un robot ou
pas. Un peu lourd quoi...
N'hésitez pas à rediriger le message sur fr.usenet.abus.d ou
fr.comp.securite s'il le faut...
--
Ludovic LE MOAL
La seule méthode qui va pouvoir te permettre de faire un tri correct c'est limiter le nombre de soumission. S'il y en a trop, ou trop rapides, ou trop fréquentes, ou à des horaires réguliers ... alors c'est probablement un robot et il faut bloquer.
Je suis confronté au même problème que Philippe : j'ai un site où des personnes peuvent écrire à d'autres personnes via un formulaire. Le problème, c'est qu'il y a toujours des robots ou des scripts. Par exemple, pas plus tard qu'avant-hier : 179 messages envoyés en même pas une heure.
J'ai déjà mis en place certaines mesures comme une liste de mots-clés qui permet de mettre en attente les messages « suspects » en attendant une validation humaine. Mais les scammeurs (ce sont souvent des scammeurs) sy' habituent... J'ai mis en place une liste noire également à partir de l'email déclarée.
J'avais pensé effectivement à la solution du chiffre et de l'image mais ça peut être inaccessible.
J'avais pensé à plusieurs solutions : - Mettre dans le Alt le chiffre en toutes lettres. Par exemple : l'image « 1234 » aurait comme alternative « un deux trois quatre ». Mais bon, les robots s'y adapteraient aussi. - Alterner les champs. Par exemple, au lieu de mettre automatiquement « Nom, email, sujet du message, corps du message », faire en sorte que les 3 premiers champs soient tirés au hasard. « Email, nom, sujet et corps » une fois, « Sujet, email, nom et corps » une autre fois, etc.
Mais je ne sais pas si ça marchera vu que je ne sais pas quels logiciels ils utilisent ni leur méthode.
Reste la solution de la base de données qui enregistrerait tous les courriers qui sortent avec email, date et heure d'envoi pour pouvoir analyser à chaque envoi de message si le rythme est celui d'un robot ou pas. Un peu lourd quoi...
N'hésitez pas à rediriger le message sur fr.usenet.abus.d ou fr.comp.securite s'il le faut... -- Ludovic LE MOAL
Cleo
Bonsoir Philippe,
Si vous avez la possibilité d'utiliser les données de la session, un mécanisme trivial est facilement réalisable. Il suffit de générer un code stocké dans la session: $_SESSION["CODE_ACCEPTATION"] = uniqid("",true);
Lors de la création du formulaire que vous allez ajouter un champ hidden: <input type="hidden" name="CODE_ACCEPTATION" value="<?=$_SESSION["CODE_ACCEPTATION"] ?>" />
La page, recevant le post, traitera les informations seulement dans cas où : $_SESSION["CODE_ACCEPTATION"] == $_POST["CODE_ACCEPTATION"] et générera un nouveau code d'acceptation dans la session.
Le mécanisme, ainsi défini, permet de créer des "formulaires à usage unique", donc d'éviter les problèmes dits de 'flooding'. Cependant si votre besoin est de garantir le fait que l'information ait bien été saisie par un 'humain' (ce qui constitue un autre problème à mon sens), je suis hors sujet.
Voila tout.
Bonsoir Philippe,
Si vous avez la possibilité d'utiliser les données de la session, un
mécanisme trivial est facilement réalisable.
Il suffit de générer un code stocké dans la session:
$_SESSION["CODE_ACCEPTATION"] = uniqid("",true);
Lors de la création du formulaire que vous allez ajouter un champ hidden:
<input type="hidden" name="CODE_ACCEPTATION"
value="<?=$_SESSION["CODE_ACCEPTATION"] ?>" />
La page, recevant le post, traitera les informations seulement dans cas où :
$_SESSION["CODE_ACCEPTATION"] == $_POST["CODE_ACCEPTATION"]
et générera un nouveau code d'acceptation dans la session.
Le mécanisme, ainsi défini, permet de créer des "formulaires à usage
unique", donc d'éviter les problèmes dits de 'flooding'. Cependant si votre
besoin est de garantir le fait que l'information ait bien été saisie par un
'humain' (ce qui constitue un autre problème à mon sens), je suis hors
sujet.
Si vous avez la possibilité d'utiliser les données de la session, un mécanisme trivial est facilement réalisable. Il suffit de générer un code stocké dans la session: $_SESSION["CODE_ACCEPTATION"] = uniqid("",true);
Lors de la création du formulaire que vous allez ajouter un champ hidden: <input type="hidden" name="CODE_ACCEPTATION" value="<?=$_SESSION["CODE_ACCEPTATION"] ?>" />
La page, recevant le post, traitera les informations seulement dans cas où : $_SESSION["CODE_ACCEPTATION"] == $_POST["CODE_ACCEPTATION"] et générera un nouveau code d'acceptation dans la session.
Le mécanisme, ainsi défini, permet de créer des "formulaires à usage unique", donc d'éviter les problèmes dits de 'flooding'. Cependant si votre besoin est de garantir le fait que l'information ait bien été saisie par un 'humain' (ce qui constitue un autre problème à mon sens), je suis hors sujet.
Voila tout.
Philippe
"Cleo" a écrit dans le message de news:41570bb2$0$1516$
Le mécanisme, ainsi défini, permet de créer des "formulaires à usage unique", donc d'éviter les problèmes dits de 'flooding'.
Merci beaucoup pour cette idée, j'avais pensé à un truc comme cela, mais en fait la faille est la suivante : il suffit de se déconnecter du site puis de se reconnecter, alors un nouveau formulaire, avec un nouveau code est rechargé et est donc à nouveau validable. Un script peut facilement simuler cela.
Cependant si votre besoin est de garantir le fait que l'information ait bien été saisie par un
'humain' (ce qui constitue un autre problème à mon sens), je suis hors sujet.
Non non ce dont j'ai besoin est de garantir que le formulaire ne puisse pas être valider par un script qui tournerait en boucle.
*** Philippe
"Cleo" <cleo@no-spam.net> a écrit dans le message de
news:41570bb2$0$1516$636a15ce@news.free.fr...
Le mécanisme, ainsi défini, permet de créer des "formulaires à usage
unique", donc d'éviter les problèmes dits de 'flooding'.
Merci beaucoup pour cette idée, j'avais pensé à un truc comme cela, mais en
fait la faille est la suivante : il suffit de se déconnecter du site puis
de se reconnecter, alors un nouveau formulaire, avec un nouveau code est
rechargé et est donc à nouveau validable. Un script peut facilement simuler
cela.
Cependant si votre
besoin est de garantir le fait que l'information ait bien été saisie par
un
'humain' (ce qui constitue un autre problème à mon sens), je suis hors
sujet.
Non non ce dont j'ai besoin est de garantir que le formulaire ne puisse pas
être valider par un script qui tournerait en boucle.
"Cleo" a écrit dans le message de news:41570bb2$0$1516$
Le mécanisme, ainsi défini, permet de créer des "formulaires à usage unique", donc d'éviter les problèmes dits de 'flooding'.
Merci beaucoup pour cette idée, j'avais pensé à un truc comme cela, mais en fait la faille est la suivante : il suffit de se déconnecter du site puis de se reconnecter, alors un nouveau formulaire, avec un nouveau code est rechargé et est donc à nouveau validable. Un script peut facilement simuler cela.
Cependant si votre besoin est de garantir le fait que l'information ait bien été saisie par un
'humain' (ce qui constitue un autre problème à mon sens), je suis hors sujet.
Non non ce dont j'ai besoin est de garantir que le formulaire ne puisse pas être valider par un script qui tournerait en boucle.
*** Philippe
CrazyCat
Philippe wrote:
Non non ce dont j'ai besoin est de garantir que le formulaire ne puisse pas être valider par un script qui tournerait en boucle.
Un contrôle IP/temps entre 2 envois? Il suffit de stocker l'IP de l'émetteur d'un message (getenv("REMOTE_ADDR")) et le timestamp unix de l'envoit, et à la validation du formulaire, vérifier que date() > timestamp + X min pour cette IP.
C'est le système antiflood de base sur les forums, il devrait marcher aussi sur ton site.
-- Tout sur les eggdrops http://www.c-p-f.org ML @
Philippe wrote:
Non non ce dont j'ai besoin est de garantir que le formulaire ne puisse pas
être valider par un script qui tournerait en boucle.
Un contrôle IP/temps entre 2 envois?
Il suffit de stocker l'IP de l'émetteur d'un message
(getenv("REMOTE_ADDR")) et le timestamp unix de l'envoit, et à la
validation du formulaire, vérifier que date() > timestamp + X min pour
cette IP.
C'est le système antiflood de base sur les forums, il devrait marcher
aussi sur ton site.
--
Tout sur les eggdrops
http://www.c-p-f.org
ML @ eggdrop_fr@yahoogroupes.fr
Non non ce dont j'ai besoin est de garantir que le formulaire ne puisse pas être valider par un script qui tournerait en boucle.
Un contrôle IP/temps entre 2 envois? Il suffit de stocker l'IP de l'émetteur d'un message (getenv("REMOTE_ADDR")) et le timestamp unix de l'envoit, et à la validation du formulaire, vérifier que date() > timestamp + X min pour cette IP.
C'est le système antiflood de base sur les forums, il devrait marcher aussi sur ton site.
-- Tout sur les eggdrops http://www.c-p-f.org ML @
Ludovic LE MOAL
Ludovic LE MOAL nous a schtroumpfé :
- Alterner les champs. Par exemple, au lieu de mettre automatiquement « Nom, email, sujet du message, corps du message », faire en sorte que les 3 premiers champs soient tirés au hasard. « Email, nom, sujet et corps » une fois, « Sujet, email, nom et corps » une autre fois, etc.
Mais je ne sais pas si ça marchera vu que je ne sais pas quels logiciels ils utilisent ni leur méthode.
Finallement, j'ai essayé avec wget sous Windows et rien n'est plus simple que de flooder un formulaire. En particulier, la méthode d'alterner les champs est complètement débile et ne fera qu'embêter les gentils utilisateurs.
Par contre, la méthode décrite par Cleo dans son message news:41570bb2$0$1516$ marche bien contre les attaques à wget. Tout du moins, je n'ai pas trouvé de solution contre.
Je continue mes recherches sur la programmation de formulaire... -- Ludovic LE MOAL
Ludovic LE MOAL nous a schtroumpfé :
- Alterner les champs. Par exemple, au lieu de mettre automatiquement
« Nom, email, sujet du message, corps du message », faire en sorte que
les 3 premiers champs soient tirés au hasard. « Email, nom, sujet et
corps » une fois, « Sujet, email, nom et corps » une autre fois, etc.
Mais je ne sais pas si ça marchera vu que je ne sais pas quels
logiciels ils utilisent ni leur méthode.
Finallement, j'ai essayé avec wget sous Windows et rien n'est plus simple
que de flooder un formulaire. En particulier, la méthode d'alterner les
champs est complètement débile et ne fera qu'embêter les gentils
utilisateurs.
Par contre, la méthode décrite par Cleo dans son message
news:41570bb2$0$1516$636a15ce@news.free.fr marche bien contre les attaques
à wget. Tout du moins, je n'ai pas trouvé de solution contre.
Je continue mes recherches sur la programmation de formulaire...
--
Ludovic LE MOAL
- Alterner les champs. Par exemple, au lieu de mettre automatiquement « Nom, email, sujet du message, corps du message », faire en sorte que les 3 premiers champs soient tirés au hasard. « Email, nom, sujet et corps » une fois, « Sujet, email, nom et corps » une autre fois, etc.
Mais je ne sais pas si ça marchera vu que je ne sais pas quels logiciels ils utilisent ni leur méthode.
Finallement, j'ai essayé avec wget sous Windows et rien n'est plus simple que de flooder un formulaire. En particulier, la méthode d'alterner les champs est complètement débile et ne fera qu'embêter les gentils utilisateurs.
Par contre, la méthode décrite par Cleo dans son message news:41570bb2$0$1516$ marche bien contre les attaques à wget. Tout du moins, je n'ai pas trouvé de solution contre.
Je continue mes recherches sur la programmation de formulaire... -- Ludovic LE MOAL
Philippe
"CrazyCat" a écrit dans le message de news:41581fe7$0$13145$
Un contrôle IP/temps entre 2 envois? Il suffit de stocker l'IP de l'émetteur d'un message (getenv("REMOTE_ADDR")) et le timestamp unix de l'envoit, et à la validation du formulaire, vérifier que date() > timestamp + X min pour cette IP.
Bon ok en attendant je vais me rabattre la-dessus, mais il suffit que le hacker détecte le temps de latence entre deux envoi et c'est bon il peut faire tourner son script plusieurs jours...
merci quand-même !
*** Philippe
"CrazyCat" <crazycat@nospam.org> a écrit dans le message de
news:41581fe7$0$13145$636a15ce@news.free.fr...
Un contrôle IP/temps entre 2 envois?
Il suffit de stocker l'IP de l'émetteur d'un message
(getenv("REMOTE_ADDR")) et le timestamp unix de l'envoit, et à la
validation du formulaire, vérifier que date() > timestamp + X min pour
cette IP.
Bon ok en attendant je vais me rabattre la-dessus, mais il suffit que le
hacker détecte le temps
de latence entre deux envoi et c'est bon il peut faire tourner son script
plusieurs jours...
"CrazyCat" a écrit dans le message de news:41581fe7$0$13145$
Un contrôle IP/temps entre 2 envois? Il suffit de stocker l'IP de l'émetteur d'un message (getenv("REMOTE_ADDR")) et le timestamp unix de l'envoit, et à la validation du formulaire, vérifier que date() > timestamp + X min pour cette IP.
Bon ok en attendant je vais me rabattre la-dessus, mais il suffit que le hacker détecte le temps de latence entre deux envoi et c'est bon il peut faire tourner son script plusieurs jours...
