Discussion :

[Yogui]

Salut

Non, il t'en manque malheureusement un paquet (sans compter celles que nous ne connaissons pas encore).
Le maître mot est de savoir ce que tu fais. Le problème, avec cette maxime, est qu'elle n'aide pas beaucoup quelqu'un qui débute... Le mieux est de filtrer les données qui entrent dans ton script PHP et de convertir correctement les données en sortie.

http://phpsec.org/

[july]

Merci de ta réponse !
Je me doutais que malheureusement n'inombrables attaques existaient...
Ce que je voulais juste savoir si je me protégeais contre les principales et si de vérifier SCRUPULEUSEMENT les données (ou intéractions) avec l'utilisateur suffisait...
Evidement je ne code pas une banque en ligne ou un truc qui nécesste tant de sécurité...

[Kioob]

Le piratage par "force brute" ou bruteforcing (tester le plus de mdp possible) : résolu avec le codage des mdp avec sha 256, ajout de grain de sel nécessaire ?

non... peu importe le "cryptage", ça ne changera rien du tout. Pour se protèger d'un brute force :
- avoir des mots de passe long/complexes
- forcer un délai minimum de réponse (un sleep() incrémentiel par exemple)
- bloquer l'IP ou le compte après un certain nombre d'erreurs

piratage par écoute du réseau : "man in the middle" : SSL pour seule solution

Pas seulement. SSL est certainement l'idéal, mais en cas d'écoute sur le réseau il y a les problèmes de circulation du mot de passe (là un cryptage Javascript peut être utile), et de vol de session (divers solutions, rien de parfait non plus).

Les "injections SQL" ou XSS (inserer des commandes SQL dans les champs à saisir des formulaires) : résolu grace à des expressions régulières qui autorisent que certains caractères (donc empechent notamment les quotes)

Non, les quotes ou autres caractères ne posent absolument aucun problème à MySQL du moment qu'on utilise mysql_real_escape_string() par exemple. Pas forcément besoin d'expression régulière ici. Des fonctions comme is_numeric() peuvent également vérifier qu'il s'agit bien d'un nombre.

Pour ce qui est des XSS, là il s'agit surtout d'échapper la sortie : htmlspecialchars() suffit par exemple, pour de l'HTML. Mais à chaque format ses spécificités...

[Maxoo]

ça empeche aussi les enregistrement automatique du mot de passe par les navigateurs et à mon avis, c'est plus cet aspect qui compte

ca je suis d'accord, mais bon à chacun de faire ce qu'il veut, si le mec a son papier pour taper son mdp c'est pas plus sécurisé, autant regarder d'un coup d'oeil sur son papier

apres pour le truc avec le digicode, je crois pas que ce soit bon moyen pour aider à la sécurité. Parce qu'il est pas du tout ergonomique.

si on moins on pouvait cliquer dessus, ca irait plus vite et ca serait surement mieux ...

[july]

Merci Kioob,

Alors je récapitule ce que j'ai fait et tu continues à me corriger si je me trompes !

Pour se protéger des insertions SQL, j'ai utilisé htmlspecialchars, addslashes, htmlentities.

J'ai crypté les mdp dans la base de données pour que les mdp 'volé' soient inexploitables.
J'envisage d'ajouter le 'grain de sel' pour éviter de contraindre mes utilisateurs avec des mdp qui ne sont pas des mots et long (parce que je pense qu'ils ne le respecteront pas forcément ) pour se protéger du bruteforcing. En effet, si j'ai bien compris, il faut 2 dictionnaires au pirate (une de mots et un de grain de sel) et le nb de possibilité est décuplé puisqu'il faut qu'il teste TOUS les mots avec TOUS les grains de sel différents.

J'utilise session_regenerate_id() pour changer les sessions pour (si j'ai bien tout lu) que si quelqu'un réussi à voler un numéro de session, il ne pourra pas l'exploiter puisqu'il change régulièrement.

Je possède un formulaire 'posez vos questions' qui génère un mail automatique à l'administrateur du site. Je génère une image différente contenant des lettres et des chiffres que l'utilisateur doit resaisir. Le mail n'est pas généré tant que l'utilisateur ne les saisit pas correctement. Pensez vous que cela me protègera correctement contre l'envoi de mail à répétition par un robot par exemple ?

