Sécurité

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

Astuce

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

Mots de passe

Validation du mot de passe

La seule restriction que Elgg impose sur un mot de passe est qu’il doit contenir au moins 6 caractères par défaut, même si cela puisse être modifié dans /elgg-config/settings.php. Des critères supplémentaires peuvent être ajoutés par un plugin en s’enregistrant auprès de l’événement registeruser:validate:password.

Hachage du mot de passe

Les mots de passe ne sont jamais stockés en clair, seulement sous forme de valeur de hachage avec sel produit par bcrypt. Ceci est effectué via la fonction standard password_hash(). Sur des systèmes plus anciens, le polyfill password-compat est utilisé, mais l’algorithme est identique.

Les installations Elgg créées avant la version 1.10 peuvent avoir des chaînes de hachage de mot de passe « historiques » résiduelles créées en utilisant MD5 avec sel. Elles sont migrées vers bcrypt lorsque les utilisateurs se connectent, et sont totalement retirées lorsque le système est mis à niveau vers Elgg 3.0. Dans le même temps, nous sommes heureux d’inciter 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 e-mail est envoyé avec une URL unique. Quand l’utilisateur visite cette URL, un nouveau mot de passe est envoyé par e-mail à 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, l’identfiant et l’adresse e-mail.

La durée de vie de la session est contrôlée par la configuration PHP du serveur, et additionnellement à travers les options dans le fichier /elgg-config/settings.php.

Fixation de session

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

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 non, 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 la 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é.

Lorsqu’un utilisateur change son mot de passe, tous les cookies permanents sont supprimés de la base de données.

La durée de vie des cookies persistants peut être contrôlée dans le fichier /elgg-config/settings.php. La durée de vie par défaut est de 30 jours. Les entrées de la base de données pour les cookies persistants seront supprimées après l’expiration de la durée de vie.

Authentification alternative

Note

Cette section est très lacunaire

Pour remplacer le système d’authentification par défaut des utilisateurs de Elgg, un plugin pourrait remplacer l’action par défaut login par sa propre action. Une meilleure alternative est d’enregistrer un gestionnaire d’authentification PAM en utilisant elgg_register_pam_handler() qui gère l’authentification des utilisateurs sur la base de nouvelles exigences.

HTTPS

Note

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

Vous pouvez servir l’ensemble de votre site par SSL en changeant l’URL du site pour inclure « https » au lieu de seulement « 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 effectué via la fonction elgg_sanitize_input(). Cette fonction récupère une chaîne et renvoie une chaîne filtrée. Il déclenche un événement sanitize, input.

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

La fonction elgg_sanitize_input() est appelée pour chaque saisie utilisateur dès lors que la saisie est obtenue à travers un appel à get_input(). Si pour une raison quelconque un développeur souhaite ne pas appliquer le filtrage par défaut sur certaines saisies utilisateur, la fonction get_input() dispose d’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.

URLs signées

Il est possible de protéger les URLs avec une signature unique. Lisez-en plus dans le Guide de développement Formulaires + Actions.

Injection SQL

L’API de Elgg’s assainit toutes les entrées avant d’effectuer des requêtes dans la 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 aux divers éléments de contenu. Lisez-en plus dans la documentation du design de la base de données Base de données.

Sécurisation

Les administrateurs du site peuvent configurer des paramètres qui vont aider à sécuriser le site. Lisez-en plus dans le Guide d’administration Sécurité.