Discussion :

[berceker united]

Lorsque c'est un extranet ça peut être intéressant. Poser des questions que seul les personnes en internes savent répondre. Genre : Combien gagne votre patron .
Non plus sérieusement. Plus les questions peut être ciblé mieux ça sera contre les bots. Par contre, il est nécessaire d'avoir un personne pouvant mettre en place les questions et de sécurisé la réponse parce que s'ils arrive à hacker le serveur et récupère la liste des questions et réponse. C'est la "Bamboula Party". Un petit MD5 sur la réponse et hop

[Yogui]

L'inconvénient des questions ciblées est qu'elles excluent les invités. Par exemple un client en visite, etc.

[berceker united]

L'inconvénient des questions ciblées est qu'elles excluent les invités. Par exemple un client en visite, etc.

Plus simplement, toute personne venant d'arriver.

[Fladnag]

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

J'utilise exactement le meme genre de chose sur mon site ! (copieur ! non ? bon, on va dire que les grands esprits se rencontrent ;o)

a ceci pres que :

* Les styles ne sont pas directement dans le code html, mais deportés dans des feuilles de styles (plus dur a parser pour les bots)
* Si on considere le javascript toujours activé on peut meme faire un display:none par javascript... et là, on a 1000 maniere d'écrire ca en js, donc un bot ne pourras jamais le contourner a moins de l'interpreter, puis d'utiliser une exploration DOM a la maniere de firefox, mais ca demande deja un sacré moteur !!
* Tout les champs de mon formulaire ont des petits noms sympatiques générées aléatoirement a partir d'un md5
* J'ai mis plusieurs input "piégés" pour un input affiché... la probabilité qu'un bot ne remplissant pas tout les input ne remplisse que le bon est assez faible !

Pour générer automatiquement les noms des champs en md5, j'utilise une formule perso (basée sur le temps, l'adresse ip, et tout autre champs souhaité) pour generer une "clé" que je passe aussi en champ hidden. C'est a partir de cette clé que je genere les noms de mes champs md5 a l'aide d'une autre formule perso qui cette fois ci ne contient pas d'element aléatoire. Ainsi, lorsque je recois mes champs en POST, je récupere la clé dans le hidden, je recalcule les noms "cryptés" de mes "vrais" champs a partir de la clé et je peux associer a chaque champ sa valeur... ca a l'air compliqué comme ca, mais il est facile de faire une fonction/methode/classe dédiée qui rend tout ca transparent pour le developpeur...

A noter qu'aucun robot n'est parvenu a casser ce systeme encore... j'ai pas fait de stats par jour ou par mois (je devrais, je log juste toutes les tentatives ;o), mais j'en ai bloqué automatiquement 21 pour la journée de hier par exemple ;o)

[Asmodean]

J'ai rencontré une faille, qui n'en ai pas vraiment une puisqu'elle fait parti du fonctionnement par défaut de ph. Cependant il faut la connaître parce que ca peut poser des problèmes dans certains cas.

Je pensais, à tort, que le php, lorsque le client fermait le navigateur ou appuyait sur stop, continuait le script jusqu'à la fin. Or la directive ignore_user_abort est par défaut désactiver.

Bien sur ça ne concerne que les scripts plutot volumineux. Quoique de manière intentionnelle à l'aide d'un bot on puisse arrêter l'éxécution très tôt.

Plusieur solution : changer la directive, utiliser register_function_shutdown, ou encore utiliser une db transactionnelle. En tout cas c'est toujours bon de l'avoir à l'esprit parce que ça pourrait jouer des tours.

http://www.php.net/manual/fr/feature...n-handling.php

[berceker united]

J'ai rencontré une faille, qui n'en ai pas vraiment une puisqu'elle fait parti du fonctionnement par défaut de ph. Cependant il faut la connaître parce que ca peut poser des problèmes dans certains cas.

Je pensais, à tort, que le php, lorsque le client fermait le navigateur ou appuyait sur stop, continuait le script jusqu'à la fin. Or la directive ignore_user_abort est par défaut désactiver.

Bien sur ça ne concerne que les scripts plutot volumineux. Quoique de manière intentionnelle à l'aide d'un bot on puisse arrêter l'éxécution très tôt.

Plusieur solution : changer la directive, utiliser register_function_shutdown, ou encore utiliser une db transactionnelle. En tout cas c'est toujours bon de l'avoir à l'esprit parce que ça pourrait jouer des tours.

