[RÉGLÉ] Comment sécuriser une tâche CRON ?

[Visiteur]

Mon environnement : J 3.9.16

Bonjour,

J'ai défini dans le corps d'un article Joomla un script php essentiellement dédié à une tâche devant s'exécuter une fois chaque nuit, sans exception aucune dans le calendrier annuel.
Dans mon Cpanel chez O2switch, j'ai défini la tâche CRON activant cet article en lui précisant l'url de cet article.
Tout fonctionne bien, mais je me pose un sérieux problème d'insécurité : pour que mon hébergeur puisse accéder et exécuter un tel script, j'ai défini l'article correspondant en "accès PUBLIC" (alors qu'il aurait été bien préférable de choisir un accès de type "super-administrateur", mais j'imagine que l'hébergeur ne pourrait alors plus l'exécuter) !

Existe t-il une méthode pour sécuriser une telle tâche, pour empêcher quiconque de faire tourner à tout instant un tel script ... sauf mon hébergeur ?

nb:
1. ce script est évidemment absent de tout menu sur le site, mais je trouve que la sécurité est néanmoins très insuffisante,
2. pour gêner les aspirateurs de sites, j'avais installé un plugin dédié "system : content protection" (tous les articles correspondant à des liens de menu sont protégés contre les copier/coller, sauf ceux précisés dans le plugin). J'ai été contraint de le supprimer car il bloquait mes tâches CRON.

Merci pour votre aide.

[jfque]

Vous pourriez ajouter à l'URL un paramètre avec un "mot secret" (une chaîne de caractères plus ou moins longue). Le script vérifierait la présence et l'exactitude de ce mot avant de s'exécuter.
Pour plus de sécurité, vous pouvez le modifier périodiquement.

[Visiteur]

Vous pourriez ajouter à l'URL un paramètre avec un "mot secret" (une chaîne de caractères plus ou moins longue). Le script vérifierait la présence et l'exactitude de ce mot avant de s'exécuter.
Pour plus de sécurité, vous pouvez le modifier périodiquement.

Bonjour et merci jfque,

Je comprends bien cette bonne idée. Mais, pratiquement, comment la réaliser quand mon script est dans le corps d'un article Joomla (et qui impose donc une url précise de type : mon site/xx-code/xxxx-alias avec xx = n° catégorie article, xxxx = id de l'article) ?
Je ne vois pas du tout !

[lefabdu51]

Salut,
tu ne devrais pas passer par un article mais par la cli.
Regardes dans le dossier cli, tu as des scripts qui utilisent le framework.
Tu recuperes le debut d'un script pour avoir les appels aux fonctions qu il faut .
Tu code ta fonction et en bas tu l'executes via do_execute.
Ensuite tu l appelles via cron ( php /chemin absolu vers joomla/cli/monscript.php). Et la au moins tu est tranquille quand à l'éxécution. Toutes mes taches cron sont codées comme ça. vu que c est dans la cli, c'est bien plus sécurisé que ce que tu fait. De plus, les scripts s'executent dans une session Joomla, ce qui limite les risques d'execution arbitraire.
Les scripts deja présent peuvent directement être utilisés ou servir d'exemple.

[RobertG]

Bonjour,

Encore plus sûr lorsque ce n'est pas une URL avec l'adresse du site qu'il faut lancer, mais un chemin comme cité par lefabdu51 : placer le script hors du dossier du site.

[Visiteur]

Salut,
tu ne devrais pas passer par un article mais par la cli.
Regardes dans le dossier cli, tu as des scripts qui utilisent le framework.
Tu recuperes le debut d'un script pour avoir les appels aux fonctions qu il faut .
Tu code ta fonction et en bas tu l'executes via do_execute.
Ensuite tu l appelles via cron ( php /chemin absolu vers joomla/cli/monscript.php). Et la au moins tu est tranquille quand à l'éxécution. Toutes mes taches cron sont codées comme ça. vu que c est dans la cli, c'est bien plus sécurisé que ce que tu fait. De plus, les scripts s'executent dans une session Joomla, ce qui limite les risques d'execution arbitraire.
Les scripts deja présent peuvent directement être utilisés ou servir d'exemple.

