Sécurité

L’approche d’Elgg pour les diverses questions de sécurité est commune à toutes les applications web.

Astuce

Pour signaler une vulnérabilité potentielle dans Elgg, envoyez un email à security@elgg.org.

Mots de passe

Validation du mot de passe

La seule restriction qu’Elgg impose sur le mot de passe est qu’il doit comporter au moins 6 caractères par défaut, quoique ceci puisse être changé dans /elgg-config/settings.php. Des critères additionnels peuvent être ajoutés en enregistrant un plugin hook pour registeruser:validate:password.

Hachage du mot de passe

Les mots de passe ne sont jamais stockés, seulement les hachages salés produits avec bcrypt. Cela se fait par l’intermédiaire de la fonction standard password_hash(). Sur les anciens systèmes, le polyfill password-compat est utilisé, mais l’algorithme est identique.

Les installations Elgg créées avant la version peuvent avoir des chaînes de hachage de mot de passe « historiques » résiduelles créées en utilisant MD5 avec sel. Elles ont été migrées vers bcrypt lorsque les utilisateurs se connectent, et seront totalement retirées lorsque le système est mis à niveau vers Elgg 3.0. Dans le même temps, nous sommes heureux d’assister les propriétaires de sites à retirer manuellement ces chaînes de hachage historique, même si cela force ces utilisateurs à réinitialiser leur mot de passe.

Mitigation du mot de passe

Elgg a un mécanisme de mitigation des mots de passe qui rend les attaques par dictionnaire depuis l’extérieur très difficiles. Un utilisateur n’est autorisé qu’à 5 tentatives de connexion par période de 5 minutes.

Réinitialisation du mot de passe

Si un utilisateur oublie son mot de passe, la génération d’un nouveau mot de passe aléatoire peut être demandée. Après la demande, un email est envoyé avec une URL unique. Quand l’utilisateur visite cette URL, un nouveau mot de passe est envoyé par email à l’utilisateur.

Sessions

Elgg utilise la gestion des session PHP avec des gestionnaires personnalisés. Les données de sessions sont stockées dans la base de données. Le cookie de session contient l’id de session qui lie l’utilisateur au navigateur. Les métadonnées de l’utilisateur sont conservées dans la session, notamment le GUID, le nom d’utilisateur et l’adresse email.

Fixation de session

Elgg protège contre la fixation de session en régénérant l’id de session lorsqu’un utilisateur se déconnecte.

Détournement de session

Avertissement

Cette section est discutable.

En plus de se protéger contre les attaques de fixation de session, Elgg a également une autre vérification pour essayer de vaincre le détournement de session si l’identifiant de session est compromis. Elgg stocke un hachage de l’agent utilisateur du navigateur et un secret de site comme une empreinte digitale de session. L’utilisation du secret du site est plutôt superflue, mais la vérification de l’agent utilisateur pourrait empêcher certaines tentatives de détournement de session.

Cookie « Se souvenir de moi »

Afin de permettre aux utilisateurs de rester identifiés pour une période plus longue, que le navigateur ait été fermé ou pas, Elgg utilise un cookie (nommé par défaut elggperm) qui contient ce qui peut être considéré comme un super identifiant de session. Cet identifiant est conservé dans une table des cookies. Quand une session est initiée, Elgg vérifie la présence du cookie elggperm. S’il existe et que le code de session dans le cookie correspond au code dans la table des cookies, l’utilisateur correspondant est automatiquement connecté.

Authentification alternative

Note

Cette section est très lacunaire

Pour remplacer le système d’authentification par défaut des utilisateurs d’Elgg, un plugin pourrait remplacer l’action par défaut avec sa propre action via register_action(). Il devrait également enregistrer son propre gestionnaire d’authentification (PAM) en utilisant register_pam_handler().

Note

La fonction pam_authenticate() utilisée pour appeler les différents modules comporte un bogue lié à la variable d’importance.

HTTPS

Note

Vous devez activer le support de SSL sur votre serveur pour que chacune de ces techniques fonctionne.

Pour que le formulaire de connexion soit soumis sur https, activez login-over-ssl à partir du panneau d’administration d’Elgg.

Vous pouvez également servir l’ensemble de votre site via SSL en changeant simplement l’URL du site pour inclure “https” au lieu de simplement “http”.

XSS

Le filtrage est utilisé dans Elgg pour rendre les attaques XSS plus difficiles. L’objectif du filtrage est de supprimer les JavaScript et autres saisies dangereuses des utilisateurs.

Le filtrage est assuré à travers la fonction filter_tags(). Cette fonction prend une chaîne de caractères et retourne une chaîne filtrée. Elle déclenche le hook plugin validate, input.

Par défaut Elgg est fourni avec le code de filtrage htmLawed sous forme de plugin. Les développeurs peuvent ajouter n’importe quel code additionnel ou de remplacement sous forme de plugin.

La fonction filter_tags() est appelée pour chaque saisie utilisateur dès lors que la saisie est obtenue à travers un appel à get_input(). Si pour quelque raison un développeur souhaite ne pas appliquer le filtrage par défaut sur certaines saisies utilisateur, la fonction get_input() a un paramètre pour désactiver le filtrage.

CSRF / XSRF

Elgg génère des jetons de sécurité pour empêcher la contrefaçon de requêtes inter-sites. Ceux-ci sont intégrés dans tous les formulaires et les requêtes AJAX modificatrices d’état dès lors que la bonne API est utilisée. Lisez-en plus dans le guide de développement Formulaires + Actions.

Injection SQL

L’API d’Elgg’s assainit toutes les entrées avant d’effectuer des requêtes en base de données. Lisez-en plus dans la documentation de design Base de données.

Vie privée

Elgg utilise un système d’ACL pour contrôler quels utilisateurs ont accès à divers éléments de contenu. Lisez-en plus dans la Base de données documentation de design.