Enfin, lorsque le nb de tentative de connexion est supérieur à 5 ( ce nb de tentative maximal étant définit par moi ) je bloque l'adresse IP de cette machine et pas la session car cela permettrait de bloquer facilement l'ensemble des sessions.

Juste une dernière question, je trasmet mes formulaires de préférence en POST pour protéger les données. Cependant est-il vrai qu'il est possible de 'voir' les requetes POST comme on voit les requetes GET ? Si oui comment se protéger alors ?

Allez merci pour tout encore et si vous pensez à une autre protection n'hésitez pas !

[Kioob]

Alors je récapitule ce que j'ai fait et tu continues à me corriger si je me trompes !

On va essayer

Pour se protéger des insertions SQL, j'ai utilisé htmlspecialchars, addslashes, htmlentities.

Non. Addslashes protège partiellement des injections SQL : avec MySQL la seule vraie solution est mysql_real_escape_string().

htmlspecialchars() et htmlentities() ne servent absolument à rien pour le SQL : ils "protègent" plutôt contre les XSS ou autre déformation/détournement du HTML, et uniquement du HTML ; absoluement rien d'autre.
Par contre je précise qu'il faut utiliser l'un ou l'autre, selon tes besoins, mais pas les deux : ça fait double emploi.

J'ai crypté les mdp dans la base de données pour que les mdp 'volé' soient inexploitables.
J'envisage d'ajouter le 'grain de sel' pour éviter de contraindre mes utilisateurs avec des mdp qui ne sont pas des mots et long (parce que je pense qu'ils ne le respecteront pas forcément ) pour se protéger du bruteforcing. En effet, si j'ai bien compris, il faut 2 dictionnaires au pirate (une de mots et un de grain de sel) et le nb de possibilité est décuplé puisqu'il faut qu'il teste TOUS les mots avec TOUS les grains de sel différents.

C'est "partiellement" ça

Le "brute force", comme son nom l'indique est une technique de barbares : il s'agit de tester toutes les combinaisons possibles jusqu'à ce qu'on en trouve une qui fonctionne.
Donc, tu pourras crypter avec tous les algos que tu veux, si le mot de passe est "toto" il sera trouvé en quelques minutes.
Et ça peut même être bien pire : dans le cas où le pirate utilise un dictionnaire de mots de passe (cf plus bas), il y a de grandes chances pour qu'il trouve le mot de passe en bien moins de temps que cela.
Pour s'en protéger :
- dans le cas où le pirate a directement accès aux données (cas d'un vol de base de données par exemple), il faut des mots de passe longs et complexes.
- dans le cas où il n'a pas directement accès aux données (un système d'identification par exemple), il faut introduire des sécurités du genre : délai de réponse (positive ou négative) incrémentiel, ou blacklistage de l'IP après un certain de délai, par exemple


Pour le coup du dictionnaire, c'est encore autre chose : sur le net on peut assez facilement télécharger des listes de mots de passe courants... qui vont contenir par exemple les 500'000 mots de passe les plus courament utilisés. Il est alors assez facile de calculer un hash MD5 de tous ces mots de passe, très simple, et plutot rapide, et là : tada ! Tu as une super liste de correspondances MD5 => mot de passe. Bien sûr ça ne marchera pas avec tous les mots de passe, mais ça peut permettre à un pirate de "décrypter" les deux tiers des mots de passe de tes membres, par exemple.
La solution ? Le grain de sel effectivement : en gros c'est un peu comme si tu changeais l'algorithme pour chaque mot de passe. Du coup le pirate serait obligé de recalculer tout son dictionnaire pour chacun des mots de passe de tes membres, bref, ça devient plutôt du brute force via dictionnaire.

J'utilise session_regenerate_id() pour changer les sessions pour (si j'ai bien tout lu) que si quelqu'un réussi à voler un numéro de session, il ne pourra pas l'exploiter puisqu'il change régulièrement.

On en a parlé il y a quelques jours : le session_regenerate_id() peut être pratique à condition de s'assurer de supprimer l'ancienne session. Or ce n'est correctement faisable qu'à partir de PHP 5.1.
Si tu ne supprimes pas l'ancienne session, au contraire, tu ne fais qu'empirer les choses : un utilisateur normal ayant consulté 50 pages aura 50 identifiants de sessions valides... et donc 50 fois plus de chances de se faire voler sa session...


