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

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
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

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

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

Je travaillais sur deux pistes :

La première étais une durée vie au formulaire pour évité principalement l'exporation de celui-ci etc....

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

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

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

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

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

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

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

Eviter le SPAM et le piratage

Répondre

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