Certains caractères unicodes sont invisibles. Pas seulement les \n ou \t, non, vraiment invisibles. Genre leur existence est d’être un caractère invisible.

Un peu comme un trait d’union conditionnel qui n’est visible que dans certains cas, et invisible autrement. Sauf qu’ici, je parle d’un caractère unicode (coréen, en l’occurrence) qui est invisible même dans le code source. Il est là si on parle les données sur le disque, mais aucun éditeur de texte faisant un rendu de ces caractères ne vous le montrera, car il est invisible.

Dans cet exemple, il est montré comment on peut tout de même utiliser ce caractère comme nom de variable, et donc lui assigner des valeurs.

Dans l’exemple, on fait un simple "ping" sur Google.com (un truc classique). La variable reçoit alors un code de retour.

La backdoor, c’est que la variable est ensuite envoyée à "exec()", qui envoie des commandes au shell système. Donc il suffit que "google.com" renvoie un code contenant — au hasard — quelque chose comme "rm -rf /" et hop : un simple ping se transforme en effacement du disque dur !

… Et aucun éditeur de texte ne vous montrera quoi que ce soit d’anormal dans le code source : la variable fautive étant INVISIBLE dans le code source.

C’est violent quand-même…

Encore une fois : ça montre qu’il est bien joli de vouloir mettre de l’unicode partout (« yeah, c’est inclusif ! ») mais quand c’est pas fait sérieusement… voilà.

Voir aussi cet exemple. Ou ça. Ou encore ça, ou cet article où je dénonce les problèmes à mettre de l’Unicode partout sans réfléchir.

La dernière version de SublimeText permet d’afficher le code d’échappement des caractères non ASCII, par défaut. Je l’avais désactivé car c’est chiant. Mais si ça continue, il va falloir le laisser activé.

— (permalink)