Depuis cette discution, j'ai adopté une autre méthode :
- mon ID de session ne change jamais
- à chaque page j'envois via cookie un second ID, alléatoire. Que j'enregistre également en session.
- à la page suivante je vérifie que l'ID envoyé par l'internaute soit le même que celui en session.

Avantages :
- le délai d'action pour le pirate est fortement réduit, comme avec session_regenerate_id()
- si le pirate arrive toutefois à voler la session, et que l'utilisateur est encore en ligne, à la prochaine page la session sera détruite, donc les deux déconnectés.

Inconvénients :
- s'il s'agissait de la dernière page consultée par l'internaute, ça ne règle aucunement les risques de vol de session. Pour cela il faut les éduquer pour qu'ils cliquent systématiquement sur "se déconnecter" en quittant le site.
- les accès concurrents : ça, ça m'a posé problème... en gros avec ce genre de système on risque de se faire déconnecté à chaque fois qu'on tentera de télécharger deux pages "trop rapidement". Et sur un site un peu lent, c'est très fréquent. Pour palier à ça je maintiens une liste de "vieux" ID, utilisables pendant environ 10 secondes après le changement.

Je possède un formulaire 'posez vos questions' qui génère un mail automatique à l'administrateur du site. Je génère une image différente contenant des lettres et des chiffres que l'utilisateur doit resaisir. Le mail n'est pas généré tant que l'utilisateur ne les saisit pas correctement. Pensez vous que cela me protègera correctement contre l'envoi de mail à répétition par un robot par exemple ?

Non, il a déjà été démontré qu'un script peut très bien retrouver les codes se cachant derrière ces images.
Généralement les spammeurs passeront leur chemin... mais ça n'empèche pas que si quelqu'un veut réèllement te nuire, il pourra.

Là pour se protèger, vérifier que les champs "sujet" ou "adresse d'expéditeur" ne contiennent pas de caractères éxotiques comme les retours à la ligne par exemple. (ça permettrait d'ajouter/modifier des entêtes dans l'envoi de mail, et donc de spammer à tes dépends)

Enfin, lorsque le nb de tentative de connexion est supérieur à 5 ( ce nb de tentative maximal étant définit par moi ) je bloque l'adresse IP de cette machine et pas la session car cela permettrait de bloquer facilement l'ensemble des sessions.

Oui et non : cela va te protèger des brutes forces effectivement. Mais d'un autre coté, je prends mon compte AOL, je fais volontairement (ou non) 5 erreurs d'identification, et paf : tous les abonnés AOL sont bannis du site, bien joué.
Ouep, c'est le problème des proxy et routeurs qu'on retrouve également dans les universités, les entreprises, etc.

Juste une dernière question, je trasmet mes formulaires de préférence en POST pour protéger les données. Cependant est-il vrai qu'il est possible de 'voir' les requetes POST comme on voit les requetes GET ? Si oui comment se protéger alors ?

Oui, les données POST circulent en clair sur le réseau tout comme les paramêtres GET ou les cookies. Pour s'en protèger, une seule vraie solution : SSL.

[july]

Merci encore de m'aider (surtout à comprendre ! )

Mais là tu commences à me démoraliser...
J'ai l'impression qu'aucune technique de protection n'est vraiment efficace et que toutes les 'parades' peuvent etre détournées !

En tout cas merci encore, je vais mettre en place tout ce que tu m'as conseillé !

D'ailleurs, toi utilises tu d'autres protections ? Et comment font les 'grands' site (ebay, fnac...) pour se protéger efficacement (à part SSL)?

[Kioob]

Aucune technique n'est inviolable effectivement, l'idéal est de "tout" protèger...

- ne jamais faire confiance à ce que l'utilisateur envoi
- toujours "échapper" les variables selon la destination : mysql_real_escape_string() pour MySQL, htmlspecialchars() pour du HTML, urlencode() pour des URL, expressions régulières pour les mails, etc.
- se protèger des vols de session
- forcer des mots de passe d'au moins 8 caractères
- toujours "crypter" les mots de passe avec un grain de sel
- SSL pour les transferts
etc

Sans oublier la sécurité du serveur, de la salle, du batiment, etc.


Aucune de ces méthodes n'est parfaite, le tout serait plutot de toutes les utiliser "où il faut quand il faut"...

[july]

Bon je voudrai juste préciser que je travaille sur un intranet donc les administrateurs réseaux (donc pas moi ) s'occupent ne le rendre accessible qu'aux machines de l'entreprise avec la liste des adresses IP. Donc pas de problème de blocage de TOUS les abonnés AOL (mais c'est bon à savoir pour l'avenir ) et justement si quelqu'un c'est introduit je préfère bloquer son IP comme ça je me protège aussi des autres intrusions depuis AOL.

Par contre je crois qu'il est possible de se faire pirater son adresse IP et c'est LA que mes protections entrent en jeux ! :
- stockage dans la BDD des mdp en crypté (contre le vol de bdd) ET avec un grain de sel

- la saisie des caractères d’une image pour éviter l’envoi de spam
- bloquer l’accès aux pages des IP ayant tenté de se connecter trop de fois (>5)
- obliger l’utilisateur a saisir un mdp de taille > 8 caractères
- protection contre le vol de session (avec la méthode décrite par Kioob)
- mysql_real_escape_string() pour MySQL, et expressions régulières pour la validité des adresses mail



Voila, avec cette information supplémentaire mes protections vous semblent-elles suffisantes ?

[Kioob]

Pour un intranet, c'est clair que c'est déjà très bien : souvent la sécurité en interne est négligée.

Par contre, dans beaucoup d'entreprises le réseau local est encore constitué de hub, et non de switchs. Du coup n'importe quel bidouilleur est capable de sniffer le réseau, et donc de chopper les mots de passe qui circulent par exemple.

M'enfin... de toutes façons dans ce cas, le gars a déjà certainement accès à la boite mail de son chef, a ses identifiants pour le proxy donnant sur le net, et ses identifiants pour les autres applications internes

[july]

Merci beaucoup pour tout et surtout du temps passé.

Je vais donc arreter la pour mes protections, je retourne au codage des pages !!

C'est sur qu'un 'vrai' pirate qui a un but précis réussira certainement TOUTES les informations qu'il souhaite !

N'oublions pas également le mot de passe noté sur un post-it sur l'écran, le bureau ouvert avec la session de l'ordinateur non vérouillée...

Merci encore !

[tuttle]

Bonjour,

Je ne découvre qu'aujourd'hui ce Post (Merci au passage à Maxoo) mais il y a quelque chose qui me gène dans le Grain de Sel.

La solution de Spip a effectivement le problème mentionné par Maxoo mais la solution donnée me parait ne pas résoudre le point suivant :

Si j'ai bien compris, on envoie ce qui sera directement vérifié. Du coup quelqu'un qui a accès à la base peut se connecter sur n'importe quel compte.

