Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
Ah c'est vraiment un casse tête la sécurisation des session...
Il va de soit qu'il faut essayer de désactivé le magic_quotes, cependant parfois il n'est pas possible de le faire, exemple sur 1and1 php est compilé en CGI et donc on ne peut forcer la configuration du php.ini via un .htaccess.
Ensuite pour gérer les sessions par base de données ce n'est pas un peu gourmand en requête ?
En tous cas je trouve cela sympathique que l'on puisse débattre sur la sécurité sans se "bouffer le nez".
Je ne suis pas convaincu que la gourmandise en ressources soit un réel problème, dans la mesure où :Pour les sessions en BDD, je me permets de rappeler : http://a-pellegrini.developpez.com/t...hp/session-db/
- Les serveurs sont sur dimensionnés
- Les sites ont rarement plusieurs centaines d'accès concurrents, ce qui fait qu'un script s'exécute sans aucun problème
Pour la sécurité des formulaires, il y a du nouveau ici : Hébergez vos projets
Juste une question il y a un groupe dédié à la réflexion de solution pour la sécurité en php dans un premier temps ?
Car pour le moment le forum sécurité php pointe vers le forum Session de php, mais je pense qu'il serait bon de développer un peu plus hors de cet aspect restrictif non ? Certes les sessions sont un nerf de la guerre mais les cookies et autres faille d'upload devraient être mieux expliquer et de façon plus régulière aux débutant.
Une autre faille d'ailleurs qui n'est pas aborder dans ce topic et qui gêne, surement, chacun d'entre nous se sont les injections d'entêtes dans les formulaires d'envoi de mail sur les sites qui conduise aux spams.
Il est une fois encore pourtant simple de ce protéger de cela par une validation rigoureuse des informations communiqué par l'utilisateur.
Cordialement Inazo.
Vu que tu as soulevé un problème, peux-tu donner plus d'explication et la solution.Envoyé par Inazo
Pour ma part :
Ne jamais dire que le formulaire va envoyer un mail.
Ne pas faire d'envoy de mail depuis votre site pour vous même, exemple : contacter l'administrateur. Préférer le faire en deux temps. Formulaire en base de données puis alerte email en arrière plan.
Différer l'envoy de mail en masse si possible. Si vous avez une appli qui envoy des mails faite en sorte que les info soit en pile dans une base. Puis l'envoy se fait en paquet avec tous les contrôles nécessaires. Inconvéniant : Il faut pas être pressé d'attendre les mails.
Les injections d'entete se faisant uniquement sur ces entetes, il est donc indispensable de valider celle que l'on met par exemple avec la fonction mail.
Je pense que beaucoup de site, on ce problème car leurs validation du mail fournis par le formulaire n'est pas assez strict.
Pour ma part je ne met pas de formulaire de contact directement sur mes sites, mais ce n'est pas si compliqué à protéger.
Vous me corrigerais si je me trompe bien entendu. Si vous souhaitez on peut débattre avec des exemples pour ce concerter.
Cordialement Inazo.
En résumant un peu, ces problèmes peuvent être limités par la mise en place d'un CAPTCHA (jeu de chiffres et lettres que les bots peines à lire et que le client doit taper !) dans les formulaires.
Limiter les risques d'injections par un contrôle systématique des saisies en appliquant le principe du "Tout ce qui n'est pas attendu est retourné à l'envoyeur".
Y'a les formulaires qui sont effectivement des nis de spams, mais il y a aussi et surtout des machines zombies (serveurs dédiés, et autres machines hackées).
Le captcha est une solution mais le problème est que ce n'est pas accessible à tout le monde, de plus les OCR, reconnaissance des images, commencent à fleurir sur les bots donc les captchas deviennent obsolète.
A moins d'avoir un captcha comme un certain site d'hébergement de vidéo qui est presque illisible à une personne déjà "bonne voyante".
Donc avec un contrôle systématique des données vous évitez à d'autre spamé par contre se sera vous la personne spamé si vous ne mettez pas en place un captcha ou système similaire.
Cordialement Inazo.
Il y a aussi le systeme d'un dictionnaire de question simple. Par contre il faut pas que la personne devant l'ordi ait le QI d'une poule. Sur le site de 20minutes; pour poser un commentaire il demande la première lettre de l'alphabet ou la deuxieme ou la troisième, pas plus.
De là, il y a des questions qui peut être posé du genre. Quel est la capitale de l'espagne. Qui est le prénom président français. Quel jours nous sommes ect ... Plus le dictionnaire de question réponse et le robot aura moin de chance d'y acceder. Par contre, plus il y a de questions plus le risque q'une personne ne sache pas répondre ne puisse pas accéder mais comme je l'ai dit. C'est des question simple à la porté d'une poule
Ouais c'est une autre solution. Le seul problème, c'est que ça peut faire fuire des visiteurs bêtement...Il y a aussi le systeme d'un dictionnaire de question simple. Par contre il faut pas que la personne devant l'ordi ait le QI d'une poule. Sur le site de 20minutes; pour poser un commentaire il demande la première lettre de l'alphabet ou la deuxieme ou la troisième, pas plus.
De là, il y a des questions qui peut être posé du genre. Quel est la capitale de l'espagne. Qui est le prénom président français. Quel jours nous sommes ect ... Plus le dictionnaire de question réponse et le robot aura moin de chance d'y acceder. Par contre, plus il y a de questions plus le risque q'une personne ne sache pas répondre ne puisse pas accéder mais comme je l'ai dit. C'est des question simple à la porté d'une poule
Pas parceque QI de poule, mais parceque les internautes aiment la rapidité d'accès et n'aiment pas réfléchir "inutile" lorsqu'ils remplissent une formulaire HTML, aussi futile soit la question.
Donc ça peut être la contrainte "de trop", qui fait que l'internaute ferme le navigateur ou l'onglet par reflexe !
Niveau sécurité par contre, c'est sûr, c'est robuste.
C'est robuste mais seulement si les questions ne sont pas automatiques. Il faut un genre de quizz avec une question prise au hasard, mais il ne faut pas construire les questions de manière automatique sous peine d'être exposé à des bots.
Oui biensur, c'est complètement hasardeux les questions. Pas de suite logique, pas qcm. Il est possible de demander à l'internaute de décrire une image mais là c'est plus compliqué car prenons cette exemple.
Indiquez ce que vous voyez au centre de l'image
L'internaute peut dire :
- Une maison
- Un pavillon
Que faire ? Accepter les deux réponses ou prendre que "maison".
C'est aussi une technique efficasse s'il y a beaucoup d'image présentant des objet simple. Un OCR ne peut rien sur ça.
Dans tous les cas, il est inpensable de choisir une solution excluant d'office certains utilisateurs, dans ce cas précis, les personnes aveugles.
Oui, c'est une chose que j'ai oublié. Il y a ceux qui ne veulent pas afficher d'image. De plus, pour les aveugles il impensable de décrire l'image dans le "alt" ou le "title" de l'image
Je pense que l'idée du Quizz n'est pas mauvaise. Seul ombre au tableau : ça va exclure les QI d'huitre
Non, car ils peuvent sans doute s'inscrire en demandant de l'aide, ce qu'un bot ne pourra tout simplement pas faire.
Moi je pense que l'on pas le système dans le bon sens. Je m'explique.
La différence entre un bot et un internaute Lambda, pas trop bête un, c'est que l'on peut comprendre des phrases alors que le bot on ne lui apprend pas la compréhension mais la reconnaissance des phrases.
Donc on le fait en deux temps, premièrement on met un message du genre : "Si vous n'êtes pas un être humain merci de répondre à la question suivante : "
Ensuite on met une question sans image du genre : Combien font deux fois deux ? ou Qui c'est fait viré du gouvernement français car il a pas été élu ?
On met le tout dans une balise "span" avec un style display : none; et visibility : hidden;
Comme cela lorsque des personnes bien voyantes arriverons sur le site pas de soucis tout se passera bien, par contre en cas de bot ou de personne mal voyante ils auronts le texte caché.
Résultat on fait pas fuire la majeur partie de nos visiteurs, on reste accéssible aux mal voyant et on fait fuire les bots.
Cordialement Inazo.
Juste un petit détail de rien du tout : un bot est parfaitement en mesure de repérer les éléments visuels que tu définis en display:hidden... Pour rappel, un bot utilise le code HTML de la page, pas ce que le navigateur affiche.
Justement c'est là la blague le bot répond à toute question si il est éduqué pour cela. Cependant un mal voyant qui lui comprend le français contrairement à un bot, verra qu'il ne faut pas répondre au question, donc en effet le hidden, permet juste de ne pas géré les utilisateurs non handicapé visuellement, et cela permet au personne mal voyante de ne pas répondre au question.
Donc en résumant :
utilisateur Lambda ne voit pas le message donc c'est bon.
Le bot le voit et répond donc il s'est fait piégé.
Le mal voyant le voit mais comprend qu'il ne doit pas répondre donc c'est bon.
Cordialement Inazo.
Et le bot qui ne répond pas à tous les questionnaires ?
Ben là on est bleu ^^ c'est sur...
Mais cela reste bien plus accessible qu'un captcha. Et la majorité des bots répondes car il remplisse tous les champs de formulaire automatiquement. Le but et de ce basé pour l'avenir je pense sur cette différence majeur entre nous et les bots qui pour le moment existe : l'intelligence.
Après mon idée est à compléter il est vrai.
Cordialement Inazo.
L'idée est en effet bonne
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager