salut,

comme je suis en train de travailler sur un site commercial j'essai de vérouiller le maximum de tentatives de hack via injection sql ou autres au niveau du login.

pour l'injection sql j'ai pensé à n'autoriser que les caractères alphanumériques et une longueur maximal de 10 pour le login et 6 pour le mot de passe.

après j'ai entendu parlé de logiciels de crackage de mot de passe qui testent toutes les possibilités(du style brutus pour ceux qui connaissent).
j'ai pensé à faire une redirection au bout de trois tentatives infructueuses pour contrer ce type de logiciel, mais ne connaissant pas exactement leur mode de fonctionnement je me demande si ça suffira.

donc je post ici pour savoir si quelqu'un connait le fonctionnement de ce type de logiciel, et si ce que j'ai pensé faire pour les injections et les logiciels de crack tient la route ou ne sert à rien.

Salut,
pour les protections contre les injections SQL, tu as sur la page d'accueil de PHPFrance un lien vers un tuto sur les magic_quotes qui devrait t'aider pas mal.

Pour ce qui est de limiter le tentatives de crack de mots de passe, il y a plusieurs choses :
- D'abord des conseils de prudence basique: ne jamais utiliser en mot de passe des mots qu'on peut retrouver dans un dictionnaire, il faut donc préférer des suites aléatoires de caractères alphanumériques; un minimum de 6 caractères semble une bonne chose, on peut pousser le maximum à 12 voire plus, mais il deviendrait difficile à l'internaute de s'en souvenir correctement.
- pour limiter les tentatives au delà de trois essais par exemple, récupérer au moment de l'identification l'IP de l'internaute et quelques variables d'environnement, et initialiser un pointeur à 1 puis l'incrémenter à chaque nouvelle tentative. Enregistrer chaque tentative avec la date et l'heure de l'opération en base de données. Établir un délai maximum après trois tentatives en cas d'échec et bloquer l'accès au formulaire pendant un délai déterminé.
- Enfin pour le formulaire d'identification, ne JAMAIS utiliser la méthode GET ni récupérer les valeurs dans $_REQUEST : méthod post et récupération dans $_POST seulement.

je suis d'accord avec toi sur les principes.

sinon j'ai pensé à n'autoriser que les caractères alphanumériques(en testant la valeur ascii à défaut d'avoir trouver une fonction php) pour justement éviter d'avoir à utiliser les magic_quote ou autres fonctions d'échappement, ainsi qu'à interdire les caractères de commentaires sql, signes d'égalité...
pour ce qui est de la longueur maximal c'est pour éviter les instructions sql(ouvert à toutes critiques constructives sur ces deux points).

après est-ce que tu es sûr qu'une simple redirection suffit à contrer un logiciel de crack(j'imagine que oui mais je ne sais pas du tout comment ils fonctionnent alors je ne suis pas rassuré).

thierry

Pour éviter les injections SQL, il suffit d'échapper les chaines saisies par les utilisateurs. Ca permettrait en plus de pouvoir mettre des caractères spéciaux dans les mots de passe, ce qui est un bon moyen pour éviter le brute force. Et puis, comme te disait Cyrano, ty peux compter le nombre de tentatives infructeuses, et bloquer ou bout de 3 ou 5. Ca devrait sécuriser pas mal tes pages.

sinon j'ai pensé à n'autoriser que les caractères alphanumériques(en testant la valeur ascii à défaut d'avoir trouver une fonction php)

Tu as les expressions régulières qui font ça très bien. Il y a un autre tuto très complet de Ripat au même endroit que l'autre.

Tu as les expressions régulières qui font ça très bien. Il y a un autre tuto très complet de Ripat au même endroit que l'autre.

c'est vrai qu'il faut que je m'y mette(toujours pas eu à les utilisé, mais je vais jeté un coup d'oeuil voir si ça peut me simplifier la vie sur ce coup là).

Pour éviter les injections SQL, il suffit d'échapper les chaines saisies par les utilisateurs

d'accord mais de quel façon?
je m'explique:
j'ai testé le magic_quote_gpc à on et mysql_escape_string(avec le magic... à off).

outre le fait que je n'aime pas que l'on échappe pour moi et le magic.. encore moin(le magic... supprime carrément les '<' par exemple) j'y voit un gros problème de sécu.
aucun des deux ne gère les commentaires sql('#' et '/*'), pour ce qui est du mysql_esc.. je trouve ça vraiment abusé.

un ptit exemple:

$reket="select * from toto where tutu=$var or tata='titi'";

si $var provient d'un formulaire est qu'il est de la forme 'toto#' ou 'toto/*' voila ce qui sera éxécuté: voila pourquoi je pourquoi, et j'usqu'à preuve du contraire, je préfère autoriser les caractères alphanumériques et rien d'autre.
faites gaffe aux magic_quotes

sinon toujours à la recherche du fonctionnement d'un logiciel de crack et savoir si une redirection suffit.

j'ai donné un mauvais exmple.
aucun des caractères d'échappement ne gère les commentaires mais pour les chaînes protégés par des ' il n'y a pas de problème.
le problème n'intervient que pour les valeurs numériques.
et même si pour un login ce n'est pas le cas, je n'aime pas laisser cette possibilité.

en fait j'ai mal lu vos réponses et j'étais resté sur l'idée d'une redirection alors que vous me parliez de bloquer le compte.

entre temps j'ai tester un logiciel de crack et c'est clair qu'une redirection sert à rien du tout.