Je m'explique avec l'exemple de Maxoo (mon idole décidemment aujourd'hui) :
Le client envoie md5(GDS+md5(mdp))
Le serveur ayant a sa disposition GDS (il vient de l'envoyer) et md5(mdp) (dans la base) il peut comparer.
Mais le type qui a accès à la base a lui aussi le GDS et md5(mdp), il suffit donc qu'il envoie le tout hashé en md5 et il n'a même pas besoin du vrai mot de passe...

Il faudrait qu'il y ait un hashage supplémentaire coté serveur... Mais là ca fait beaucoup pour aujourd'hui, mon cerveau ne suit plus...

[wamania]

Salut

Le GDS n'est pas fait pour protéger le compte d'un "man in the middle", il est fait pour protéger l'intégrité du mot de passe.
Le hacker pourra effectivement toujours prendre la place d'un membre, mais ne connaîtra pas son mot de passe, comme en général, les mots de passe sont communs pour plusieurs site/mail.. pour un membre.
Il protège aussi des attaques par dictionnaire.

[tuttle]

Ok, je pensais que md5 suffisait pour empécher de connaitre le mot de passe réel mais il y a les problèmes des dictionnaires si j'ai bien compris.

Et (mea culpa) ma remarque a déjà été postée sur http://www.developpez.net/forums/showthread.php?t=98673

Merci !

[Maxoo]

juste : tu parles d'une personne qui a accès à la BDD, mais dans ce cas tu es mal barré car si quelqu'un a accès à la BDD il est dans le système et c'est foutu ...

Maxoo (mon idole décidemment aujourd'hui)

juste pour un post ?

[Kioob]

Maxoo : il peut s'agir d'une simple "petite" faille qui donne un accès en lecture à une seule table dans la base de données... et qui pourrait alors prendre des proportions bien plus grave si les mots de passes deviennent "exploitables".

[Maxoo]

Maxoo : il peut s'agir d'une simple "petite" faille qui donne un accès en lecture à une seule table dans la base de données... et qui pourrait alors prendre des proportions bien plus grave si les mots de passes deviennent "exploitables".

mais les mdp sont toujours exploitables !!
quoi que tu fasses dans la BDD tu as tout pour reconnaitre l'utilisateur !!
donc voila.

[Kioob]

gna ? on doit pas parler de la même chose.

Si le mot de passe est "crypté" à l'aide d'un salt, ça devient quand même difficile pour le pirate de récupèrer le mot de passe de départ... et cela reste une des informations les plus importantes de la plupart des bases de données (associé à l'email de la personne, évidement).

[berceker united]

salut,

je viens rajouter mon grain de sel, car effectivement j'ai trouvé une faille dans celui-ci.

Je ne sais pas si SPIP utilise toujours ce que Mathieu a expliqué pour leur systeme de login, mais je pense avoir trouver une grosse faille.


Disons que l'utilisateur se loggue :
il entre son mdp et avec javascript il envoie au serveur md5(GDS+mdp) et md5(GDS2+mdp), le serveur dis oki ca correspond avec ce que j'ai, il remplace son md5 par md5(GDS2+mdp) remplace son GDS par GDS2 et recréé un nouveau GDS2.

Jusque la tout le monde est d'accord. mais en fait y avait un petit malin qui écoutait entre le pc et le serveur.

Je rappelle que dans ce cas on essayait de trouver un moyen pour ne pas utiliser un protocole SSL (https)

Donc le hacker a ecouter md5(GDS+mdp) et md5(GDS2+mdp) or voila le premier ne lui sert a rien on est bien d'accord, mais le deuxieme ... BAh c'est EXACTEMENT le md5 que le serveur attend pour la prochaine connexion !!! Y a comme un probleme ici.

Donc apres le hacker se connecte avec le md5(GDS2+mdp) en l'envoyant au serveur et en donnant un autre md5 (celui qu'il veut) et ainsi il prend la place de l'internaute sans aucune difficulté !!

Qu'en dites vous ??



Heureusement (il y a findus) j'ai une solution.

• Sur le serveur :
  1. Grain de Sel (GDS)
  2. le md5(mdp)
  
• Coté client :
  1. le mec demande a se connecter avec son login
  2. il a une demande de mdp, dans ce formulaire, il y a le GDS de son login
  3. le javascript (ou autre) fait un (suivez bien) md5(GDS+md5(mdp)) Ce qui fait que quelque chose d'inutile est envoyé en clair au serveur.
  4. le serveur recoit ce md5, fait (lui meme, donc en php) md5(Grain de sel de la BDD + md5(mdp) de la BDD) et compare ces deux md5.
  5. le GDS est changé.

• Avantages :
  - le md5 que le hacker peut chopper en clair ne sert qu'une seule foi et du coup c'est déja trop tard le GDS a été changé
  - l'utilisateur est content
  - pas besoin de SSL (la j'abuse je pense mais bon ...)
  
  Inconvenients :
  - besoin de deux formulaires

vous allez me dire que le md5(du mdp) est stocké comme ca sur la BDD, mais c'est le cas sur la plupart des appli non ??

Pour eviter les deux formulaires il est possible de le faire en AJAX. En fait les deux formulaires sont traité en deux temps mais c'est transparent pour le client .

[Maxoo]

Kioob >> effectivement on parle pas de la même chose, toi si j'ai bien compris tu parles de récupérer le mdp ?

moi je parle juste d'avoir acces au compte, car même si on ne récupere pas le mdp, mais qu'on a le mdp+salt avec autant de md5, si on a ce que le serveur a besoin pour reconnaitre le user, on peut se faire passer pour lui en envoyer ces informations au serveur.