quel choix faites-vous pour bloquer code malveillant

[herve]

Bonjour
Quel choix faites-vous pour bloquer code malveillant: éditeur tiny ou configuration j!/filtres de texte

J'ai vu passer une mention qq part du dev' d'akeeba qui n'aimerait pas (il est souvent très ... affirmatif!) utiliser le blocage dans le paramétrage général de joomla (configuration globale>filre de texte)
J’utilise maintenant de préférence le blocage via la configuration de tiny, qui a en plus le mérite de gérer les rôles ACL
Que conseillez-vous ? peut-être indépendant d'autres extensions ?

[daneel]

voila un exemple à titre professionnel ( dans le cadre d'une prestation ) :

- Un gestion du http header, le hsts et une politique de sécurité (CSP).

- Tous les formulaires génèrent dynamiquement un jeton qui est vérifié par le script php afin de déterminer si c'est bien le formulaire qui envoie les données et pas un script externe. Tous les générateurs de formulaire devraient comporter un jeton surtout si l'envoi se fait en ajax (ce qui permet de ne pas changer de page).

- Le pot de miel et un captcha utilisant les mêmes techniques que friendly capcha ou friendly captcha directement : https://friendlycaptcha.com/demo ! RGPD Oblige, on doit s'assurer que les serveurs sont en Europe et que la politique de confidentialité du capcha soit conforme.

- Des règles définies dans le htaccess entre sécurité, optimisation et performance

- Une vérification dans les bases antispam permet de bloquer les ip avant d'arriver sur le site.

- Des mesures de sécurité dans les serveurs et accessibles depuis le cpanel (firewall et autres).

- La version gratuite de Cloudflare complète le blocage en proposant un challenge en cas de doute et autres petits réglages précis.

- une page statut hébergée sur un autre serveur qui informe les visiteurs du fonctionnement de mes sites.

- Un rapport est généré régulièrement afin d'évaluer le niveau de sécurité, la performance.

- Des notifications sont envoyés en cas d'attaque pour réagir rapidement. Pour cela, j'utilise un script local intégrant divers api dont clouflare. Je peux passer en mode "je suis attaqué" afin de filtrer par challenge dans le cas d'un deni de service.

- Les membres enregistrés pourront utiliser l'authentification multifacteur de la 4.2 pour éviter les captcha et autres contrôles.


A ton niveau et gratuitement, tu peux utiliser facilement cloudflare, l'antispam et les règles de htaccess, choisir le bon gestionnaire de formulaire et un hébergeur proposant des mesures de sécurité, La page statut peut être réalisé gratuitement. Le http header peut être configuré facilement au minima avec le plugin natif de joomla.

En fait, quand tu utilise des outils qui contrôle avant que ton site soit affiché comme cloudflare ou ton hébergeur, tu evite d'utiliser tes ressources inutilement.

De préférence, si tu peux ajouter également quelques règles au niveau du htaccess, c'est mieux que d'offrir accès aux pages aux scripts malveillants.

Par exemple, si le script malveillant cherche un wp-admin sur un site joomla, tu peux déjà le blacklister pendant une période ou définitivement. En htaccess, tu donne la condition si l'url se termine par le segment /wp-* alors rediriger sur un autre site (par exemple google.com). N'hésite pas à consulter les logs, tu serais surpris du nombre de tentatives et de la différence avant et après !

Evidemment, la logique serait de protéger prioritairement l'admin de joomla par une clé dans l'url ou un htpasswd. C'est à dire que d'ajouter administrator à l'adresse de ton site ne devrait pas afficher l'administration joomla mais simplement une erreur.

Voilà !

[Colnem30]

Evidemment, la logique serait de protéger prioritairement l'admin de joomla par une clé dans l'url ou un htpasswd. C'est à dire que d'ajouter administrator à l'adresse de ton site ne devrait pas afficher l'administration joomla mais simplement une erreur.

Bonjour daneel

Pour ajouter une clef dans l'url, suffit-il de modifier le nom du dossier administrator? Si oui, peut-on le faire sur un site en ligne?

Merci

[daneel]

Bonjour daneel

Pour ajouter une clef dans l'url, suffit-il de modifier le nom du dossier administrator? Si oui, peut-on le faire sur un site en ligne?

Merci

Il ne faut jamais faire cela. En réalité, c'est une affaire de redirection.

la personne qui tape l'adresse de l'administration de ton site sans la clé :
nomdetonsite.com/administrator
sera redirigé sur l'url ou le message d'erreur que tu aura défini.

Si tu utilise un plugin, ton url se présentation sous la forme
nomdetonsite.com/administrator/?variable=xxxxx

Les plugins disponibles librement et gratuitement sous joomla 4 sont : "asm no admin" ou "go to admin"

https://extensions.joomla.org/extension/asm-no-admin/

https://extensions.joomla.org/extension/gotoadmin/

Après tu as la solution d'admintools d'akeeba mais j'avoue que je ne l'utilise pas.

Perso, je préfère la solution du htaccess + cookie dans le repertoire administrator, ce qui evite la requête en base mysql pour récupérer la valeur.
et de devoir supprimer le plugin, et intervenir dans la base via phpmyadmin en cas d'oubli du code.

Pour cette méthode sans plugin :

Vérifiez préalablement que vous avez activé la réécriture et renommer le htaccess.txt en .htaccess

1. Créer un repertoire à la racine du site que vous nommerez sans accent ni espace ou caractère spéciaux et en minuscule
2. Editer un fichier via notepad++ que vous nommerez par exemple index.php ou le nom de votre choix suivi de .php
et coller le code suivant :

<?php
if ( setcookie ( 'allowAdminAccess' , 'valeurCookie' , time ( ) + 60 * 60 * 1 , '/' ) ) {
header ( 'Location: /administrator' ) ;
} else {
echo 'Erreur lors de l\'enregistrement du cookie' ;
}
?>

Attention à ne pas faire d'espace avant le code puis sauvegarder et transférer dans le repertoire créé.
Remplacer valeurCookie par la valeur de votre choix (il peut être compliqué car il ne sera pas saisie mais stocké dans le cookie)

3. Créer un fichier contenant le code suivant

RewriteCond %{REQUEST_URI} ^/administrator
RewriteCond %{HTTP_COOKIE} !allowAdminAccess=valeurCookie
RewriteRule .* - [L,F]

Sauvegarder sous le nom .htaccess et transférer dans le repertoire administrator
( à ne pas confondre avec celui à la racine mais bien dans le repertoire administrator)
N'oubliez pas de remplacer valeurCookie par la valeur que vous avez défini précédemment

Voilà !

4. Quand on essaye de se connecter directement dans administrator; un message d'erreur 403 Forbidden s'affiche
et si vous saisissez le nom de votre site suivi du repertoire, le cookie va s'installer dans votre navigateur et vous serez redirigé dans le repertoire administrator et la page de connexion est visible.

Je préfère cette méthode au plugin car je peux agir en cas d'oubli sans intervenir sur la base, il n'y a pas non plus de saisie d'un login/password via un htpasswd ( ce qui est compliqué sur un smartphone) vu que le formulaire du htpasswd n'est pas personnalisé avec le template et n'est pas responsive. C'est un peu difficile à faire pour les débutants mais pas tant que ça si on prend le temps de lire.

Le système de cookie est toujours en vigueur donc je continue de cette façon, en cas de changement, j'opterai certainement pour un stockage similaire dans le localstorage du navigateur.

[herve]

Bonjour
daneel
Encore merci à cette longue réponse même si je ne pense que c'est répondu à ma question plus limitée.
Bon j'aurai d'autre question à poser mais j'attendrai ta dispo sur cette question d’outils https://forum.joomla.fr/forum/joomla...93#post2041993 à mettre en place sur un site
Je regarderai plus précisément point par point cette sécurisation à ce me moment :-)