Bonjour et merci,

J'étais justement en train de réfléchir à cette méthode jamais utilisée.
Merci pour toutes tes explications.

[roland_d_alsace]

+1 avec lefabdu51, ce n'est pas le boulot d'un article.

De plus tu peux donner un nom de fichier suffisamment complexe afin que personne ne le trouve.
Tu peux aussi bien sur mettre un tocken (jeton) complexe en variable d'url.
Mais cela reste une sécurité toute relative.

Toutefois qu'elle est précisément ta crainte ?

Les scripts lancé par cron sont généralement fait pour lancer des tâches de maintenance, de synchronisation, de nettoyage ou d'envoi de mail ou sms.
Donc au niveau du traitement il doit savoir ce qu'il doit faire et quand il doit le faire.

Il faut aussi que ton script sache gérer le lancement multiple (éviter un 2ème lancement si le précédent n'est pas terminé) et s'il est lancé aux heures prévues.

C'est donc au script de vérifier s'il doit s’exécuter au moment de son lancement et donc de gérer sa propre sécurité.

S'il est lancé par inadvertance ou par un tiers ne devrait pas poser de problème.

De mon côte mes scripts cron sont intégrés à mes composants, c'est bien plus sûr (car dans l'espace réservé à ton composant).
A mon avis les tâches de type "cli" sont à réserver aux traitements spécifiques et exceptionnels (mais c'est mon point de vue).
De plus tout le framework est chargé, tu n'as pas besoin de gérer ceci.

J'utilise la variable "task" gérée par le Framework de Joomla pour leur lancement.
Voir cette discussion : https://forum.joomla.fr/forum/joomla...05#post2014305


Bon dev.

[lefabdu51]

un conseil, si tu utilise des classes spécifique pense à importer les librairires correspondantes .
Et n'oublies pas d'inclure un jexec or die, qui permet de verifier qu on est dans une session joomla.

ta fonction doit commencer par ceci :

class MaFonctionQuiVaBien extends JApplicationCli
{
/** on verifies que l'on est dans une session Joomla
const _JEXEC = 1;

// Load system defines
if (file_exists(dirname(__DIR__) . '/defines.php'))
{
require_once dirname(__DIR__) . '/defines.php';
}

if (!defined('_JDEFINES'))
{
define('JPATH_BASE', dirname(__DIR__));
require_once JPATH_BASE . '/includes/defines.php';
}
// cette ligne sert à définir les chemins vers le composants utilisés
// dans regardes dans le script du finder, tu as un exemple d'utilisation
//si tu n en a pas besoin tu peux oublier
define('JPATH_COMPONENT_ADMINISTRATOR', JPATH_ADMINISTRATOR . '/components/com_finder');
//Ces lignes sont standard
// Get the framework.
require_once JPATH_LIBRARIES . '/import.legacy.php';

// Bootstrap the CMS libraries.
require_once JPATH_LIBRARIES . '/cms.php';
// l'import de la configuration si tu as besoin de paramètres de config dans ton script
//si ce n est pas le cas, tu peux oublier
// Import the configuration.
require_once JPATH_CONFIGURATION . '/configuration.php';

// la configuration dans une variable, ce qui simplifies l'appel.
//Si aucun besoin, tu peux oublier
$config = new JConfig;
define('JDEBUG', $config->debug);

// La fonction qui contiens ton code
public function doExecute()
{
// Import des librairies dont tu as besoin(celles ci dessous concernent la gestion des fichiers et dossiers)
jimport('joomla.filesystem.file');
jimport('joomla.filesystem.folder');

//le code de ta fonction
}
//et ensuite on l'éxécute à la fin du script
JApplicationCli::getInstance('MaFonctionQuiVaBien')->execute();

Le nom de ton script doit etre MaFonctionQuiVaBien.php et il doit être dans le dossier cli de ton site. Tu ne peux le mettre en dehors car il faudrais que tu importe utilise le framework (jplateform) pour etre dans une session Joomla.
Le dossier cli est inaccessible via une url direct, il me sembles.
Si cela peux t aider.
Le tout est de bien situer les imports nécessaires. Après c'est simple si tu sait ce que tu veux.
Le principe de base: observe, l'existant, inspire toi en , et teste .....

[lefabdu51]

@roland d'alsace:
si tu les met dans un composant, c'est que tu attend une ou plusieurs actions de l'utilisateur. Conclusion, ce ne sont pas des taches cron.
Par définition, les scripts lancés par une tache cron sont entièrement automatisés, donc ils ne nécessitent aucune intervention humaine et aucun besoin d'accéder à l'interface graphique (comprendre partie visiteur ou admin du site). Tu ne peux lancer une tache qui nécessite une action d'un utilisateur via cron, car si celui ci pour une raison x ou y n'agit pas, ton script bloque et représente un risque.

[roland_d_alsace]

@roland d'alsace:
si tu les met dans un composant, c'est que tu attend une ou plusieurs actions de l'utilisateur. Conclusion, ce ne sont pas des taches cron.
Par définition, les scripts lancés par une tache cron sont entièrement automatisés, donc ils ne nécessitent aucune intervention humaine et aucun besoin d'accéder à l'interface graphique (comprendre partie visiteur ou admin du site). Tu ne peux lancer une tache qui nécessite une action d'un utilisateur via cron, car si celui ci pour une raison x ou y n'agit pas, ton script bloque et représente un risque.

En toute amitié, je trouve que tu as une vue un peu "réduite" d'un composant.

Bien sûr qu'une tâche cron ne peut pas avoir d'interaction avec l'utilisateur (voir mon code ci-dessus), mais "normalement" elles font bien partie d'un composant.

J'ai juste dit que je plaçais les paramètres des actions de ma tâche cron (unique pour plusieurs actions) dans les paramètres du composant (jours et heures de lancement de chaque action, historique de lancement, fractionnement des actions, etc...).
(Fractionnement car une tâche cron est aussi faite pour des lancements lourds, qui peuvent atteindre les limites mémoire ou timeout serveur...).
C'est bien plus facile à configurer ainsi pour un admin lambda.

C'est aussi normal que ces tâches utilisent des model et des helpers du composant en questions.
...et les affichages utilisateur (les "enqueumessage") je les récupère pour les envoyer par mail ou les enregistrer dans un journal, quand je suis en mode "cron"

Sinon j'ai d'autres arguments :

• en général les actions faites par ces tâches, moi je les autorise souvent en lancement individuel et manuel dans l'interface d'admin (par exemple synchro avec des webservices, calcul de géoposition, etc....), jutilise donc les mêmes helpers, model ou librairies.
• c'est bien plus facile de factoriser le code si tout est dans le composant, plutôt que de faire de JLoader à la pelle.
• je préfère les livrer dans les dossiers du composant, plutôt que dans un dossier "commun" à Joomla, c'est bien plus "secure".

Regarde les taches automatiques du côté d'Acymailing, de Kunena, etc...
Je n'ai rien inventé.

Mais comme dit c'est ma vision de la chose, pour moi le cli c'est juste pour des "moulinettes" occasionnelles, quand on a un problème particulier, par pour de l'admin régulière.
En informatique il y a toujours plusieurs chemins pour arriver à un résultat.
En mode cli tu peux tout faire aussi, charger des models ou des helpers de différents composants, charger ou écrire des paramètres, etc...

Bon dev.

[lefabdu51]

en lancement individuel et manuel dans l'interface d'admin ... donc ce ne sont pas des taches cron.
Les tâches cron se lancent via la cli et non via le web.
Ce sont des scripts automatisés. C'est la même approche dans la conception, mais pas dans l'utilisation.
De plus, avec Joomla, dans une tâche cron, tu utilise la notion d'objet ($this) mais pas la notion d'évenement, ce qui est normal car une tache cron est avant tout une procédure. La notion d'événement est remplacée par la notion de temporalité (execution à intervalle de temps donné).
Les scripts shell linux sont un bon exemple de tâches cron pour la plupart.

dans le script: update_cron.php
/**
* This is a CRON script which should be called from the command-line, not the
* web. For example something like:
* /usr/bin/php /path/to/site/cli/update_cron.php

Les taches acymailing et autres dont tu me parles sont dans le composant et sont lancées par le premier visiteur qui passe après la date et l heure fixée pour le lancement. Tu peux avoir des délais entre l heure effective et l'heure de lancement programmée. Ce mécanisme est la pour permettre d'émuler cron sur des serveurs ou les utilisateurs ne peuvent implémenter ce genre de tâche (80% des serveurs mutualisés).

Désolé, mais c est mon coté admin réseaux qui ressort.
De plus, je suis bien d accord avec toi,l'informatique est un des rares métiers ou plusieurs voies sont possible pour arriver au même résultat.

[Visiteur]

Grand merci à vous tous sur ce sujet de CRON.

Je viens de refondre mon script php logé désormais dans le dossier "cli", et mis à jour la tâche cron dans mon Cpanel.

nb: j'attends la nuit prochaine pour voir les résultats du prochain traitement nocturne, avant de passer mon post initial en "Résolu".

Pour répondre à Roland, l'objet du script est bien une action de maintenance quotidienne sur ma BDD : ajout chaque nuit des créneaux horaires d'un nouveau jour + effacement du jour le plus ancien.

[roland_d_alsace]

Salut lefabdu.

en lancement individuel et manuel dans l'interface d'admin ... donc ce ne sont pas des taches cron.

Non, ce n'est pas ce que j'ai dis, j'ai dis que mes méthodes sont factorisées, et sont utilisée par mes tâches automatiques et par des tâches manuelles.

Ce sont des actions spécifiques qui peuvent être lancées manuellement, si l'on ne peut pas attendre l’exécution nocturne de la tâche automatique.

Le besoin est quand même assez fréquent qu'un administrateur ne puisse pas attendre l’exécution du cron et qu'il doit demander un lancement forcé à un moment précis (cas des synchronisation entre serveurs suite à un correctif urgent par exemple).
En tous cas à mon avis le développeur doit toujours prévoir un lancement manuel, cela reste une bouée de sauvetage qui sera utile un jour (+ de 40ans expérience qui ressortent là...).

Les tâches cron se lancent via la cli et non via le web.

Et pourquoi pas, c'est nouveau ça ?
Tu peux lancer par un cron externe une URL qui lancera un script PHP, cela ne pose aucun problème.

De plus, avec Joomla, dans une tâche cron, tu utilise la notion d'objet ($this) mais pas la notion d’événement, ce qui est normal car une tache cron est avant tout une procédure. La notion d'événement est remplacée par la notion de temporalité (execution à intervalle de temps donné).

Je ne comprend pas ce que tu veux dire... quel rapport entre la notion d'objet et la notion d’évènement ?

Les scripts shell linux sont un bon exemple de tâches cron pour la plupart.

Oui bien sur, le plupart des mes tâches cron, sont sous Shell Linux (bash), surtout pour la synchronisation nocturne des mes serveurs et mes sauvegardes (je n'ai que des serveurs dédiés).

Les taches acymailing et autres dont tu me parles sont dans le composant et sont lancées par le premier visiteur qui passe après la date et l heure fixée pour le lancement. Tu peux avoir des délais entre l heure effective et l'heure de lancement programmée. Ce mécanisme est la pour permettre d'émuler cron sur des serveurs ou les utilisateurs ne peuvent implémenter ce genre de tâche (80% des serveurs mutualisés).

Attention, il y a les 2 formules, celle-ci étant celle qui ne faudrait pas utiliser, mais qui est la plus facile à mettre en oeuvre pour un non informaticien !

Acymailing, Acysms, Hikashop, Prestashop, etc... ont tous des scripts que tu lances par un CRON (linux ou autre) par appel d'une URL (commande wget).
Tous mes acymailing fonctionnent ainsi, c'est beaucoup plus sûr et efficace.

Quand tu as des gros volumes impossible de faire autrement que d'utiliser un CRON, car il est impossible d'attendre qu'un hypothétique visiteur nocturne lance un script qui n’enverra que 50 ou 100 messages sur les quelques milliers à traiter....
C'est d’ailleurs vivement conseillé de passer par un CRON.
Acyba proposant même de lancer le script par un CRON hébergé chez eux et qui lancera l'URL (et Adrien se sert bien d'un contrôleur de son composant dans la partie frontale, pour faire cela voir...).
Ce type de cron est lancé toutes les 5mn environ, et c'est ensuite le script qui décide ce qu'il a à faire.

C'est ce que j'ai essayé d'expliquer dans me posts précédent en parlant de configuration du CRON dans les paramètres de configuration de mes composants.

L'url est lancée toutes les 5mn par un CRON quelconque et ensuite selon les paramètres que l'administrateur à fixé le script exécutera diverses routine ou non, ceci après que ce script ait vérifié qu'il n'y a pas déjà une autre instance de lui même qui s’exécute encore.
Par exemple dans le cas d'un site d'une ligue sportive l'admin aura décidé que :

• les agendas des compétitions doivent être synchronisés avec les serveurs centraux de la fédération tous les mercredi et vendredi à 23h30
• les titres fédéraux, les officiels et les clubs doivent être synchronisés toutes les nuits à 3h
• les marqueurs des cartes doivent être calculé tous les...
• etc....

Petite question par curiosité, pour le déploiement de tes composants, comment déposes-tu tes fichiers dans le dossier cli par l'installateur de Joomla ?
Sauf si j'ai raté un truc, à priori ce n'est pas prévu, non ?
Je pense que le core-team aurait prévu un système avec un dossier par extension, comme pour les librairies par exemple. C'est ce qui me fait dire que c'est plutôt réservé pour les "moulinettes" occasionnelles.

Donc je persiste à dire que la place d'un script tiers n'est pas dans un dossier du framework (donc pas dans le dossier /cli) au risque de se le faire "bouffer un jour" si le Joomla team décide de supprimer ce dossier lors d'une maj p.e..
C'est mon avis.

Bon dev.

[lefabdu51]

pourquoi une tache cron ne se lance que via la cli ?
C'est simple, CRON est un service, donc si tu peux activer le service cron depuis le web sur un serveur, c est que le serveur a un gros soucis.
cron est un programme qui n as rien a voir avec PHP et le web. Il est présent sous tous les systemes linux et unix.
de plus pour preparer le lancement de ta tache cron, la commande est crontab -e. Et apres, c est le service crond qui se debrouille tout seul pour faire ce qu il y a dans sa table.
La seule option que je vois pour executer cette commande via php est de passer par shellexec(), exec(), ou passthru().
CRON existait avant le web....

https://fr.wikipedia.org/wiki/Cron

de plus une commande telle que php /chemin vers la cli/cli/monscript.php est une commande shell et pas autre chose. Tout comme la commande wget (monurlquifaittout.php).

Si tu met oncontentprepare dans ta tache cron, est tu sur que cela en est une ? Pour moi non, car ce n'est qu une procédure... c est ce que je voulais dire.

De ce que j en comprends la ou je lance PHP pour un script situé dans la CLI, toi tu lance wget sur une url. Chacun ses choix en fait.
Mais CRON reste CRON soit un service rendu par un serveur linux, tout comme wget est une commande linux.

quand au lancement manuel: ssh est ton ami.

[roland_d_alsace]

pourquoi une tache cron ne se lance que via la cli ?
C'est simple, CRON est un service, donc si tu peux activer le service cron depuis le web sur un serveur, c est que le serveur a un gros soucis.
cron est un programme qui n as rien a voir avec PHP et le web. Il est présent sous tous les systemes linux et unix.
de plus pour preparer le lancement de ta tache cron, la commande est crontab -e. Et apres, c est le service crond qui se debrouille tout seul pour faire ce qu il y a dans sa table.
La seule option que je vois pour executer cette commande via php est de passer par shellexec(), exec(), ou passthru().
CRON existait avant le web....

https://fr.wikipedia.org/wiki/Cron

Je pense que l'on ne se comprend pas et ce que tu dis là ce sont un peu des généralités sur les fondamentaux.
Les commandes et la programmation shell jeconnais et ceci bien avant Linux sous Unix (j'administre de serveurs depuis près de 40 ans, ).
J'ai demarré sur des PDP 7 et 8 en 1977... pour piloter les trains de bloom et les fours dans les fonderies industrielles.

de plus une commande telle que php /chemin vers la cli/cli/monscript.php est une commande shell et pas autre chose. Tout comme la commande wget (monurlquifaittout.php).

ben justement wget te permet bien de lancer une url. Tout le monde n'a pas accès à crontab, mais tout le monde à accès à de nombreux service web qui peuvent lancer un URL.

Je te donne un autre exemple, vu que tous mes précédents exemples de développeurs pourtant reconnu dans le monde Joomla et qui font ainsi ne te suffisent pas.
Geraint aussi fait de même dans son composant Jevents et donne une liste de services web pour le faire voir cet article...

Si tu met oncontentprepare dans ta tache cron, est tu sur que cela en est une ? Pour moi non, car ce n'est qu une procédure... c est ce que je voulais dire.

C'est dans un plugin, mais peu importe.
Normalement tu n'utilises pas les mêmes helpers que ceux destiné à l'affichage, on parle de tâche batch là, à chaque développeur de maitriser son code et de bien séparer les fonctionnalités.
Il y a de nombreux exemples de ce type, sans parler spécifiquement de tâche automatiques comme des choses que l'on peut lancer en admin et pas en front ou vice versa.
De +, et si vraiment il le fallait, il y a des formules pour détecter dans un script s'il est lancé via un navigateur ou pas.

De ce que j en comprends la ou je lance PHP pour un script situé dans la CLI, toi tu lance wget sur une url. Chacun ses choix en fait.

Non mes scripts ne sont pas dans le dossier cli, comme je le dis dans mes précédents messages, car ce n'est pas leur place et de surcroit tu n'y as pas accès dans l'installateur pur les déposer.
Ils sont dans la partie site des mes composants.

Mais CRON reste CRON soit un service rendu par un serveur linux, tout comme wget est une commande linux.

Off course, difficile de ne pas être d'accord (au moins on l'est sur un point )

quand au lancement manuel: ssh est ton ami.

ssh n'est que le protocole lancé par la commande du même nom, c'est telnet qui est est le "vrai ami" et qui permet d’accéder à la console à travers ssh.

Si tes clients ont tous un accès via putty ou autre, et qu'ils ne te font jamais de conneries je dis bravo, c'est que tu les a bien formés (et qu'ils sont volontaires, car il faut trouver des gens qui veulent encore travailler en 2020 en mode commande) !
Mais je trouve qu'un développeur ne devrait plus imposer ceci à un exploitant. Du temps d'UNIX et des traitements batch oui, mais plus aujourd'hui.

Dans ma logique, je donne l'accès aux mêmes fonctions que celles qui se lancent via cron dans la partie admin de Joomla onglet "outils", au moins là je peux maitriser les lancements manuels.
Car comme je l'ai déjà dit, j'ai trop souvent eu le cas où il fallait lancer manuellement une tâche de nuit dans l'urgence.

Mais c'est une façon de voir les choses que de donner ou pas l'accès aux fonctions à l'administrateur (et sous contrôle des ACL bien sûr).

Bon dev.