Les failles de sécurité historiques des CMS PHP populaires ?

Question

Je suis en train de créer un CMS PHP qui, je l'espère, sera utilisé par le public. La sécurité est une préoccupation majeure et j'aimerais apprendre de certains des CMS PHP les plus populaires comme Wordpress, Joomla, Drupal, etc. Quelles sont les failles de sécurité ou les vulnérabilités qu'ils ont eues dans le passé et que je peux éviter dans mon application, et quelles stratégies puis-je utiliser pour les éviter ? Quels sont les autres problèmes dont je dois me préoccuper et qui n'ont peut-être pas été considérés comme des vulnérabilités parce qu'ils les ont traités correctement dès le départ ? Quelles caractéristiques ou mesures de sécurité supplémentaires incluriez-vous, qu'il s'agisse de détails infimes ou d'approches de sécurité au niveau du système ? Veuillez être aussi précis que possible. Je suis généralement au courant de la plupart des vecteurs d'attaque habituels, mais je veux m'assurer que toutes les bases sont couvertes, alors n'ayez pas peur de mentionner également les éléments évidents. Supposons que PHP 5.2+.

Modifier : Je change ceci en un wiki communautaire. Même si l'excellente réponse d'Arkh est acceptée, je suis toujours intéressé par d'autres exemples si vous en avez.

Answer 1

Falsification de requête intersite (CSRF)

Description :

L'idée de base est d'attirer un utilisateur vers une page où son navigateur lancera une requête POST ou GET vers le CMS que vous attaquez.

Imaginez que vous connaissez l'adresse électronique d'un administrateur de site utilisant un CMS. Envoyez-lui une page web amusante avec ce que vous voulez dedans. Dans cette page, vous créez un formulaire avec les données utilisées par le panneau d'administration du CMS pour créer un nouvel utilisateur administrateur. Envoyez ces données au panneau d'administration du site, avec le résultat dans une iframe cachée de votre page web. Voilà, vous avez créé votre propre compte administrateur.

Comment la prévenir :

La méthode habituelle consiste à générer un nonce aléatoire de courte durée (15 minutes à une heure) dans tous vos formulaires. Lorsque votre CMS reçoit les données d'un formulaire, il vérifie d'abord si le nonce est correct. Si ce n'est pas le cas, les données ne sont pas utilisées.

Exemples de CMS :

• Le CMS en toute simplicité
• Joomla !
• Drupal
• ModX

Plus d'informations :

Sur le wikipedia et sur la page Projet OWASP .

Mauvais stockage des mots de passe

Description :

Imaginez que votre base de données soit piratée et publiée sur quelque chose comme wikileak. Sachant qu'une grande partie de vos utilisateurs utilisent le même login et mot de passe pour de nombreux sites web, voulez-vous qu'ils soient faciles à obtenir ?

Non. Vous devez atténuer les dommages causés si les données de votre base deviennent publiques.

Comment la prévenir :

• Une première idée est de les hacher. Ce qui est une mauvaise idée à cause de tables arc-en-ciel (même si le hachage n'est pas md5 mais sha512 par exemple).
• Deuxième idée : ajouter un sel aléatoire unique avant le hachage pour que les pirates aient à forcer chaque mot de passe. Le problème est que le pirate peut calculer beaucoup de hashs rapidement.
• L'idée actuelle est donc de faire en sorte que le hachage des mots de passe soit lent : vous ne vous en souciez pas car vous ne le faites pas souvent. Mais l'attaquant pleurera quand il passera de 1000 hashs générés par ms à 1.

Pour faciliter le processus, vous pouvez utiliser la bibliothèque phpass développé par un gourou des mots de passe.

Exemples de CMS :

• Joomla ! : md5 salé
• ModX : md5
• Typo3 : texte clair
• Drupal : passage à phpass après cette discussion .

Plus d'informations :

Le site page phpass .

Cross Site Scripting (XSS)

Description

Le but de ces attaques est de faire en sorte que votre site Web affiche un script qui sera exécuté par votre utilisateur légitime.

Il en existe deux sortes : persistants ou non. La première provient généralement de quelque chose que votre utilisateur peut sauvegarder, l'autre compte sur les paramètres donnés par une requête envoyée. Voici un exemple, non persistant :

<?php
if(!is_numeric($_GET['id'])){
  die('The id ('.$_GET['id'].') is not valid');
}
?>

Maintenant, votre attaquant peut juste envoyer des liens comme http://www.example.com/vulnerable.php?id=<script>alert('XSS')</script>

Comment la prévenir

Vous devez filtrer tout ce que vous envoyez au client. Le moyen le plus simple est d'utiliser htmlspecialchars si vous ne voulez pas laisser votre utilisateur sauvegarder du html. Mais, lorsque vous les laissez produire du html (soit leur propre html, soit du html généré par d'autres choses comme le bbcode), vous devez être très prudent. Voici un vieil exemple utilisant l'événement "onerror" de la balise img : Vulnérabilité de vBulletin . Ou vous avez l'ancien Samy de Myspace .

