Commentaires sur une source : QUESTIONS ANTI FLOOD

ekremyilmaz Messages postés 3 Date d'inscription mercredi 6 octobre 2004 Statut Membre Dernière intervention 23 août 2007
23 août 2007 à 00:05

j'ai remarqué un truc bizarre.
dans les question à chiffre, parfois aucun chiffre n'apparait, exemple taper le chiffre ? et meme dans les opération 1* = ?
a ton avis ça vient de la fonction randomint ?

coucou747 Messages postés 12303 Date d'inscription mardi 10 février 2004 Statut Membre Dernière intervention 30 juillet 2012 44
13 juil. 2007 à 11:53

... j'ai fait un tas de fonctions, c'est a toi de faire les appels comme bon te semble (en mettant les resultats en session pour verification apres le post...)

ekremyilmaz Messages postés 3 Date d'inscription mercredi 6 octobre 2004 Statut Membre Dernière intervention 23 août 2007
13 juil. 2007 à 11:47

tu affiche la réponse en bas ?
est ce grave ou on peut laisser pour donner à l'utilisateur de répondre plus rapidement.

cs_Kirua Messages postés 3006 Date d'inscription dimanche 14 avril 2002 Statut Membre Dernière intervention 31 décembre 2008
31 janv. 2007 à 13:28

Je sais bien, mais ce n'est pas la question: dans ce cas particulier, ça paraît franchement raisonnable d'opter pour le cas O(1). Du reste, dans la mesure ou ça changera d'une µs, autant prendre la version la plus courte et la plus claire. La plus simple à maintenir et à lire, etc. ici, tu as plein de cas assez particuliers, que tu peux éviter simplement avec un tableau défini dans les bonnes bornes.

coucou747 Messages postés 12303 Date d'inscription mardi 10 février 2004 Statut Membre Dernière intervention 30 juillet 2012 44
31 janv. 2007 à 13:23

faudrait voir... un sqort contre un tri à bulles, le qsort ne gagne pas pour les petites listes (si je me souviens bien...)

cs_Kirua Messages postés 3006 Date d'inscription dimanche 14 avril 2002 Statut Membre Dernière intervention 31 décembre 2008
31 janv. 2007 à 13:21

Non mais je suis assez sur de mon coup ;) Et les constantes seront comparables dans ce cas.

coucou747 Messages postés 12303 Date d'inscription mardi 10 février 2004 Statut Membre Dernière intervention 30 juillet 2012 44
31 janv. 2007 à 13:16

pour n=13, un algo en 100*1 ou en 4*n, c'est pas forcément judicieux...

cs_Kirua Messages postés 3006 Date d'inscription dimanche 14 avril 2002 Statut Membre Dernière intervention 31 décembre 2008
30 janv. 2007 à 19:20

c'est tout vu: complexité O(1) contre O(n), et en plus en interprêté, du code court c'est tjs une bonne idée.

coucou747 Messages postés 12303 Date d'inscription mardi 10 février 2004 Statut Membre Dernière intervention 30 juillet 2012 44
30 janv. 2007 à 16:50

possible pour le switch... faudrait bencher...

cs_Kirua Messages postés 3006 Date d'inscription dimanche 14 avril 2002 Statut Membre Dernière intervention 31 décembre 2008
29 janv. 2007 à 21:12

Question de temps essentiellement :/. Mais on se verra à prologin :) (enfin, sous réserve de).

Ceci dit, je reviens quand même sur ta façon d'écrire les nombres entiers en toutes lettres: je suis certain que tu peux échanger avantageusement tes switch pour des tableaux.

coucou747 Messages postés 12303 Date d'inscription mardi 10 février 2004 Statut Membre Dernière intervention 30 juillet 2012 44
29 janv. 2007 à 10:42

"Et rendre les choses plus compliquées avec des images etc ne réduira que le nombre de programmeurs capables de passer les tests"=> personellement, je penses que la patience peut le réduire suffisement... le but de toute sécurité est de réduire ce nombre...

on pourrait dire que chaque solution est mauvaise : mettre l'ip en bdd et interdire une ip de poster plus de 3 messages par jours, ça pénalise les entreprises, écoles ou autres groupes de gens derière une seule ip, et tor permet d'avoir plein d'ips...

le javascript n'est pas supporté partout.

les images ne sont pas disponibles aux mal voyants.

