web-dev-qa-db-fra.com

Si un pirate modifie le blog_charset en UTF-7, cela rend-il WordPress vulnérable à de nouvelles attaques?

J'ai eu un client qui a été piraté récemment et j'ai remarqué qu'il y avait des personnages étranges apparaissant sur son site, comme  et. Il s'avère que les pirates ont modifié le blog_charset en UTF-7 dans la table wp_options de la base de données. Je l'ai redéfini sur UTF-8, mais je me demandais si, au moment où il était réglé sur UTF-7, cela pouvait-il créer des vulnérabilités en matière de sécurité?

J'ai fait des recherches et découvert qu'il y avait une vulnérabilité WordPress UTF-7 qui a été corrigée dans la version 2.0.6 . Nous utilisons la version la plus récente de WordPress, de sorte qu'ils n'auraient pas pu utiliser cet exploit, mais existe-t-il d'autres exploits liés à UTF-7? Vraiment, y a-t-il une raison pour que les pirates informatiques modifient le blog_charset autrement que pour être pénible? 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.

securityencodinghackedcharacters
19
Jennette

< et > sont codés en tant que +ADw- et +AD4- dans UTF-7 . Maintenant, imaginez ce qui suit:

  1. Quelqu'un envoie +ADw-script+AD4-alert(+ACI-Hello+ACI-)+ADw-/script+AD4- sous forme 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 également valides, cela ne provoquera jamais d'erreur SQL, et mysql_real_escape ou htmlspecialchars ne le toucheront pas.

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

  4. WordPress affiche le commentaire, en attente de données échappées. Mais puisque ceci 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 des textes seront rendus sous forme de Windows-1252 (ou quel que soit le codage par défaut de leur système d'exploitation) ou UTF-8. Le problème principal est le suivant: s’échapper ne fonctionnera plus.

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

23
fuxia

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

0
Travis van der Font