Il y a quelque mois j'étais tombé sur une belle faille de sécurité : un site qui donnait un accès libre à des données bien sensibles. Alors je précise vu que le net est plein de gens qui ne savent pas lire, cette faille que j'ai trouvé, n'a rien à voir avec le sujet que nous allons aborder ici, c'est histoire quelque chose de faire une introduction... Bref, flairant le coup casse gueule, j'avais transmis l'information à un spécialiste du genre, Damien Bancal, du site zataz.com.

Il y a quelques temps, j'ai reçu sur mon adresse personnelle (et ultra-secrète), l'invitation d'une amie pour un "réseau social" (un machin pour vous remettre avec d'anciennes relations en contact...) dont je tairais le nom plus par manque d'intérêt que par peur de poursuites.

Après petite enquête, j'ai appris que cette amie s'était juste inscrite pour tester et n'avais jamais, par manque de temps, donné suite. Cependant, comme pas mal d'autres services (à la con) du même genre, ce site ne devait prendre toute sa puissance qu'après avoir fournit soit le mot de passe d'un compte WebMail (Yahho, GMail, AOL, etc..), soit avoir copié directement, et à la main, les précieuses adresses dans la zone prévue à cet effet. La justification de cette requête assez étrange est de permettre au site de retrouver les personnes déjà inscrites ou d'envoyer facilement, si vous le désirez, des demandes de mise en relation à celles qui ne le sont pas.

Résultat des courses, et sans que cette amie n'est faite la moindre demande de mise en relation, le site s'est permis d'envoyer des invitation à tous ses contacts, et comme par hasard, je commence à recevoir de SPAM (sex & co) sur mon adresse personnelle ultra-sécrète.

La suite ici...

Pour sécuriser une connection à un serveur web (https), un serveur imap (imaps) ou tout autre client utilisant SSL ou TLS, nous avons besoin d'un certificat. Dans une première approche il est possible d'utiliser des certificat dits "auto-signés". Générés très facilement, il sont très pratique pour développer et tester un site sécurisé mais beaucoup moins s'agissant d'une utilisation régulière et publique, principalement à cause des avertissements de sécurité qu'ils génèrent sur l'application cliente. L'autre option est alors d'acheter un certificat auprès d'un tiers de confiance. Certificat qui vous permettra à votre tour d'en générer d'autres qui cette fois seront acceptés sans erreur.

La troisième voie développée ici, entre l'auto-signature et l'achat, consiste à créer sa propre autorité certifiante qui, une fois importée, par exemple dans un navigateur, se comportera exactement de la même manière que si vous l'aviez achetée. Au delà de la compréhension technique des mécanismes mis en jeu, cette approche est plutôt bien adaptée à une petite structure qui n'a pas le goût de payer un certificat et pour qui distribuer ou pré-installer une autorité ne pose pas de problèmes (nombre restreint d'utilisateurs, postes pré-installés, etc.).

Bon, j'ai craqué, le serveur LDAP est parti en vrille une fois de trop et vient de partir à poubelle. Je ne remet en cause l'intérêt de cette base de donnée mais pour gérer une poignée d'utilisateur les inconvénients pour un "non-administrateur système" étaient largement au dessus de l'intérêt. Ce fût instructif comme dirat Dab.

Retour donc à la simplicité avec une base utilisateur UNIX, éventuellement NIS et encore PAM pour abstraire un peu tout cela, cette fois pour Apache.

Quelques failles ont été trouvées sur la 5.3 de drupal donnant lieu à une mise à jour corrective. Pour faire cela rapidement, vous pouvez vous aider de ce tutorial.