Les failles de sécurité historiques des CMS PHP populaires?
je crée un CMS PHP, un qui j'espère sera utilisé par le public. La sécurité est une préoccupation majeure et je voudrais apprendre de certains des CMS PHP populaires comme Wordpress, Joomla, Drupal, etc. Quelles sont les failles de sécurité ou les vulnérabilités qu'ils ont connues dans le passé que je peux éviter dans mon application et quelles stratégies puis-je utiliser pour les éviter? Quelles sont les autres questions que je dois être préoccupé par ce qu'ils n'ont peut-être pas fait face comme une vulnérabilité parce qu'ils l'ont manipulé correctement dès le début? Quelles autres caractéristiques ou mesures de sécurité incluriez-vous, qu'il s'agisse de détails mineurs ou d'approches de sécurité au niveau du système? Veuillez être aussi précis que possible. je suis généralement conscient 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 l'évidence aussi. Supposons PHP 5.2+.
Edit :je change ceci à 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 les avez.
9 réponses
Cross-Site Request Forgery (CSRF)
Description:
l'idée de base est de tromper un utilisateur à une page où son navigateur va initier un POST ou obtenir la demande au CMS que vous attaquez.
Imaginez que vous connaissez l'email d'un administrateur de site alimenté par CMS. Envoyez-lui une page Web drôle 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 administrateur utilisateur. Envoyez ces données au panneau d'administration du site Web, avec le résultat dans une iframe cachée de votre page web. Voilà, vous avez votre propre compte administrateur fait.
Comment les prévenir :
la manière habituelle est de générer des nonce aléatoires de courte durée (15mn à l'heure) dans toutes vos formes. Lorsque votre CMS reçoit les données d'un formulaire, il vérifie d'abord si le nonce est correct. Si non, les données ne sont pas utilisés.
CMS examples :
plus d'informations:
sur la page wikipedia et sur la page OWASP project .
mauvaise mémorisation du mot 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 d'utiliser le même login et mot de passe pour un grand nombre de sites web, voulez-vous être facile à obtenir ?
Pas de. Vous devez atténuer les dégâts si votre base de données.
Comment les prévenir :
- une première idée est de de hachage. Ce qui est une mauvaise idée en raison 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 de sorte que les pirates doit bruteforce chaque mot de passe. Le problème est, le hacker peut calculer beaucoup de hachage rapide.
- ainsi, l'idée actuelle est de le rendre lent à hachez les mots de passe : vous ne vous souciez pas parce que vous ne le faites pas souvent. Mais l'agresseur pleurera quand il passe de 1000 hash générés par ms à 1.
pour faciliter le processus, vous pouvez utiliser la bibliothèque phpass développé par un gourou de mot de passe.
CMS examples :
- Joomla! : salé md5 1519290920"
- ModX: md5
- Typo3 : texte en clair
- Drupal: commuté en phpass après cette discussion .
plus d'informations:
Le phpass page .
Cross Site Scripting (XSS)
Description
Le but de ces attaques est de rendre votre site web un script qui sera exécuté par votre utilisateur légitime.
vous avez deux sortes de ceux-ci : persistante ou non. Première l'un vient habituellement de quelque chose que votre utilisateur peut enregistrer, l'autre compte sur les paramètres donnés par une demande 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 les empêcher
vous devez filtrer tout ce que vous produisez pour le client. La façon la plus simple est d'utiliser htmlspécialchars si vous ne voulez pas laisser votre utilisateur sauver HTML. Mais, quand vous les laissez sortir html (soit leur propre html ou d'autres produits d'autres choses comme bbcode) vous devez être très prudent. Voici un ancien exemple utilisant l'événement "onerror" de la balise img : vulnérabilité vBulletin . Ou vous avez l'ancien Myspace's Samy .
CMS examples :
plus d'informations:
vous pouvez cocher wikipedia et OWASP . Vous avez aussi beaucoup de vecteur XSS sur ha.caters page.
injection en-tête de courrier
Description:
Les en-têtes sont séparés par la séquence CRLF ( \r\n ). Lorsque vous utilisez certaines données utilisateur pour envoyer des mails (comme L'utiliser pour le From: ou Le To:), ils peuvent injecter plus d'en-têtes. Avec cela, ils peuvent envoyer des mails à partir de votre serveur.
Comment les prévenir :
filtrer tous les \n , \r , %0a et %0d dans vos en-têtes.
CMS examples :
plus d'informations:
Wikipedia est un bon début comme d'habitude.
SQL Injection
Description:
le vieux classique. Cela se produit lorsque vous formez une requête SQL en utilisant l'entrée directe de l'utilisateur. Si cette entrée est conçue comme nécessaire, un l'utilisateur peut faire exactement ce qu'il veut.
Comment les prévenir :
Simple. Ne formez pas de requêtes SQL avec l'entrée de l'utilisateur. Utiliser les 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 vienne du système de fichiers, de votre propre base de données ou d'un service Web par exemple.
exemple CMS:
plus d'informations:
Wikipedia et OWASP ont vraiment de bonnes pages sur le sujet.
fractionnement de la réponse Http
Description:
comme les en-têtes e-mail, les en-têtes http sont séparés par la séquence CLRF. Si votre application utilise l'entrée de l'utilisateur aux en-têtes de sortie, ils peuvent l'utiliser pour créer leur propre.
Comment les prévenir :
comme pour les e-mails, filtre \n , \r , %0a et %0d caractères de l'utilisateur avant de l'utiliser comme une partie d'un en-tête. Vous pouvez aussi urlencode vos en-têtes.
CMS examples :
plus d'informations:
je vous laisse deviner un peu de l'endroit où vous pouvez trouver beaucoup d'infos sur ce genre d'attaque. OWASP et Wikipedia .
détournement de Session
Description:
dans celui-ci, l'attaquant veut utiliser la session d'un autre utilisateur légitime (et avec un peu de chance authentifié). Pour cela, il peut modifier son propre cookie de session pour correspondre à la victime ou qu'il peut faire la victime utiliser son (l'attaquant) propre id de session.
Comment les prévenir :
Rien ne peut être parfait ici : - si l'attaquant de voler la victime cookie, vous pouvez vérifier que la session de l'utilisateur correspond à l'IP de l'utilisateur. Mais cela peut rendre votre site inutile si les utilisateurs légitimes utilisent un proxy qui change souvent L'IP. - si l'attaquant fait que l'utilisateur utilise son propre identifiant de session, il suffit d'utiliser session_regenerate_id pour modifier l'identifiant de session d'un utilisateur lorsque ses droits changent (connexion, déconnexion, accès à la partie admin du site, etc.).
CMS examples :
plus d'informations:
Wikipedia page sur le sujet.
autres
- dose utilisateur: si vous empêchez bruteforcing de tentative de connexion en désactivant les noms d'utilisateurs essayé et non L'IP d'où proviennent les tentatives, n'importe qui peut bloquer tous vos utilisateurs dans 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 vous connectant par exemple).
- utiliser l'entrée de l'utilisateur pour faire quelque chose sur votre système de fichiers. Filtrez ceci comme si c'était un cancer mélangé avec le sida. Cela concerne l'utilisation d'include et require sur les fichiers dont le chemin est fait en partie à partir de l'entrée de l'utilisateur.
- utilisant eval , système , exec ou quelque chose de ce genre avec l'entrée de l'utilisateur.
- ne mettez pas les fichiers que vous ne voulez pas web accessible dans le répertoire web accessible.
vous avez beaucoup de choses que vous pouvez lire sur la page OWASP .
je me souviens d'une assez drôle de phpBB. Le cookie autologin contenait un tableau sérialisé contenant un nom d'utilisateur et un mot de passe crypté (pas de sel). Changez le mot de passe en un booléen avec la valeur true et vous pouvez vous connecter comme n'importe qui que vous vouliez être. N'aimez-vous pas weaktyped langues?
un autre problème que phpBB avait dans une expression régulière pour la mise en évidence des mots-clés de recherche qui avaient un rappel (avec le e modifier ), qui vous a permis d'exécuter votre propre code PHP - par exemple, les appels système sur les systèmes non sécurisés ou tout simplement la sortie 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 le code qui pourrait être utilisé dans un rappel (ou pire, eval).
et bien sûr il y a les autres questions déjà mentionnées avant moi.
un autre problème de sécurité au niveau de l'application que j'ai vu traiter par le Scemd est l'autorisation insuffisante de l'accès au niveau de la page ou de la fonction. En d'autres termes, la sécurité étant définie en montrant seulement les liens lorsque vous êtes autorisé à voir ces liens, mais pas entièrement vérifier que le compte d'utilisateur est autorisé à voir la page ou utiliser la fonctionnalité une fois qu'ils sont sur la page.
en d'autres termes, un compte administrateur a des liens affichés pour aller aux pages de gestion des utilisateurs. Mais l' gestion des utilisateurs page vérifie seulement que l'utilisateur est connecté, pas qu'ils sont connectés et administrateur. Un utilisateur régulier se connecte alors, tape manuellement dans L'URI de la page d'admin, puis a un accès admin complet aux pages de gestion de l'utilisateur et fait de son compte un compte admin.
vous seriez surpris du nombre de fois où j'ai vu des choses comme ça, même dans les applications de panier d'achat où l'utilisateur CC données est visible.
le plus grand que tant de gens semblent oublier ou ne pas se rendre compte est que n'importe qui peut poster n'importe quelles données à vos scripts, y compris les cookies et les sessions etc. Et n'oubliez pas, juste parce qu'un utilisateur est connecté, ne signifie pas qu'ils peuvent faire n'importe quelle action.
Par exemple, si vous avez un script qui gère l'ajout/édition d'un commentaire, vous pourriez avoir cette:
if ( userIsLoggedIn() ) {
saveComment( $_POST['commentid'], $_POST['commenttext'] )
}
pouvez-vous voir ce qui ne va pas? - Vous vérifié que l'utilisateur est connecté, mais vous n'avez pas vérifié si l'utilisateur possède le commentaire, ou est en mesure de modifier le commentaire. Ce qui signifie que n'importe quel utilisateur connecté pourrait poster un ID de commentaire et du contenu et éditer les commentaires des autres!
une autre chose à se rappeler lors de la fourniture de logiciels à d'autres est que la configuration du serveur varie énormément. Lorsque les données sont publiées, vous pouvez faire ceci, par exemple:
if (get_magic_quotes_gpc())
$var = stripslashes($_POST['var']);
else
$var = $_POST['var'];
tellement..
un certain nombre de réponses ici sont la liste de vuls spécifiques qu'ils se souviennent ou générique "choses que je me soucie en écrivant une webapp", mais si vous voulez une liste raisonnablement fiable d'une majorité de vulnérabilités signalées trouvé historiquement, alors vous ne feriez pas beaucoup pire que de rechercher le National Vulnerability Database
il y a 582 vulnérabilités signalées dans Joomla ou Joomla addons, 199 pour Wordpress et 345 pour Drupal à digérer.
pour la compréhension générique de common webapp vuls, le OWASP Top Ten project a récemment été mis à jour et est une lecture essentielle pour tout développeur web.
- A1: Injection
- A2: Cross-Site Scripting (XSS)
- A3: Broken d'Authentification et de Gestion de Session
- A4: Objet Direct Non Sécurisé Références
- A5: falsification de demandes intersite (CSRF)
- A6: Mauvaise Configuration De La Sécurité
- A7: Unsafe Cryptographic Storage
- A8: défaut de restreindre L'accès aux URL
- A9: Protection Insuffisante De La Couche Transport
- A10: redirections non validées et Forwards
Quatre grands dans mon esprit:
- utilisant le code exec sur les données non fiables (ou en général)
- comprennent-ing fichiers distants d'URL pour l'exécution locale
- activer les variables globales de Registre pour que les variables get et post attribuez automatiquement des valeurs variables.
- pas échapper db entrée de données/ permettre des attaques par injection SQL (cela se produit généralement quand on n'utilise pas une couche D'API DB)
ne permet pas de poste d'autres Domaine / IP afin Bots cant login / soumettre des formulaires.
Peuple , est de la réponse, la plus grande brèche de sécurité, est le humain stupidité . Confiance , examen du code. Vous avez besoin d'une équipe spéciale, qui va passer en revue tout ce qui a ajouté comme un code supplémentaire dans votre application, le problème de cms sont l'externalisation, les revenus, WordPress, Drupal, Joomla, et d'autres cms populaires, comme les installations par défaut, ils sont vraiment dans un très bon point sécurisé. Le problème vient quand vous laissez les gens ajouter du code supplémentaire dans votre application, sans une bonne critique (ou mieux, sans test de pénétration). C'est le point où WordPress et Joomla ont la faiblesse, il y a tant de plugin n thème devs, il y a tant d'approbations,des centaines de plugins obsolètes n thèmes ailleurs.... Donc, imho, si vous êtes en mesure de construire une équipe forte, un bon plan de sécurité, former vos contributeurs, et leur apprendre à coder sécurisé, et avec tous les d'autres commentaires avant le mien, alors vous serez en mesure d'avancer et dire :ie salut c'est mon cms, et c'est un peu plus sécurisé que tous les autres cms sur le net ;)
voici un pitfall potentiel pour les administrateurs de forum en particulier, mais aussi toute personne qui code vers le haut d'un formulaire avec un sélecteur dropdown mais ne valide pas que la réponse postée était en fait l'une des options disponibles.
à l'Université, j'ai réalisé que le sélecteur "pays" de l'utilisateur dans phpBB n'avait pas une telle validation.
dans notre forum scolaire, au lieu de "Etats-Unis" ou "Afganistan", mon pays pourrait être N'importe quoi, peu importe à quel point stupide, ou sale. Tout Ce Que Je il fallait un formulaire html POST. Il a fallu quelques jours à mes camarades de classe pour comprendre comment j'avais fait, mais bientôt, tous les "enfants cool" avaient des phrases drôles au lieu de pays affichés sous leur nom d'utilisateur.
aller à une fac de geek était génial. : D