Eviter le SPAM et le piratage

Répondre


Cette question est un moyen d’empêcher des soumissions automatisées de formulaires par des robots.
Smileys
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :!: :?: :idea: :arrow: :| :mrgreen: =D> #-o =P~ :^o :non: :priere: 8-|
Voir plus de smileys
  Revue du sujet
 

  Étendre la vue Revue du sujet : Eviter le SPAM et le piratage

par dunbar » 28 mai 2008, 17:45

Regarde le titre que j'ai mis en ouvrant le post
Eviter le SPAM et le piratage
:wink:

par Sékiltoyai » 28 mai 2008, 00:41

On ne cherche pas à limiter des attaques, on veut que les robots ne puissent pas poster une seule fois…

par dunbar » 27 mai 2008, 22:48

ou encore mieux usleep(100000) = 1/10 de seconde qui est invisible pour un être humain, mais gêne considérablement une attaque par force brute par exemple :?
Hum, je crois pas que tu ait bien saisi la dernière réponse de Cyrano, qui disait (si j'ai bien compris) que les robots peuvent éventuellement utiliser la fonction sleep pour simuler un comportement humain...
Si je pense avoir bien compris je m’explique :
Si le site répond en une milliseconde par exemple un pirate ou un srcipt automatique pourra tester +/- mille mots par seconde !
Avec un usleep(100000) ont réduit considérablement la vitesse d’attaque à +/- 10 par seconde :)

par AB » 27 mai 2008, 22:39

