OK, voici un problème: dans le projet que je travaille, nous ne pouvons pas compter sur des sessions côté serveur pour une fonctionnalité. p>
Le problème est que les solutions CAPTCHA communes de prévention robotique soumise nécessitent une session de stocker la chaîne pour correspondre à CAPTCHA contre. P>
La question est - y a-t-il un moyen de résoudre le problème sans utiliser des sessions? Ce qui se voit à mon esprit - sert de champ de formulaire caché, contenant du hachage, avec le champ de saisie CAPTCHA, de sorte que le serveur puisse ensuite correspondre à ces deux valeurs ensemble. Mais comment pouvons-nous faire la sécurité de cette méthode afin qu'elle ne puisse pas être utilisée pour casser facilement CAPTCHA. P>
13 Réponses :
Vous pouvez essayer de stocker un tas de codes CAPTCHA dans une base de données. Alternativement, il y a une belle discussion sur les méthodes alternatives CAPTCHA ici: approches CAPTCHA à base non identiques? p>
Certaines techniques assez intéressantes ont vraiment une lecture. P>
Faites votre champ de saisie caché juste une séquence aléatoire. Conservez ces données aléatoires dans la base de données avec les informations CAPTCHA, vous pouvez donc rechercher le CAPTCHA correct avec celui-ci. p>
Vous aurez également besoin de définir un temps court-ish pour vivre pour chaque CAPTCHA généré. Enfin, vous pouvez stocker et suivre dans la base de données le nombre de tentatives de chaque CAPTCHA et imposer une limite difficile à ce sujet (3 suppositions et c'est un échec permanent). P>
Ce sont les bases de la façon dont les sessions fonctionnent. Stockez les données sur le côté serveur (vos informations CAPTCHA dans la base de données) et associez-la à un ID (votre séquence aléatoire).
Sans le côté serveur d'état persistant, je ne vois pas de captcha travaillant. p>
Ce que vous avez suggéré n'est pas en sécurité car un attaquant pourrait facilement toujours poster son propre "champ caché" avec le texte CAPTCHA correspondant. P>
Pourquoi ne pas faire le CAPTCHA d'un autre serveur Web où vous pouvez avoir un état persistant? p>
Oui, je suis conscient du fait que sans une certaine forme de persistance sur le serveur, l'attaquant peut utiliser la même paire de hash-captcha comme 100 milliards de fois. Mais que si nous salons le hachage de sel avec l'horodatage du serveur et les paires chanceux expireront toutes les 10-20 minutes, que pensez-vous de la sécurité de cette méthode?
Il offre en effet un niveau de sécurité supplémentaire, mais je crains que le sel ne soit assez aléatoire. Une chose à considérer est la sécurité de niveau dont vous avez besoin. Si vous avez besoin de «quelque chose», mais la probabilité de devenir la cible d'une attaque est faible, vous pouvez essayer une méthode de sécurité aussi faible.
Ma propre idée, je ne sais pas, c'est bien: P>
1) Si l'utilisateur est enregistré, utilisez simplement une fonction de hachage sur sa connexion et générer CAPTCHA avec elle, P>
2) S'il s'agit d'un formulaire d'enregistrement, etc. Il suffit de hacher une certaine valeur dans le champ Formulaire (par exemple de connexion, lorsque l'utilisateur a terminé de type IT) et par Ajax Show CAPTCHA avec hachage de connexion. P>
espoir que c'est compréhensible. :) p>
à 1, nous collectons la connexion, etc. Après avoir soumis, nous dirons vers à 2, nous avons une entrée cachée avec ? Login = new_login code> p> p>
Obtenez ["Connexion"] CODE> et HASH à partir de celui-ci dans CAPTCHA Image - Après avoir soumis, nous avons tous pour vérifier la réponse. p>
2) Belle idée :) Mais en faisant cela, nous bloquons les personnes avec JavaScript OFF ou permettent à tous les robots sans que le moteur JS ne passe le CAPTCHA à chaque fois. Corrige moi si je me trompe.
Les bots ne passeront pas CAPTCHA à moins qu'ils ne sachent comment vous vous connectez :)
Oui, mais les vrais clients, qui ne peuvent pas faire d'appels Ajax n'auront pas leur chance de passer non plus?
Eh bien, j'aime bien, notamment combiné - rendre CAPTCHA à la volée pour les clients compatibles AJAX et utiliser le plan B avec une forme à deux étapes pour tous les autres. Prendra cette méthode en considération :)
Sera bien si vous n'oubliez pas voter +1 ma réponse ou simplement la marque comme solution, THX (j'ai remarqué que vous êtes neuf ici): -): -)
Le hash ne serait-il pas le même à chaque fois pour un utilisateur donné, puisque vous déposez la même variable?
Oui, nous pouvons donc ajouter des données aussi ... et envoyez-leur par URL
Pouvez-vous leur accorder un certificat client en réponse à un appel CAPTCHA? Ensuite, une fois qu'ils sélectionnaient ce certificat dans le navigateur, il est envoyé avec chaque appel du client et peut être utilisé pour l'authentification sans sessions et sans autre appel CAPTCHA. P>
C'est un type de certificat similaire, mais il est conservé par le client au lieu du serveur. Avec SSL, le serveur présente le certificat et le client l'accepte. Avec les certificats clients, c'est l'inverse - le client présente (via le navigateur Web) et le serveur Web accepte. Une fois que vous avez sélectionné un certificat client sur le côté du navigateur Web, ce certificat est envoyé à chaque appel (demande ["ClientCertificate"] ou d'une autre), de sorte que vous n'ayez pas à garder l'état de connexion en session. Cela ajoute-t-il des cerceaux pour que le client passe toutefois, et peut ne pas fonctionner pour vous.
Voici ma prise à elle (Sry si cela semble compliqué): P>
à la page Demande: P>
sous la forme: p>
La page CAPTCHA.PHP décrypte le texte crypté et génère l'image. P> LI>
L'utilisateur soumet un formulaire avec le code 'ABCDAA' (et l'entrée cachée $ CRYPT) P> LI>
EDIT: La fonction de chiffrement doit être réversible (déchiffrer), car le générateur d'images CAPTCHA aura besoin du code d'origine. P>
Le problème avec cette méthode est que l'attaquant peut utiliser une paire de valeurs beaucoup de fois.
@Anton N: Pas exactement, si le mot de passe change (il suffit d'ajouter un sel basé sur des informations disponibles telles que l'adresse IP de l'utilisateur, la journée en cours, les informations sur le navigateur ou d'autres autres choses)
Je pense que cette approche est pire que ce que Anton N a suggéré en premier lieu. Utilisez un hachage, évidemment! caché_field = hachage (CAPTCHA + sel) et vérifiez par Hidden_Field == hachage (user_inputted_captcha + sel).
@Yannick M. La question réside dans le fait que le script de génération d'image doit savoir quel code texte générer à la première place. Sans utilisation du serveur de session / dB, le texte doit venir de quelque part ...
La génération d'images est le côté serveur et un hachage du texte + sel est uniquement pour vérifier le résultat après. La chose à propos de la cryptage est si un attaquant peut le casser, ils ont le texte + le mot de passe. Alors qu'ils ne peuvent pas «casser» le hachage, ils ne peuvent trouver que des collisions possibles.
Que diriez-vous de cette solution? J'ai trouvé cet article "PHP Captcha sans session" sur Google et j'ai utilisé sur l'un de mes projets, c'est simple, pas de session et c'est gratuit. Toute préoccupation de sécurité sur RC4? P>
Utilisez le Honeypot Lorsque vous devez assainir le formulaire, vérifiez simplement si ce champ est vide, est en train d'être envoyé par un humain (qui ne peut pas voir le champ et donc le remplir), sinon, d'un spammeur. P>
C'est pourquoi l'utilisation habituellement du spammer pour remplir tous les champs de la page avec des valeurs prédéfinies avant d'envoyer le formulaire ... et ne dérange pas l'utilisateur à lire le CAPTCHA. P>
ailleurs, comptez sur la Ensuite, il vous suffit d'envoyer le mot $ X et $ à la page suivante et de le vérifier (et bien sûr, vous pouvez randomiser le nom des champs à être plus précisé) P>
Je me souviens que un plugin
Les chèvres ne sont pas une solution particulièrement utile, à l'exception des cibles obscures et de faible valeur. C'est une forme de sécurité-globe-obscurité. Cela ne résout pas l'attaque conçue sur mesure. Même pour des attaques non conçues sur mesure, il suppose des robots ne développera pas la capacité d'identifier des champs invisibles, ce qui est assez trivial. Si le manuel a été utilisé par des cibles précieuses, des robots seront ajustés pour interpréter CSS et ignorer des champs invisibles. Le vrai CAPTCHA résout toutes les situations, à l'exception de la méthode "Human SweatShop Solver CAPTCHA" pour laquelle aucune protection n'existe (sauf peut-être sur la liste noire IP).
Le besoin de session ou de base de données provient de la nécessité de coordonner l'image de l'image avec la page HTML contenant, alors que diriez-vous d'utiliser le même code pour incorporer une image CAPTCHA: [IMG SRC = 'Data: Image / JPEG ; base64, ... '], utilisez un sel aléatoire vers le cas de son texte, puis envoyez le sel aléatoire et le hachage avec l'image au client en un seul get? p>
sur le post-plan, vous appendez le texte de l'utilisateur sur le sel puis comparez les hachages. Je me demandais simplement à quel point cela serait sécurisé ... p>
Demandez au générateur CAPTCHA renvoyer une image et utilisez un hachage salé ou un hachage personnalisé pour la réponse (accent sur salé / personnalisé). Demandez au générateur pousser ce hachage dans un cookie. Le serveur peut ensuite valider en fonction de la valeur dans le cookie. Cela ne nécessiterait pas JavaScript, mais si les cookies sont désactivés, vous devez revenir à une autre technique. P>
Le hachage peut être poussé dans un champ de forme cachée. De cette façon, vous n'auriez pas besoin d'un cookie.
@Matt c'est une bonne idée mais je pense que ce n'est pas en sécurité. L'attaquant pourrait utiliser un hachage connu pour un résultat connu (E.g d9a263b9de1023a8cc ... = "928137"), modifier le champ masqué et soumettre avec le résultat connu. Donc contourner le captcha.
@cherouvim C'est pourquoi vous devez saler votre hachage;)
@Matt: L'attaquant peut utiliser un hachage salé connu (découvert de la source HTML) pour un résultat connu (découvert en regardant l'image CAPTCHA).
@cherouvim vous devez lire sur le salage. Il n'y a aucun moyen pour un attaquant de dériver le sel d'une valeur hachée sans dépenser littéralement des millions d'années brute la forçant. Cet argument est notifié dans tous les cas - un attaquant écrit un script pour soumettre le formulaire plusieurs fois pourrait lire le hachage du champ d'en-tête Set-Cookie juste à partir d'un champ de formulaire caché.
@matt si vous me donnez un hachage salé sur la source HTML en tant qu'entrée cachée, et vous me donnez également le captcha respectif comme une image, ce qui m'arrête de "rejouer" que le hasch exact avec la valeur CAPTCHA chaque fois que je dois contourner le captcha?
@cherouvim c'est un point valide. Une solution à ce problème consiste à utiliser une nonce - un jeton unique unique à usage unique - qui ne peut être validée que à la fois, liée directement à la réponse CAPTCHA. J'utiliserais probablement également la nonce dans mon algorithme de salage, ce qui signifierait qu'en plus de la nonce à usage unique, le jeton de la nonce et la réponse CAPTCHA répondent fondamentalement. Semblable à la prévention XSRF.
Remplissez automatiquement un UUID du CAPTCHA avec la réponse de l'utilisateur dans le poteau. Peasy facile. p>
Il suffit de faire un captcha mathématique;) 2 + 90 =? L'équation doit être montrée dans une image et une vila;) p>
Mais vous devez toujours stocker le côté du serveur d'équation et identifier l'expéditeur pour le vérifier. Il ne s'agit pas du défi, il s'agit de la livraison.
Je ne sais pas que voulez-vous dire par «Stocker le côté serveur d'équation», l'équation est renvoyée par PHP, son côté serveur de toute façon.
Formulaire avec validation:
/* font size will be 75% of the image height */ $font_size = $height * 0.75; $image = @imagecreate($width, $height) or die('Cannot initialize new GD image stream'); /* set the colours */ $background_color = imagecolorallocate($image, 255, 255, 255); $text_color = imagecolorallocate($image, 0, 26, 26); $noise_color = imagecolorallocate($image, 25, 89, 89); /* generate random dots in background */ for( $i=0; $i<($width*$height)/3; $i++ ) { imagefilledellipse($image, mt_rand(0,$width), mt_rand(0,$height), 1, 1, $noise_color); } /* generate random lines in background */ for( $i=0; $i<($width*$height)/150; $i++ ) { imageline($image, mt_rand(0,$width), mt_rand(0,$height), mt_rand(0,$width), mt_rand(0,$height), $noise_color); } /* create textbox and add text */ $textbox = imagettfbbox($font_size, 0, $this->font, $code) or die('Error in imagettfbbox function'); $x = ($width - $textbox[4])/2; $y = ($height - $textbox[5])/2; imagettftext($image, $font_size, 0, $x, $y, $text_color, $this->font , $code) or die('Error in imagettftext function'); /* output captcha image to browser */ header('Content-Type: image/jpeg'); imagejpeg($image); imagedestroy($image);
Pourquoi ne pouvez-vous pas compter sur des sessions?
Je veux poser la même session. Aussi aucune séance ne signifie aucune identification de l'utilisateur du tout. Votre script PHP devient apatride. Qu'est-ce que CAPTCHA dans ce système?
Ils mettent la connexion à get ou post-variables;)
Peut-être est juste d'envoyer un formulaire "Contactez-nous".