les wav ne sont pas disponibles aux gens qui n'ont pas de son, et pour ceux qui écoutent déjà de la musique, c'est chiant (mais moins, je l'accorde).

et enfin, là, pour une attaque ciblée, ça tient au fait que l'attaquant soit patient (comme toute attaque non ?)

kirua abandonne le dev... toi qui m'a tant appris sur le C... enfin bon, t'as fait ton choix, personellement, je trouve que c'est un énorme gachis...

cs_Kirua Messages postés 3006 Date d'inscription dimanche 14 avril 2002 Statut Membre Dernière intervention 31 décembre 2008
27 janv. 2007 à 23:08

J'ai réfléchi quelques minutes, mais je ne vois pas de façon simple ni efficace de réaliser la chose sans JS ... Quelqu'un a une idée? Je ne fais plus de dev web (ni de dev tt court ^^) depuis trop longtemps ... Perdu la souplesse et l'imaginativité des workaround ;).

cs_wizad Messages postés 355 Date d'inscription samedi 30 octobre 2004 Statut Membre Dernière intervention 14 avril 2009
27 janv. 2007 à 19:33

ce sujet est effectivement des plus intérréssant et mériterais presque un bon débat sur un forum.

Pour ton idée de javascript Kirua c'est vrai que l'idée est bonne mets néammoins cela poserais un problèmes sérieux pour les navigateur n'implémentant pas le javascript comme cela peut être la cas pour certains navigateurs destinés aux personnes ayant un handicap.

cs_Kirua Messages postés 3006 Date d'inscription dimanche 14 avril 2002 Statut Membre Dernière intervention 31 décembre 2008
27 janv. 2007 à 18:08

Maintenant que j'y pense, ce qu'on cherche fondamentalement, c'est un problème dont on puisse construire un très grand nombre d'occurrences différentes de manière systématique, donc la réponse soit donnée par le mécanisme de construction (ie: quand on génère le problème, on a ou on définit sa solution dans la foulée) mais dont la résolution systématique "à coup sûr" (une seule chance de répondre) soit impossible (enfin, l'impossibilité, c'est pour le but ultime ^^). Et on a une constrainte de plus ici: on voudrait que toutes les informations ne soient que du texte / des chiffres (par opposition aux captchas "images"). Evidemment, la résolution du problème doit être rapide et aisée pour un humain moyennement débile (c'est la condition de base ^^).

C'est franchement pas facile ^^. Mais on peut déjà penser que, vu la façon dont le problème est reformulé ici, tout captcha doit (devrait) partir de la réponse attendue. On peut donc se donner un nombre ou un mot, et tenter de construire une question dont ce soit la réponse, tout en rendant difficile le travail inverse pour une machine ...

Ce sujet est génial :D

cs_Kirua Messages postés 3006 Date d'inscription dimanche 14 avril 2002 Statut Membre Dernière intervention 31 décembre 2008
27 janv. 2007 à 17:56

Hmm, le cookie c'est juste un champ à passer dans l'en-tête de la requête HTTP. Pour quelqu'un qui code son propre flooder en C++ ou en PHP par exemple, en construisant et en émettant la requête HTTP lui-même, c'est facile de mettre tout ce que tu veux dans ce champ, et donc de simuler un cookie ad hoc, sans utiliser les fonctions de l'API Win32 pour la manip des cookies, par exemple (ce qui est over chiant).

Ce serait pas plus facile d'avoir un tableau $nums = {'zéro', 'un', 'deux' ...}; que ton énorme switch?

De mon point de vue, écrire un grand nombre de questions ne te protège pas du flood: ces questions, tu les écriras tjs à la main: ton courage à la rédaction sera toujours battable par la patience de celui qui les répertoriera manuellement ;). Il vaut mieux, AMHA, ne considérer que les tests générés de manière automatique. De ce point de vue, les calculs à résoudre sont une bonne idée, mais écrire "plus" plutôt que "+" ne change en rien la difficulté pour le hacker. Ecrire un interpréteur arithmétique est franchement aisé quand on a compris le truc: pas efficace.

En toutes hypothèses, il faut se poser la question suivante: est-ce qu'on veut se prémunir d'une attaque ciblée, ou des attaques "crawler" ? Pour les crawler, c'est facile: il suffit de penser à un système qui détecte le fait que le formulaire a été rempli dans le navigateur web (par opposition aux requêtes GET et POST émises par un programme sans passer par la page web de soumission). Je dis pas ça juste en l'air: je l'ai fait pour un de mes livres d'or qui avait bouffé 25000 spams: plus rien n'est passé, en 4-5 lignes de JS / HTML. L'idée de base est consternante de simplicité: une action de l'utilisateur sur un des champs déclenche un mini javascript qui rempli un champ "hidden" du formulaire. A la réception, on vérifie la valeur. Un crawler ne va certainement pas exécuter le javascript -> il ne passera pas. Même pas la peine d'implémenter un CAPTCHA.

Mais les attaques ciblées, c'est franchement plus dur: le pirate comprendra l'astuce tout de suite. Et rendre les choses plus compliquées avec des images etc ne réduira que le nombre de programmeurs capables de passer les tests. C'est une question plus intéressante ^^.

coucou747 Messages postés 12303 Date d'inscription mardi 10 février 2004 Statut Membre Dernière intervention 30 juillet 2012 44
27 janv. 2007 à 14:23

les cookies, ça ne peut pas marcher... sinon, je n'utilise pas ce code, donc, les questions, c'est sorti comme ça... c'était ce à quoi je pensais sur le moment, "à quoi sert une casserole ou un aspirateur ?" c'est du au fait que je dois ranger ma chambre, et que je me fais ma bouffe seul maintenant :=)

codefalse Messages postés 1123 Date d'inscription mardi 8 janvier 2002 Statut Modérateur Dernière intervention 21 avril 2009 1
25 janv. 2007 à 21:40

