Sécurité pour les développeurs
 | Cette page documente un guide de développement de MediaWiki, construit au fil du temps par consensus des développeurs (ou parfois simplement par un des développeurs principaux) |
En tant que développeur MediaWiki, vous avez la responsabilité d'écrire du code sécurisé dans un style facile à relire et à modifier. Cet article traite des problèmes relatifs à la sécurité et des meilleures manières utilisées par les développeurs MediaWiki pour résoudre ces problèmes de sécurité. Pour les problèmes concernant la manière de coder, lire les conventions de codage de MédiaWiki.
Chaque développeur MediaWiki doit lire soigneusement cet article quelque soit son niveau d'expérience dans le développement des applications web et de PHP, et se refamiliariser périodiquement avec ce contenu. De plus, chauqe développeur doit lire soigneusement les articles à propos du Cross-site scripting (XSS), du Cross-site request forgery (CSRF), et Injection de SQL, qui fournissent chacun des explications plus détaillées sur ces types communs de failles. La page Points de sécurité vérifiés par les développeurs fournit une référence utile pour les tâches communes de développement.
Importance de la sécurité
La sécurité des applications web est un problème critique dans le monde cablé. Les sites web avec des failles de sécurité sont une partie clé de l'infrastructure globale illicite du vandalisme, pourriel et phishing. Les dresseurs de robots parcourent le web à la recherche de sites web présentant des failles de sécurité, puis utilisent ces vulnérabilités pour les détourner. Le site web qui a été attaqué va distribuer des malware (c'est à dire des virus) aux visiteurs, soit en utilisant les failles de leur navigateur ou d'une manière générale par ingénierie sociale. Le logiciel malveillant téléchargé transforme l'ordinateur du client en un « zombie » qui fait partie d'un réseau mondial de crime organisé visant à voler les coordonnées bancaires, à envoyer du spam et à extorquer de l'argent à des sites web présentant des menaces de déni de service.
Sécurité démontrable
Ce n'est pas suffisant de vérifier que vous êtes parfait et que votre code ne présente pas de failles de sécurité. Chacun fait des erreurs. Tout le code de base, et une bonne partie du code des extensions, est examiné par des développeurs expérimentés pour vérifier sa sécurité. Ceci est une bonne méthode et doit être encouragé.
Ecrivez du code de sorte à pouvoir montrer qu'il est fiable du point de vue sécurité, de sorte à ce qu'un relecteur puisse affirmer qu'il est sécurisé. N'écrivez pas de code qui semble non fiable à première vue et qui après relecture se révèlerait fiable. Un tel code affole inutilement les relecteurs.
Apperçu des failles de sécurité et des attaques
Ce document cible particulièrement les attaques suivantes et les risques de sécurité. Tout développeur MediaWiki devrait être familier avec ces problèmes et avoir au moins déjà compris de quoi ils relèvent.
Scripts XSS inter sites
Pour le détail des informations sur la manière d'éviter les failles XSS dans MediaWiki, lire l'article Scripts inter-sites. Les failles XSS (de Cross-site scripting) permettent aux attaquants d'injecter du code malicieux sur un site web. Les failles XSS sont causées par une application web qui n'échappe pas proprement les données venant des sources externes (utilisation de GET data, POST data, des flux RSS et URLs). L'éventail des attaques pouvant être faites via XSS est très large, partant des farces inoffensives jusqu'au piratage du compte d'un utilisateur authentifié.
Défense immédiate : pour éviter les attaques XSS les principes de base sont :
- Validez vos entrées
- Echappez vos sorties
Vous pouvez sauter la validation mais pas l'échappement. Tout doit être échappé. Echappez aussi près que possible de la sortie de sorte à ce que le relecteur puisse vérifier facilement que cela a été fait.
Notez que l'encodage des sorties (c'est à dire l'échappement) dépend du contexte. Soyez donc conscient du contexte de sortie prévu et encodez de manière appropriée (par exemple l'entité HTML, l'URL, le JavaScript, etc.)
Le OWASP Abridged XSS Prevention Cheat Sheet est un guide de référence rapide utile et à jour pour atténuer les problèmes XSS.
Si vous écrivez du JavaScript, assurez-vous que vous comprenez le XSS basé sur le DOM, et savez comment l'empêcher dans votre code.
Falsification des requêtes intersite (CSRF Cross-site request forgery)
Pour les informations détaillées sur la manière d'éviter les failles CSRF dans MediaWiki, veuillez lire l'article Forge des requêtes inter-sites. Les attaques du type Cross-site request forgery (CSRF ou XSRF) utilisent les crédits d'authentification se trouvant dans le cache du navigateur de la victime (tels qu'un cookie ou un nom d'utilisateur et mot de passe mis en cache) pour autoriser des requêtes HTTP malicieuses. La requête HTTP malicieuse peut être envoyée de différentes manières. Tant que les requêtes sont traitées par un navigateur web qui a mis en cache les crédits d'authentification, une attaque CSRF peut être tentée.
Défense immédiate : utiliser d'abord les jetons d'édition dans les formulaires HTML comme premier mécanisme de défense.
Injection de SQL
Pour des informations détaillées sur la manière d'éviter l'injection de SQL, lire l'article SQL injection.
L'injection de SQL s'appuie sur des entrées trop faiblement validées et utilisées dans une requête vers la base de données, permettant éventuellement à l'attaquant d'exécuter des requêtes SQL arbitraires sur votre serveur. L'attaquant ayant ensuite la possibilité de récupérer des données privées, de détruire des données ou de provoquer d'autres réponses non souhaitées. Dans le pire des cas, le code injecté peut permettre à l'attaquant de prendre le contrôle total du système en exploitant de multiples failles du serveur de base de données, des utilisaires système ou du système d'exploitation.
Défense immédiate : pour se défendre contre l'injection de SQL, utiliser les fonctions MediaWiki préintégrées de la base de données. Evitez d'utiliser des commandes SQL directes à tout prix.
serialize() / unserialize()
unserialize() peut conduire à exécuter du code arbitraire.
Pour éviter cela les développeurs MediaWiki doivent toujours utiliser Json au lieu de la sérialisation PHP dans le code nouveau.
Défense immédiate : utiliser FormatJson::encode() et FormatJson::decode() au lieu de la sérialisation native de PHP.
Historique
- register_globals, n'est plus un problème depuis MediaWiki 1.24+.
Voir aussi
- Points de sécurité vérifiés par les développeurs – liste de points concernant les tâches communes de développement avec les mesures de sécurité nécessaires correspondantes
- phan-taint-check-plugin – outils d'analyse statistique dédié MediaWiki qui vérifie votre extension quant aux failles de sécurité habituelles. Exécuté comme partie de Phan.
- PhpStorm project security – pour les développeurs qui utilisent l'environnement de développement PhpStorm
- Sécurité – Comment rapporter des problèmes de sécurité dans les logiciels Wikimedia
- Vulnérabilités communes
- XSS
- Forge des requêtes inter-sites
- Injection de SQL
- Open Web Application Security Project (OWASP) – aperçu général des vulnérabilités
- Manuel:Sécurité – informations pour les administrateurs systèmes MediaWiki sur la manière de renforcer votre installation MediaWiki
Sous-pages