Qu'il s'agisse d'applications, de systèmes d'exploitation, de bases de données, etc., tout ce qui lit, écrit ou manipule des données doit utiliser un encodage. De nos jours, il s'agit le plus souvent d'UTF-8 par défaut, parfois d'UTF-16, les deux étant des normes Unicode. Les auditeurs et les chercheurs en sécurité manipulent souvent des données ou des protocoles, mais qu'en est-il de la manipulation de l'encodage sous-jacent ?

Unicode est devenu l'encodage par excellence, remplaçant des centaines d'anciennes normes. À première vue, on pourrait penser qu'il s'agit d'une simplification. Il n'en est rien. Tous ces anciens encodages étaient très basiques, alors qu'Unicode est d'une complexité inouïe, que l'on ne peut imaginer qu'en lisant les spécifications.

Au fil des ans, la méconnaissance de l'Unicode et sa complexité ont entraîné de nombreux problèmes et erreurs de mise en œuvre. La version 16.0 de la norme Unicode compte 1140 pages, et il y a plus de 60 UAX (Unicode Standard Annexes), UTS (Unicode Technical Standards), UTR (Unicode Technical Reports), chacun d'entre eux étant comparable à un RFC de l'IETF. Au cours des trois dernières années, j'ai analysé une quinzaine de langages de programmation, dont aucun n'implémente 100 % de la norme Unicode.

Tous les logiciels qui vous entourent utilisent probablement l'Unicode, mais aucun d'entre eux ne l'implémente complètement et tous sont probablement différents. Qu'est-ce qui pourrait mal se passer ?