pour l'instant je pense à stocker une variable temporelle de l'ordre de la milliseconde hisoire de savoir si c'est un humain ou un robot qui fait les tentatives(je commence à être fatigué et c'est une des premières idées qui m'est passé par la tête).

donc si vous avez une meilleur idée...

pour l'instant je pense à stocker une variable temporelle de l'ordre de la milliseconde hisoire de savoir si c'est un humain ou un robot qui fait les tentatives(je commence à être fatigué et c'est une des premières idées qui m'est passé par la tête).

C'est une très bonne idée, les protections de type anti-flood sont souvent mises en place et c'est efficace. Imagine un brute-force s'il doit s'écouler 5 secondes entre chaque tentative ! il aurait besoin de milliers d'années pour cracker le mot de passe

histoire de savoir si j'ai bien compris:

.je garde l'idée d'une variable temporelle pour savoir qui fait les tentatives.
.au bout de n tentatives je bloque le compte pendant une durée déterminé.
.le fait de bloquer le compte pour une durée déterminé empêche le crackage du compte à cause d'un problème de temps, et évite à l'admin du site de le débloquer manuellement.
.je garde l'idée de ce système pour tout ce qui permet à un internaute d'envoyer des commentaires sur le site.

c'est ça?

Quelque chose dans ce goût-là oui. j'ajouterais même autre chose.

Lorsqu'un internaute ouvre un compte, tu pourrais mettre en place un système avec image de caractères déformés un peu comme on voit sur certains sites: ces caractères ne peuvent pas être lus par un robot puisque c'est une image, les lettres déformées pour empécher la reconnaissance par des robots qui pourraient comporter un programme de reconnaissance de caractères OCR, et donc leur interdit toute inscription automatique. Ajoute à ça l'envoi d'un courriel comprenant une url variable de validation/confirmation et à mon avis ton site devrait être relativement bien protégé.

Enfin, dernière option, mais coûteuse, la partie identification via une page https (sécurisée).

Enfin, dernière option, mais coûteuse, la partie identification via une page https (sécurisée).

exact, j'ai soulevé le problème du sniffage et j'attends de voir ce que décidera le client.

par contre bien vue l'histoire des lettres déformés j'avais pas du tout pensé au système ocr(en plus ça m'évitera de trop râler contre les images avec des lettres incompréhensibles).

sinon merci pour les réponses ça m'a bien aidé à réfléchir sur le sujet et à trouver des solutions, et même si je suis conscient qu'un système ne sera jamais fiable à 100% je reste preneur de tout autre proposition.

...et puis maintenant je peux commencer à coder le système de sécu

une petite précision sur les logiciels de crack pour que ceux qui n'en ont pas un sous la main évitent de se faire avoir.

un moyen de régler ce type de logiciel est de lui dire:
si la réponse à l'essai est différente d'un mauvais login, alors c'est que c'est le bon.

imaginons maintenant trois choses:
.le logiciel est sur un login qui existe et passe en revu les différents mdp.
.une fois le compte bloqué on pense à avertir l'utilisateur légitime, au cas où il viendrais se loguer, que son compte est bloqué(donc lorsque login et mot de passe sont bon).
.bloqué ou pas bloqué on garde la même réaction lorsque le mot de passe est mauvais.

donc lorsque le bon login/mdp sera trouvé par le logiciel, il interprétera l'avertissement du compte bloqué comme ayant trouvé le bon login/mdp...et il aura raison.

après à chacun de voir comment éviter ce piège

Une autre méthode :
- À chaque tentative si le compte n'existe pas, ou si le mot de passe est mauvais, on a le même message d'identification incorrecte.
- Au bout de 3 essais infructueux en moins de 5 minutes sur un compte existant, le compte est bloqué et un mail indiquant les instructions de déblocage est envoyé à l'utilisateur légitime.
- Tant que le compte est bloqué, toute tentative de login se solde par un message d'identification incorrecte.

Le message d'identification incorrecte est un message généraliste indiquant que "le compte est inexistant ou bloqué, ou bien le mot de passe est incorrect", accompagné bien sûr d'explications dans les différents cas (vérifiez votre boite mail, vérifiez le caps-lock, etc...).

On ne donne ainsi jamais aucune information quant à savoir si le login existe ou non, et surtout on ne différencie pas un compte bloqué d'un compte inexistant.

dans une méthode que j'envisageais je pesais le pour et le contre vis à vis de donner ou pas le login.
je me disais qu'après tout vu qu'il y avait un algo pour bloquer le compte c'était pas trop important même si par principe ça ne plaisait pas beaucoup.

finalement j'ai explorer deux autres pistes.

la première serait d'utiliser une image anti spam, mais ça obligerait l'utilisateur à remplir 3 champs au lieu de deux.

la deuxième est lié au fonctionnement du logiciel de crack.
ce type de logiciel nécessite de connaître le nom des champs login et mdp.

le truc est de générer dynamiquement un champs login(ou mdp) avec un nom aléatoire(rand(456,7896) marche très bien) et stocker ce nom dans un fichier placé dans un répertoire protégé.
il suffit ensuite de récupérer le nom générer et de tester si $_POST['nom_généré'] existe bien pour continuer le traitement.

pour l'instant ça pertube bien le robot, donc reste à savoir s'il n'y a pas de faille dans ce système.
en tout cas s'il n'y a pas de faille, plus de bloquage de compte, et cette idée me plairait bien.