TOC

WordPress affiche 404 après la mise à jour du message?

image

Ce bug m’ennuie très longtemps. Dans WordPress, après la mise à jour ou l’enregistrement d’un nouveau message ou d’un message existant, il est parfois procédé à une redirection vers une page 404, ce qui se produit de manière aléatoire. Aucune idée d’identifier la cause de la racine.

Après avoir lu quelques articles similaires - this et http://wordpress.org/support/topic/clicking-update -page-results-in-a-404[this], je découvre que cela est dû au filtrage mod__security installé sur Apache - Si un message contient certaines" combinaisons de mots "dangereuses prédéfinies, telles que" exec "ou" SQL injecter des commandes »comme« insérer », la publication sera filtrée et WordPress retournera simplement une page 404.

Voici ma solution:

1. Mod__security désactivé

Beaucoup suggèrent de désactiver le module mod__security en mettant les règles suivantes dans` .htaccess`. 

#...
<IfModule mod__security.c>
SecFilterEngine Off
SecFilterPost Off
</IfModule>

<IfModule mod__env.c>
SetEnv MODSEC__ENABLE Off
PassEnv MODSEC__ENABLE
</IfModule>
#...

Malheureusement, la solution ci-dessus ne fonctionne pas pour moi. En fouillant dans httpd.conf , découvrez que mon Apache utilise le dernier` mod__secuirty2`, puis j’essaie à nouveau de suivre la règle: 

#...
<IfModule mod__sec2.c>
SecFilterEngine Off
SecFilterPost Off
</IfModule>
#...

Mais, ne travaille pas non plus. Tu peux tenter ta chance :)

2. Contourner les règles mod__security

Après Google, découvrez que «mod__security 2`» ne prend plus en charge les substitutions .htaccess , vous devez contourner ces règles manuellement via le fichier de configuration.

Pour le résoudre, recherchez ‘ /usr/local/apache/conf/modsec2/exclude.conf et ajoutez le contenu ci-dessous au début du fichier.

/usr/local/apache/conf/modsec2/exclude.conf 

<locationmatch "/wp-admin/post.php">
SecRuleRemoveById 300013
SecRuleRemoveById 300015
SecRuleRemoveById 300016
SecRuleRemoveById 300017
</locationmatch>

WordPress utilise /wp-admin/post.php pour mettre à jour le message. Désormais,` mod__security` contournera les règles - 300013, 300015, 300016, 300017.

Redémarrez le serveur Apache. Mettez de nouveau à jour l’ancien post-problème, il est maintenant mis à jour avec succès, plus aucune redirection vers la page 404, cela fonctionne!

3. Quel ID de règle filtrer?

Attendez, comment savons-nous quelles règles filtrer? Vous pouvez trouver cette information dans modsec__audit.log - Toutes les URL filtrées ou interceptées seront enregistrées dans ce fichier.

/usr/local/apache/logs/modsec__audit.log 

# your problem-post URL here...

--2950df1e-H--

Message: Accès refusé avec le code 500 (phase 2). Correspondance de modèle "((sélectionnez | accordez | supprimez | insérez | déposez | modifier | remplacer | tronquer | mettre à jour | créer | renommer | décrire)
\ **  | | \\,][[: espace:]](de | dans | table | base | index | vue)[[: espace:]][A-Z | a-z | 0-9 | \\ **  | | \\,]| UNION SELECT. **  \\ '. **  \\'. ** ,[0-9]. **  INTO. **  FROM) "dans REQUEST__BODY.

[file "/usr/local/apache/conf/modsec2.user.conf"][line "345"][id "300013"][rev "1"]

[msg "Generic SQL injection protection"][severity "CRITICAL"]

Action: intercepté (phase 2)

# ...

Filter by URL or your IP, to identify which rules are triggered when you update the post. In the above case, the post’s URL hits rule “ 300013 “, and you need to bypass this rule id in order to update the post.

  • Note**
    Check your http.conf , mod__security logs may have logged the error messages to somewhere else, do consult your hosting provider for detail.

References

  1. http://www.modsecurity.org/blog/archives/2007/12/using transacti.html[Using Transactional Variables Instead of SecRuleRemoveById]. 404 error after editing update post . Clicking update page result in a 404 . WordPress error 404 when publishing or saving post . WordPress mod security 2 . Weird 500 internal server error on WordPress resolved 404 mod__security wordpress

Related