11
votes

PHP CAPTCHA SANS SESSION

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

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.

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.


4 commentaires

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


13 Réponses :


1
votes

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?

Certaines techniques assez intéressantes ont vraiment une lecture.


0 commentaires

0
votes

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.

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


1 commentaires

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



0
votes

Sans le côté serveur d'état persistant, je ne vois pas de captcha travaillant.

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.

Pourquoi ne pas faire le CAPTCHA d'un autre serveur Web où vous pouvez avoir un état persistant?


2 commentaires

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.



0
votes

Ma propre idée, je ne sais pas, c'est bien:

1) Si l'utilisateur est enregistré, utilisez simplement une fonction de hachage sur sa connexion et générer CAPTCHA avec elle,

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.

espoir que c'est compréhensible. :)

edit: Sans Ajax: 2 étapes Inscription:

à 1, nous collectons la connexion, etc. Après avoir soumis, nous dirons vers ? Login = new_login

à 2, nous avons une entrée cachée avec Obtenez ["Connexion"] et HASH à partir de celui-ci dans CAPTCHA Image - Après avoir soumis, nous avons tous pour vérifier la réponse.


7 commentaires

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



0
votes

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.


1 commentaires

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.



0
votes

Voici ma prise à elle (Sry si cela semble compliqué):

  1. à la page Demande:

    • Vous générez un code de chaîne aléatoire 'ABCDEF';
    • Vous chiffrez le code en utilisant un mot de passe prédéfini: $ crypt = chiffrer ($ captcha_code, "mot de passe")
    • sous la forme:

      • Un lien d'image est envoyé au navigateur 'CAPTCHA.PHP? $ CRYPT'
      • Une entrée cachée est définie avec la valeur de $ crypt
      • La page CAPTCHA.PHP décrypte le texte crypté et génère l'image.

      • L'utilisateur soumet un formulaire avec le code 'ABCDAA' (et l'entrée cachée $ CRYPT)

      • Le serveur vérifie s'il chiffre ('abcdaa') == $ crypt

        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.


5 commentaires

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.



0
votes

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?

http://www.mythos-rini.com/blog/archives/732


0 commentaires

2
votes

Utilisez le Honeypot technique : Placez un champ de texte avec un nom gourmand, comme« email » , dans un champ caché par CSS (Affichage: Aucun; Visibilité: Cachée;).

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.

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.

ailleurs, comptez sur la Lecture humaine , quelque chose comme "Écrivez la première lettre x x du mot" $ Word "dans le champ:"

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

Je me souviens que un plugin pour le forum PHPBB s'appuie sur le fait que, généralement, les bots spams sélectionnent la première option disponible (avec une valeur) dans le