[daneel]

Bonjour
daneel
Encore merci à cette longue réponse même si je ne pense que c'est répondu à ma question plus limitée.
Bon j'aurai d'autre question à poser mais j'attendrai ta dispo sur cette question d’outils https://forum.joomla.fr/forum/joomla...93#post2041993 à mettre en place sur un site
Je regarderai plus précisément point par point cette sécurisation à ce me moment :-)

oui tu as parfaitement raison, comme je suis un peu sur tous les fronts, ce n'est pas évident. Merci.



La réponse complémentaire était surtout pour Colnem30 à propos de la protection du repertoire administrator.
On ne touche pas aux dossiers et aux fichiers core, on protège en filtrant les accès et en effectuant des redirections.
Le mieux étant de cacher le fait que ce soit un site joomla, ce qui est parfaitement possible sans aucune modification.

Pour ce qui est de ma réponse principale, je considère qu'il faut avoir une méthodologie pour protéger contre l'injection de code à travers les urls mais également dans tous les formulaires, y compris les formulaires de connexion (front & back), de recherche et de création de compte. Je n'ai pas évoqué également les API car je travaille la-dessus.

[Colnem30]

Colnem30 remercie baucoup daneel

Je pense avoir compris le principe. Je vais le tester. Je suppose qu'en cas d'erreur, il suffit de supprimer le .htaccess du répertoire administrator...

[Colnem30]

Bonjour daneel

Tout ceci fonctionne parfaitement. Merci à toi.
Avec les valeurs de ton exemple, si j'ai bien compris, le cookie dure une heure.
Si on met 0, ai-je lu, il expire à la fin de la session. Pas mal non plus, non?