Exemples de CMS :

• Le CMS en toute simplicité
• Mura CMS
• Drupal
• ModX

Plus d'informations :

Vous pouvez vérifier wikipedia y OWASP . Vous avez également beaucoup de vecteur XSS sur ha.ckers page.

Injection d'en-tête de courrier

Description :

Les en-têtes de courrier sont séparés par le CRLF ( \r\n ) séquence. Lorsque vous utilisez certaines données de l'utilisateur pour envoyer des courriers (par exemple, pour le champ "From :" ou "To :"), il peut injecter d'autres en-têtes. Avec cela, ils peuvent envoyer des mails anonymes depuis votre serveur.

Comment la prévenir :

Filtrez tous les \n , \r , %0a y %0d dans vos en-têtes.

Exemples de CMS :

• Jetbox CMS

Plus d'informations :

Wikipedia est un bon début, comme d'habitude.

Injection SQL

Description :

Le vieux classique. Cela se produit lorsque vous formulez une requête SQL en utilisant une entrée directe de l'utilisateur. Si cette entrée est conçue comme il se doit, l'utilisateur peut faire exactement ce qu'il veut.

Comment la prévenir :

Simple. Ne formez pas de requêtes SQL avec la saisie de l'utilisateur. Utilisez requêtes paramétrées . Considérez toute entrée qui n'est pas codée par vous-même comme une entrée utilisateur, qu'elle provienne du système de fichiers, de votre propre base de données ou d'un service Web, par exemple.

Exemple de CMS :

• Drupal
• Joomla !
• ModX
• Pars CMS

Plus d'informations :

Wikipedia y OWASP ont de très bonnes pages sur le sujet.

Fractionnement de la réponse Http

Description :

Comme les en-têtes de courrier électronique, les en-têtes http sont séparés par la séquence CLRF. Si votre application utilise l'entrée de l'utilisateur pour produire des en-têtes, il peut utiliser cette séquence pour créer les siens.

Comment la prévenir :

Comme pour les e-mails, filtrez \n , \r , %0a y %0d des caractères de la saisie de l'utilisateur avant de l'utiliser comme partie d'un en-tête. Vous pouvez également urlencode vos en-têtes.

Exemples de CMS :

• Drake CMS
• Plone CMS
• Wordpress

Plus d'informations :

Je vous laisse deviner un peu où vous pouvez trouver beaucoup d'informations sur ce type d'attaque. OWASP y Wikipedia .

Détournement de session

Description :

Dans ce cas, l'attaquant veut utiliser la session d'un autre utilisateur légitime (et, espérons-le, authentifié). Pour cela, il peut soit changer son propre cookie de session pour qu'il corresponde à celui de la victime, soit faire en sorte que la victime utilise son propre identifiant de session (celui de l'attaquant).

Comment la prévenir :

Rien ne peut être parfait ici : - si l'attaquant vole le cookie de la victime, vous pouvez vérifier que la session de l'utilisateur correspond à son IP. Mais cela peut rendre votre site inutile si les utilisateurs légitimes utilisent un proxy qui change souvent d'IP. - si l'attaquant fait en sorte que l'utilisateur utilise son propre ID de session, utilisez simplement session_regenerate_id pour changer l'ID de session d'un utilisateur lorsque ses droits changent (connexion, déconnexion, accès à la partie admin du site web, etc.)

Exemples de CMS :

• Joomla ! y Drupal
• Panier zen

Plus d'informations :

Wikipedia page sur le sujet.

Autre

• User DoSing : si vous empêchez le bruteforcing des tentatives de login en désactivant les noms d'utilisateurs essayés et non l'IP d'où proviennent les tentatives, n'importe qui peut bloquer tous vos utilisateurs en 2mn. Même chose lors de la génération de nouveaux mots de passe : ne désactivez pas l'ancien jusqu'à ce que l'utilisateur confirme le nouveau (en se connectant avec lui par exemple).
• Utiliser l'entrée de l'utilisateur pour faire quelque chose sur votre système de fichiers. Filtrez cela comme s'il s'agissait d'un cancer mélangé à du sida. Cela concerne l'utilisation de include et require sur des fichiers dont le chemin est fait en partie à partir de l'entrée de l'utilisateur.
• Utilisation de eval , système , exec ou quoi que ce soit de ce genre avec l'entrée de l'utilisateur.
• Ne mettez pas les fichiers que vous ne voulez pas rendre accessibles sur le web dans le répertoire accessible sur le web.