autant pour moi
en fait j'ai mélangé deux sources ou je poste des commentaires, donc je me suis un peu emmelé les pinceaux pour les commentaires :)
tu a tout a fait raison, si le cookie est la pour bloquer, ca ira pas si c'est un bot qui l'utilise

bon apres il existe diverses autres méthodes plus utiles les unes aux autres (utilisation de bdd par exemple) en sachant que de toute facon, dans l'absolu, il y aura toujours moyen de contourner la protection :)

cs_wizad Messages postés 355 Date d'inscription samedi 30 octobre 2004 Statut Membre Dernière intervention 14 avril 2009
25 janv. 2007 à 20:47

Dans ton exemple (1er coms) : une fois le form validé, le site envoi un cockie indiquant que le formulaire à déja été soumis et ne peut donc être resoumis.

Ainsi si le coockie est supprimé on peut à nouveau soumettre le formulaire.

Ensuite tu me parle de formulaire externe. Généralement les hackers (floodeur) les plus courants passent par un script type bot configuré en fonction d'un ou plusieur site cible afin d'envoyer un trés grand nombre de requetes HTTP similaire à la requète qu'effectuerais un navigateur lors de l'envoie du formulaire.

La technique de site externe dont tu fait allusion est justement utilisé pour contourner les méthodes de sécurité (Et le coockie ne l'empêchera pas). Cette technique se base généralement sur une inscription sur un site différent mais recopiant le système de sécurité anti-bots du site à flooder. Lorsque les utilisateurs s'inscrivent en passant le système de sécuriter cela active l'inscription bidon sur le site visé (j'ai pris l'inscription comme cible mais tout formulare peut être visé).

codefalse Messages postés 1123 Date d'inscription mardi 8 janvier 2002 Statut Modérateur Dernière intervention 21 avril 2009 1
25 janv. 2007 à 19:59

alors justement, si le "hacker" dégage le cookie, le code ne marche plus ! donc il ne pourra pas mettre les données

.. sauf si j'ai pas compris ton idée

bon, on contraire, s'il arrive à récuperer le cookie, c'est mort, maintenant faut savoir de 1 que ca passe par cookie, et etre tres motivé pour faire un script qui gere ca ...
en effet, le but c'est de faire une formulaire externe qui pointe sur la page de post du script en cours (page dans le action du form) hors, si on genere un cookie pour récuperer la valeur, faudra savoir quel calcul faire et quel est le résultat, donc charger la page du formulaire pour avoir ces infos + la page de post pour mettre ces infos : c'est carrément plus chiant

cs_wizad Messages postés 355 Date d'inscription samedi 30 octobre 2004 Statut Membre Dernière intervention 14 avril 2009
25 janv. 2007 à 18:57

quand je parle du coockie s'était pour toi ;)

codefalse Messages postés 1123 Date d'inscription mardi 8 janvier 2002 Statut Modérateur Dernière intervention 21 avril 2009 1
25 janv. 2007 à 12:07

Wizad, ton post était pour moi ou la source ? (quand tu parle de cookie) ? :)

cs_wizad Messages postés 355 Date d'inscription samedi 30 octobre 2004 Statut Membre Dernière intervention 14 avril 2009
25 janv. 2007 à 10:08

et à ton avis un hacker créant un robot ne pensera-t-il pas à virer les coockies entre chaque tentative (ce qui est assez simple)?

Par contre j'ai pas bien pigé le coup du javascript étant donné que la question reste en clair dans le fichier (oui je sait que tu avais pas la force de faire le cryptage)...

Je n'ai pas non plus saisie l'utilité de tes deux fonctions sur les couleurs.

Sinon sur le système en lui même bien qu'intérréssant par la variété des questions, il est dommage que certaine question soit un peu compliqué (pour les internautes) et voire un peu trop porté sur une culture nationale ou informatique nécéssaire (Je suis pas sur que tous les internautes connaissent Linus Torvald et Larry Wall.

Ni que des québecois ne connaissent Optic 2000 (encore que le nom est plutot explicite).

codefalse Messages postés 1123 Date d'inscription mardi 8 janvier 2002 Statut Modérateur Dernière intervention 21 avril 2009 1
24 janv. 2007 à 22:17

Bien que ton idée est sympa j'ai pas tout compris et je la trouve très longue pour quelque chose qui pourrait être plus simple... enfin je pense.
Dans l'idée, tu applique les variable 1 un, 2 deux, etc..
ensuite tu fait le calcul correspondant (en algo : mavar = key(a) + key(b)) que l'on met dans un cookie, ensuite on affiche "mettez le résultat de ".value(a)." plus ".value(b)." : ";

et dans la réception du formulaire on compare les résultats.
Ca me semble carrément plus simple à mettre en oeuvre non ?
Après, cette idée là est pour empecher les moteurs de gerer le formulaire.
Pour une histoire d'antiflood, tu met une variable en cookie avec une durée de x minutes, et tant qu'elle existe, impossible de re-valider le formulaire.

Non ?

QUESTIONS ANTI FLOOD

Votre réponse

Discussions similaires