http://www.php.net/manual/fr/feature...n-handling.php

C'est vrai nous y pensons pas souvent. Il suffit qu'un script assez pas forcement long mais qui des que l'utilisateur fait stop ou ferme le navigateur fait que le script n'est pas terminé est s'arrête en plein processus ce qui fait que le site peut completement bugué. Problème c'est que si le script ne s'arrête jamais parce qu'il y a un os vous pouvez mettre à genoux un serveur. Il faut être sur de son coup. Etre sur d'avoir un script qui marche au poil de c*l pret. Au pire de ne pas le mettre partout seulement dans les opérations critiques.
Asmodean, t'as déterré un bon lièvre

[Fladnag]

oui, j'ai deja "detecté" ce "bug" lors d'un simple script du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
$nb=trim(@file_get_contents('compteur.txt'));
if (!isset($nb) || !is_numeric($nb)) $nb=0;
$nb++;
$f=@fopen('compteur.txt', 'w');
fputs($f, $nb);
fclose($f);

Etrangement, de temps en temps, le compteur était remis a zero tout seul. Il suffit de faire quelques tests en faisant une page avec 1000 iframes qui appellent une page avec ce script. La parallelisation fera que certaines iframe ne se chargeront pas completement (ou bien faire un sleep(25) juste apres le fopen et fermer la page)
Le fopen recréant un nouveau fichier vide, la valeur précédente du compteur est perdue si le fichier n'est pas recréé...
Conclusion : il faut assurer l'integrité des données a toutes les etapes (= entre chaque ligne) de son code !
(gerer un fichier backup, faire un append au lieu d'un w, ou faire un rw avec un fseek suivi d'un trunc, etc...)

[Invité]

C'est vrai nous y pensons pas souvent. Il suffit qu'un script assez pas forcement long mais qui des que l'utilisateur fait stop ou ferme le navigateur fait que le script n'est pas terminé est s'arrête en plein processus ce qui fait que le site peut completement bugué. Problème c'est que si le script ne s'arrête jamais parce qu'il y a un os vous pouvez mettre à genoux un serveur. Il faut être sur de son coup. Etre sur d'avoir un script qui marche au poil de c*l pret. Au pire de ne pas le mettre partout seulement dans les opérations critiques.
Asmodean, t'as déterré un bon lièvres

En faite, cette problématique va bien au-delà de PHP, elle nous mène aux propriétés ACID .

Un exemple d'application ACID : les transactions MySQL (InnoDB); elles confinent les données durant l'exécution des instructions et restaure leur état initial en cas de souci !

Dans le cas de PHP, il y a pas seulement l'abandon coté client qui doit être pris en compte, mais le timeout des scripts coté serveur.

Dans les opérations d'écrirure de fichiers ou de génération de ressources en tout genre c'est effectivement un problème de sécurité...Mais je pense pas que ça puisse se constituer en faille critique.

Heureusement ce genre de script est assez peu fréquent.

[Yogui]

C'est un autre exemple qui démontre que l'utilisation d'une base de données, bien que lourde dans certaines circonstances, permet d'instaurer facilement divers mécanismes de sécurité bien pratiques.

[Sayrus]

Hello,

Je tourne en rond depuis une heure maintenant...

Je ne reviens plus sur comment on appelle des scripts qui testent les failles de sécurité de sites web?

Auriez-vous plusieurs scripts en JS ou autre à me suggérer pour tester les failles de sécurités les plus connues?

Je sais que ça existe mais je tourne en rond

Merci.

[Fladnag]

Un etre humain ?

[Sayrus]

Non en plus de l'être humain qui a au préalable passé en revue les eventuelles failles de sécurités, il existe des programmes, scripts ou autre qui testent tout ça...

[Yogui]

Salut

Ne s'agit-il pas d'un programme de fuzz ?

[kaymak]

Pas nécessairement le fuzzing en soit consiste à envoyer des valeurs volontairmeent érronées et aléatoires sur un point d'entrée de l'appli jusqu'à ce que celle ci revele une faille, ou que l'on abandonne.

Ce qu'il faut surtout c'est un logiciel pour détecter automatiquement les points d'entrées, et après soit on teste le point d'entrée par fuzzing, soit avec des attaques connues. Ou les deux.

Maintenant c'est clairement un bon point de départ pour trouver ce genre d'appli sur le net.

[Sayrus]

Hello,

Merci pour vos réponses c'est exactement ça que je cherchais