HackTricks TrainingTwitterLinkedinSponsor

Unicode Injection

Apprenez le piratage AWS de zéro à héros avec htARTE (Expert en équipe rouge AWS de HackTricks)!

Autres façons de soutenir HackTricks :

Introduction

Selon le comportement du back-end/front-end lorsqu'il reçoit des caractères unicode étranges, un attaquant pourrait être en mesure de contourner les protections et d'injecter des caractères arbitraires qui pourraient être utilisés pour exploiter des vulnérabilités d'injection telles que XSS ou SQLi.

Normalisation Unicode

La normalisation Unicode se produit lorsque les caractères unicode sont normalisés en caractères ASCII.

Un scénario courant de ce type de vulnérabilité se produit lorsque le système modifie d'une manière ou d'une autre l'entrée de l'utilisateur après l'avoir vérifiée. Par exemple, dans certaines langues, un simple appel pour mettre l'entrée en majuscules ou en minuscules pourrait normaliser l'entrée donnée et l'unicode sera transformé en ASCII générant de nouveaux caractères. Pour plus d'informations, consultez :

Unicode Normalization

\u à %

Les caractères unicode sont généralement représentés avec le préfixe \u. Par exemple, le caractère 㱋 est \u3c4b(vérifiez ici). Si un back-end transforme le préfixe \u en %, la chaîne résultante sera %3c4b, qui décodée en URL est : <4b. Et, comme vous pouvez le voir, un caractère < est injecté. Vous pourriez utiliser cette technique pour injecter n'importe quel type de caractère si le back-end est vulnérable. Consultez https://unicode-explorer.com/ pour trouver les caractères dont vous avez besoin.

Cette vulnérabilité provient en fait d'une découverte qu'un chercheur a faite, pour une explication plus approfondie, consultez https://www.youtube.com/watch?v=aUsAHb0E7Cg

Injection Emoji

Les back-ends se comportent parfois de manière étrange lorsqu'ils reçoivent des emojis. C'est ce qui s'est passé dans ce compte rendu où le chercheur a réussi à obtenir un XSS avec une charge utile telle que : 💋img src=x onerror=alert(document.domain)//💛

Dans ce cas, l'erreur était que le serveur, après avoir supprimé les caractères malveillants, a converti la chaîne UTF-8 de Windows-1252 en UTF-8 (essentiellement, l'encodage d'entrée et la conversion d'encodage ne correspondaient pas). Ensuite, cela ne donne pas un < correct mais un étrange en unicode : ‹ ``Ils ont donc pris cette sortie et l'ont convertie à nouveau de l'UTF-8 en ASCII. Cela a normalisé le ‹ en <, c'est ainsi que l'exploit a pu fonctionner sur ce système. Voici ce qui s'est passé:

<?php

$str = isset($_GET["str"]) ? htmlspecialchars($_GET["str"]) : "";

$str = iconv("Windows-1252", "UTF-8", $str);
$str = iconv("UTF-8", "ASCII//TRANSLIT", $str);

echo "String: " . $str;

Liste d'emojis :

Apprenez le piratage AWS de zéro à héros avec htARTE (Expert de l'équipe rouge HackTricks AWS)!

Autres façons de soutenir HackTricks :

PreviousReverse Tab NabbingNextUnicode Normalization

Last updated