Vous avez beaucoup de choses que vous pouvez lire sur le OWASP page.

Answer 2

Je me souviens d'un cas plutôt amusant sur phpBB. Le cookie autologin contenait un tableau sérialisé contenant un userId et un mot de passe crypté (sans sel). Changez le mot de passe en un booléen avec la valeur true et vous pouvez vous connecter en tant que qui vous voulez. N'aimez-vous pas les langages à faible typage ?

Un autre problème rencontré par phpBB concernait une expression régulière pour la mise en évidence des mots-clés de recherche, qui comportait une fonction de rappel (avec l'attribut e modifier ), qui vous permet d'exécuter votre propre code PHP - par exemple, des appels système sur des systèmes non sécurisés ou simplement l'édition du fichier de configuration pour obtenir le login/mot de passe MySQL.

Donc, pour résumer cette histoire :

• Attention à la faiblesse de PHP ( md5( "secretpass" ) == true ).
• Soyez prudent avec tout code qui pourrait être utilisé dans un callback (ou pire, eval).

Et bien sûr, il y a les autres questions déjà mentionnées avant moi.

Answer 3

Un autre problème de sécurité au niveau de l'application auquel j'ai vu des CMS faire face est l'autorisation insuffisante de l'accès au niveau des pages ou des fonctions. En d'autres termes, la sécurité est établie en montrant uniquement les liens lorsque vous êtes autorisé à les voir, mais sans vérifier complètement que le compte utilisateur est autorisé à voir la page ou à utiliser la fonctionnalité une fois qu'il est sur la page.

En d'autres termes, un compte administrateur affiche des liens permettant d'accéder aux pages de gestion des utilisateurs. Mais la page de gestion des utilisateurs vérifie seulement que l'utilisateur est connecté, et non qu'il est connecté et administrateur. Un utilisateur ordinaire se connecte alors, tape manuellement l'URI de la page d'administration, puis dispose d'un accès complet aux pages de gestion des utilisateurs et fait de son compte un compte d'administration.

Vous seriez surpris de savoir combien de fois j'ai vu ce genre de choses, même dans des applications de panier d'achat où les données CC des utilisateurs sont visibles.

Answer 4

Tellement, tellement

Un certain nombre de réponses énumèrent des vulnérabilités spécifiques dont ils se souviennent ou des "choses dont je me soucie lorsque j'écris une application web", mais si vous voulez une liste raisonnablement fiable de la majorité des vulnérabilités signalées dans le passé, vous ne pouvez pas faire pire que de chercher dans le site Web de la Commission européenne. Base de données nationale sur la vulnérabilité

Il y a 582 vulnérabilités signalées dans Joomla ou ses addons, 199 pour Wordpress et 345 pour Drupal, que vous devez digérer.

Pour une compréhension générique des vulnérabilités courantes des applications web, l'option Projet OWASP Top Ten a récemment été mis à jour et constitue une lecture essentielle pour tout développeur web.

• A1 : Injection
• A2 : Cross-Site Scripting (XSS)
• A3 : Authentification et gestion de session cassées
• A4 : Références directes à un objet non sécurisées
• A5 : Falsification de requête intersite (CSRF)
• A6 : Mauvaise configuration de la sécurité
• A7 : Stockage cryptographique non sécurisé
• A8 : Absence de restriction de l'accès aux URLs
• A9 : Protection insuffisante de la couche de transport
• A10 : Redirections et transferts non validés

Answer 5

Le plus gros problème que beaucoup de gens semblent oublier ou ne pas réaliser est que n'importe qui peut envoyer n'importe quelle donnée à vos scripts, y compris les cookies et les sessions, etc. Et n'oubliez pas que ce n'est pas parce qu'un utilisateur est connecté qu'il peut faire quoi que ce soit.

Par exemple, si vous aviez un script qui gère l'ajout/modification d'un commentaire, vous pourriez avoir ceci :

if ( userIsLoggedIn() ) {
    saveComment( $_POST['commentid'], $_POST['commenttext'] )
}

Vous voyez ce qui ne va pas ? Vous avez vérifié que l'utilisateur est connecté, mais vous n'avez pas vérifié si l'utilisateur est propriétaire du commentaire, ou s'il peut le modifier. Ce qui signifie que n'importe quel utilisateur connecté peut poster un ID et un contenu de commentaire et éditer les commentaires des autres !

---

Une autre chose à garder à l'esprit lorsque vous fournissez des logiciels à d'autres personnes est que les configurations de serveur varient énormément. Par exemple, lorsque des données sont publiées, vous pouvez faire ceci :

if (get_magic_quotes_gpc())
    $var = stripslashes($_POST['var']);
else
    $var = $_POST['var'];