Si un pirate a changé le blog_charset en UTF-7, est-ce que WordPress est vulnérable à de nouvelles attaques?

J'ai eu un client qui a été piraté récemment et j'ai remarqué que des personnages étranges apparaissaient sur son site, comme  et Æ. Il s'avère que les pirates ont changé le blog_charset en UTF-7 dans la wp_optionstable de la base de données. Je l'ai remis à UTF-8, mais je me demandais si pendant le temps qu'il était réglé à UTF-7, cela pouvait-il créer des failles de sécurité?

J'ai fait quelques recherches et j'ai découvert qu'il y avait une vulnérabilité dans WordPress UTF-7 qui a été corrigée dans la version 2.0.6 . Nous utilisons la version la plus récente de WordPress, donc ils n'auraient pas pu utiliser cet exploit, mais y a-t-il d'autres exploits liés à UTF-7? Vraiment, y a-t-il une raison pour que les pirates modifient le blog_charset autrement que d'être une douleur? J'ai essayé de déterminer comment ils sont entrés et je me demande si cela est lié d'une manière ou d'une autre.

<et >sont codés en +ADw-et +AD4-en UTF-7 . Imaginez maintenant ce qui suit:

1. Quelqu'un envoie un +ADw-script+AD4-alert(+ACI-Hello+ACI-)+ADw-/script+AD4-texte de commentaire. Il passera tous les sanitaires sans échappatoire.

2. La base de données attend et traite toutes les données entrantes comme UTF-8. Étant donné que tous les flux UTF-7 sont l' UTF-8, ce ne sera jamais le résultat valable dans une erreur SQL et mysql_real_escapeou htmlspecialcharsne toucher.

3. WordPress envoie un en-tête text/html;charset=utf-7.

4. WordPress affiche le commentaire, en attendant les données échappées. Mais comme cela est traité comme UTF-7 par le navigateur, le JavaScript sera exécuté.

Donc, oui, c'est un problème de sécurité.

UTF-7 n'est pas pris en charge par tous les navigateurs, la plupart afficheront le texte sous Windows-1252 (ou quel que soit le codage par défaut sur leur système d'exploitation) ou UTF-8. Le principal problème est que l'échappement ne fonctionnera plus.

Changer simplement la valeur d'encodage n'est pas une solution. Un visiteur régulier ne peut jamais le changer, vous devez donc trouver la porte ouverte.

En outre, cela peut être nécessaire (reconvertir tous les encodages de vos tables): /programming/6115612/how-to-convert-an-entire-mysql-database-characterset-and-collation- to-utf-8