Une erreur interdite 403 se produit le plus souvent lorsque nos systèmes de sécurité protègent votre site. Bien plus souvent qu'autrement, notre pare-feu d'application Web (appelé Mod Security ou modsec) protège votre site Web contre les tentatives de piratage automatisées.
Cependant, dans certains cas, des actions légitimes peuvent être identifiées à tort comme une attaque et votre action sera bloquée. C'est ce qu'on appelle un faux positif. Voici quelques scénarios courants lorsque cela se produit :
- En utilisant n'importe quel créateur de site Web, il se peut qu'il ne parvienne pas à enregistrer vos modifications
- Si vous utilisez le thème/constructeur Divi pour WordPress, il indiquera quelque chose comme "Erreur lors de l'enregistrement de la page" puis fournira une liste des causes potentielles.
- Lorsque vous ajoutez du code javascript ou PHP via le panneau d'administration de votre site Web (et non le gestionnaire de fichiers Plesk ou FTP).
Si vous obtenez une erreur interdite 403 qui ne correspond pas à l'une des actions ci-dessus, vous pouvez d'abord consulter notre guide général de dépannage des erreurs 403.
Cela peut arriver apparemment à l'improviste parce que nos règles de pare-feu sont mises à jour chaque semaine ; ajoutant potentiellement de nouvelles règles chaque semaine qui pourraient affecter le fonctionnement de votre site. Notez que les règles sont plus susceptibles d'affecter l'envoi données au serveur, comme lors de la soumission d'un formulaire ou de la mise à jour des données dans le backend de votre site.
Comment rechercher et interpréter les journaux de pare-feu
La première étape consiste à vérifier les journaux du serveur pour savoir pourquoi il fournit une telle erreur. Consultez notre guide sur l'utilisation du gestionnaire de fichiers Plesk pour analyser les journaux de votre site Web.
Étant donné que notre pare-feu d'application Web aide à bloquer les attaques courantes, vous pouvez voir de nombreuses entrées ModSecurity dans le journal . Il est important d'identifier les entrées de journal directement correspondent à l'action que vous entreprenez, sinon vous finirez à la fois par affaiblir le pare-feu et par ne pas résoudre le problème en même temps.
Les erreurs liées au pare-feu ressembleront à ceci :
ModSecurity: Access denied with code 403 (phase 2).
Pattern match "(asfunction|data|javascript|livescript|mocha|vbscript):" at ARGS:input_5_7_data_canvas.
[file "/etc/httpd/conf/modsecurity.d/rules/comodo/07_XSS_XSS.conf"] [line "227"]
[id "212770"] [rev "4"]
[msg "COMODO WAF: XSS Attack Detected||customerdomain.tld|F|2"]
[data "Matched Data: data: found within ARGS:input_5_7_data_canvas: data:image/png;base64,{{{{snipped}}}}]
[severity "CRITICAL"] [hostname "customerdomain.tld"]
[uri "/specific_uri_requested/"] Notre exemple d'entrée de journal ci-dessus est un faux positif qui s'est produit lors de la soumission d'un formulaire Gravity Forms avec une image jointe.
Nous avons supprimé un tas de charabia et l'avons remplacé par {{{{snipped}}}} pour le rendre un peu plus lisible. Nous avons également mis certaines parties en gras pour indiquer ce qui nous intéresse le plus.
En lisant les sections en gras dans l'ordre, cette erreur indique que le pare-feu a trouvé :
- L'accès a été refusé avec une erreur interdite (code 403 ) (Remarque :si vous ne voyez pas 'code 403' ou 'Accès refusé', alors l'entrée de journal ModSecurity que vous consultez n'est pas pertinente :passez à la suivante. Certaines entrées sont destinées au débogage ou à des informations générales, pas tous sont pour le blocage.)
- Un type de script (javascript, livescript , etc.)
- Utilisation de l'ID de règle 212770
- Qu'il a considéré une attaque XSS (Script intersite)
- Lorsqu'il soumettait une image au format encodé en base64 (data:image/png;base64 )
- Avec la gravité "CRITIQUE" (Notez que si vous voyez une gravité de DEBUG ou WARNING, ceux-ci ne sont probablement pas responsables d'une erreur 403 visible)
- Sur l'URI /specific_uri_requested/
Le pare-feu devient assez nerveux à ce sujet ! Compréhensible :c'est un script aléatoire avec des données bizarres…
Étant donné que nous savons que le problème se produit lorsqu'un utilisateur légitime soumet un formulaire Gravity, et qu'il y a effectivement une image impliquée, il s'agit probablement d'un cas d'utilisation légitime et donc l'erreur est un faux positif.
Veuillez ouvrir un ticket si vous avez besoin d'aide pour interpréter ! Assurez-vous d'inclure l'entrée de journal afin que nous puissions l'analyser rapidement pour vous.
Vous trouverez ci-dessous deux façons de contourner ces erreurs :1) désactiver le pare-feu (recommandé uniquement dans certains cas) et 2) exclure la ou les règles particulières qui génèrent le faux positif.
Solution 1 (temporaire) :En développement ? Désactiver le pare-feu
Si vous développez actuellement le site, il est préférable de simplement désactiver complètement le pare-feu, car vous risquez de rencontrer un certain nombre d'obstacles lors de la soumission de code au serveur via HTTP (c'est-à-dire :enregistrement d'un changement CSS) dans WordPress.
N'oubliez pas de réactiver le pare-feu lorsque vous avez terminé de modifier le site, sinon votre site ne sera pas protégé contre un grand nombre d'attaques courantes.
Voici comment le désactiver :
- Dans Plesk, revenez à « Sites Web et domaines » ou « Domaines » et cliquez sur le domaine.
- Cliquez sur "Pare-feu d'application Web".
- Sous "Mode pare-feu d'application Web", choisissez "Désactivé".
Remarque :si vous choisissez "Détection uniquement", notre pare-feu de niveau TCP récupèrera toujours les entrées du journal et instituera des interdictions temporaires. Off est préférable pendant le développement. - Cliquez sur OK ou Appliquer pour enregistrer.
Une fois le développement terminé, réactivez le pare-feu en suivant les mêmes étapes, mais en choisissant "Activé" plutôt que "Désactivé".
Solution 2 (permanente) :Exclure les règles ModSec
Si les utilisateurs de votre site effectuent régulièrement la même action que vous qui a déclenché le 403, alors désactiver complètement le pare-feu ne suffira pas !
Au lieu de cela, continuons et excluons cette règle du pare-feu pour le domaine. Dans notre exemple ci-dessus, nous avons identifié la règle de sécurité ID 212770, mais la vôtre sera sûrement différente. Parcourez l'entrée du journal jusqu'à ce que vous trouviez l'ID, il ressemblera à ceci :[id "212770"] alors…
- Dans Plesk, revenez à "Sites Web et Domaines"
- Cliquez sur "Pare-feu d'application Web".
- Sous "Désactiver les règles de sécurité", saisissez le numéro d'identification que vous avez trouvé dans le journal (généralement un par ligne, si vous en avez plusieurs).
- Cliquez sur OK ou Appliquer pour enregistrer.
Essayez maintenant de faire l'action qui a causé le problème auparavant.
Si le problème n'est PAS résolu et que vous obtenez toujours une erreur 403, il est probable que l'action en ait déclenché plusieurs règles de pare-feu. Répétez le processus ci-dessus jusqu'à ce que vous ayez trouvé et exclu tous les ID de règle posant problème. Notez que s'il existe plusieurs ID de règle à l'origine de cette erreur, ils sont susceptibles d'être très similaires, regardez donc très attentivement lorsque vous vérifiez les dernières entrées de journal pour vous assurer que celles que vous voyez sont légèrement différentes de celles que vous avez déjà exclues.
Le maximum que nous ayons dû exclure en une seule séance est de 5, il y a donc de fortes chances que vous régliez ce problème en seulement 2 ou 3 exclusions.
Dépannage
Si vous excluez un ensemble de règles, vous obtenez une erreur comme celle-ci qui n'a pas d'ID associé :
ModSecurity: Output filter: Response body too large (over limit of 524288, total not specified).
Cela signifie que vous devrez augmenter ces limites. Si vous avez un accès administrateur à Plesk, vous pouvez insérer ce qui suit sous Outils &Paramètres> ModSecurity> onglet Paramètres> Directives personnalisées :
SecResponseBodyLimit 546870912SecRequestBodyInMemoryLimit 546870912
Si vous n'avez pas d'accès administrateur à Plesk et que vous êtes hébergé chez nous, ouvrez un ticket et nous nous en occuperons pour vous !