ou encore mieux usleep(100000) = 1/10 de seconde qui est invisible pour un être humain, mais gêne considérablement une attaque par force brute par exemple :?
Hum, je crois pas que tu ait bien saisi la dernière réponse de Cyrano, qui disait (si j'ai bien compris) que les robots peuvent éventuellement utiliser la fonction sleep pour simuler un comportement humain...

par dunbar » 27 mai 2008, 22:30

ou encore mieux usleep(100000) = 1/10 de seconde qui est invisible pour un être humain, mais gêne considérablement une attaque par force brute par exemple :?

par Cyrano » 17 mai 2008, 07:38

...j'irai jusqu'à dire que s'il n'y a que 10 tentatives en 3 minutes, il y a fort peu de chances pour que ce soit un robot qui soit derrière...
Sauf que ce n'est pas par rapport aux performances d'un robot que je ferais mes mesures mais par rapport aux performances humaines. Les meilleures dactylos tapent jusqu'à 120 mot/minute : l'internaute lambda ne doit pas dépasser 30 ou 40. Donc au départ, je sais à peu près à quel stade il est certain que ce n'est pas un humain à qui j'ai affaire. Mais attention toutefois à un point important : certains robots évoluent et en tiennent compte aussi. Selon le langage dans lequel il est écrit, il est possible d'utiliser un système pour temporiser entre deux tentatives. En PHP on a sleep() par exemple.

par AB » 17 mai 2008, 04:46

10 tentatives en moins de 3 minutes, il y a fort peu de chances pour que ce soit un humain qui soit derrière.
Tu ma jamais vue m'énervé sur mon clavier :!: :lol:
Je plaisante oui pourquoi pas je vais étudier la mise en place
Merci
Effectivement si tu te lance dans ce genre de contrôle tu as intérêt de bien calibrer le processus. Parce que j'irai jusqu'à dire que s'il n'y a que 10 tentatives en 3 minutes, il y a fort peu de chances pour que ce soit un robot qui soit derrière.
Ou alors c'est un robot farniente qui a su acquérir des droits sociaux bien supérieurs aux nôtres :lol:

par dunbar » 16 mai 2008, 23:25

10 tentatives en moins de 3 minutes, il y a fort peu de chances pour que ce soit un humain qui soit derrière.
Tu ma jamais vue m'énervé sur mon clavier :!: :lol:
Je plaisante oui pourquoi pas je vais étudier la mise en place
Merci

par Cyrano » 16 mai 2008, 23:18

Quand je parlais de chronomètre, ce n'était pas une question de durée de vie de formulaire mais de mesure d'écart entre deux tentatives de validation pour une même session : si tu as par exemple 10 tentatives en moins de 3 minutes, il y a fort peu de chances pour que ce soit un humain qui soit derrière.

par dunbar » 16 mai 2008, 17:28

Peut-être lu trop vite mais je ne comprend pas cette histoire de validation limitée à 10 minutes.

Etant donné que les noms de tes champs sont uniques et valides uniquement pour la durée de la session, ils ne seront utilisables que pour cette session.

Donc pour que ton formulaire ne puisse pas être copié et utilisé de l'extérieur (en dehors de la session en cour) une simple validation de type if(isset($_POST[$_SESSION['form_nom']])... devrait suffire :-k
Je travaillais sur deux pistes :

:arrow: La première étais une durée vie au formulaire pour évité principalement l'exporation de celui-ci etc....
:arrow: La seconde piste étais celle de crypté le formulaire.

J'ai opter pour la seconde solution donc éffectivement donner une durée de vie à mon formulaire n'a plus aucun sens.
Le cas que j'utilise est celui des session que je détruit une fois le formulaire valider et comme chaque session est unique je pense que je suis tranquille :wink:

par AB » 16 mai 2008, 17:07

Peut-être lu trop vite mais je ne comprend pas cette histoire de validation limitée à 10 minutes.

Etant donné que les noms de tes champs sont uniques et valides uniquement pour la durée de la session, ils ne seront utilisables que pour cette session.

Donc pour que ton formulaire ne puisse pas être copié et utilisé de l'extérieur (en dehors de la session en cour) une simple validation de type if(isset($_POST[$_SESSION['form_nom']])... devrait suffire :-k

par dunbar » 16 mai 2008, 15:37

La session reste valide tant que l'internaute reste connecté au site... pour autant que tu n'oublies pas un session_start() en cours de route. Ceci dit, une fois le formulaire valider, tu as aussi la possibilité de vider les valeurs de session propres au formulaire.
Je détruit le session une fois le formulaire valider
Donc merci je continue sur ma lancer, puisque tu me semble d'accord sur le principe :wink:

par Cyrano » 16 mai 2008, 15:33

La session reste valide tant que l'internaute reste connecté au site... pour autant que tu n'oublies pas un session_start() en cours de route. Ceci dit, une fois le formulaire valider, tu as aussi la possibilité de vider les valeurs de session propres au formulaire.

par dunbar » 16 mai 2008, 15:21

il manquerait peut-être un compteur de tentatives avec un chronomètre pour parer les possibles attaques en force brute... mais bon, c'est peut-être excessif
:lol: J'ai pas oser montrer cette partie mais le formulaire reste valable 10 minutes sinon il est rejeter.
$date = md5('SEL' .date('Y-m-d h:i:00");
La validation
$validation = range(0, 10);  #entre 0 et 10 minutes sinon refus du formulaire
$valide = false ;
foreach($validation as $v){
	if($valide|= ($_POST['date']) == md5('Sel'.date('y-m-d h:i:00', mktime() +$v * 60 ))){

	       

Donc pour une fois mon idée n'étais pas trop mauvaise :wink:
Quand à mes session arrête moi si je me trompe, la session se créer à l'ouverture du formulaire et se termine une fois celui-ci valider donc comme je place les valeurs de mes champs en session je ne sait pas les perdre :-k
Et les test me montre que je récupére bien les bonne valeur .

par Cyrano » 16 mai 2008, 15:09

Que se passera-t-il avec l'internaute qui affiche le formulaire à 23h59 et qui clique sur le bouton d'envoi à 0h00 ? J'essayerais plutôt d'utiliser un système de noms stockés en session au moment de la création du formulaire pour être certain de récupérer les mêmes à la validation.

L'intérêt de ton idée est qu'aucun robot ne pourra utiliser le formulaire efficacementr, le nom des champs changeant à chaque nouvel affichage : ça coupe toute possibilité d'envoi de données depuis une copie du formulaire sur le site du pirate lui-même. Second intérêt, c'est que le nom de chaque champ n'ayant aucun sens, le robot ne saura pas quel type de donnée est attendue : la validation éjectera rapidement la validation : il manquerait peut-être un compteur de tentatives avec un chronomètre pour parer les possibles attaques en force brute... mais bon, c'est peut-être excessif :-k