Outils de développement · Encodeur et décodeur d'URL
L'encodage d'URL n'est pas une désinfection : les paramètres décodés doivent toujours être échappés
· Pourquoi c'est important
encodage d'URL sécurité xss
Le codage en pourcentage protège la structure de l'URL, et non votre HTML, SQL ou votre shell. Cet article explique pourquoi une valeur correctement codée redevient dangereuse au moment où elle est décodée, et quelle fuite appartient à où.
Pourquoi le codage d'URL seul ne peut pas arrêter les attaques XSS
Un paramètre "sûr" peut exécuter un script s'il est codé pour la transmission mais décodé avant le rendu. Considérez la charge utile XSS comme la balise img avec le gestionnaire d'erreurs codé en pourcentage comme %3Cimg%20src%3Dx%20onerror%3Dalert%281%29%3E. Si cela se propage dans l'URL et décodé par le code de l'application avant d'être inséré dans le HTML, le navigateur voit le balisage d'origine et exécute le gestionnaire. Le codage en pourcentage est la couche de représentation ; ne change pas la menace sous-jacente.
La charge utile n'est sécurisée que pendant la transmission, lorsqu'il s'agit d'une chaîne codée sans signification particulière pour l'analyseur HTTP ou URL. Dès qu'il est décodé, il redevient dangereux car il revient à sa forme originale. Chaque contexte en aval doit appliquer ses propres règles d'échappement adaptées à la manière dont il utilisera les données. Le codage d'URL ne remplace pas l'échappement HTML, le paramétrage SQL ou la gestion des arguments du shell.
À quoi sert le codage en pourcentage : garder les délimiteurs sans ambiguïté sur le fil, rien de plus
Le codage en pourcentage protège précisément la structure de l'URL. L'esperluette fait partie de la syntaxe de la chaîne de requête et n'est pas réinterprétée comme délimiteur. Slash ne devient pas un séparateur de chemin. Le point d'interrogation ne démarre pas le fragment. En codant les caractères réservés en %XX, l'analyseur les traite comme des données et non comme de la syntaxe. Cela fonctionne pour un seul travail : garder la structure des URL sans ambiguïté sur le réseau.
Le décodage inverse exactement cette rue à sens unique. Les octets restaurés sont exactement ce qui a été codé, ni plus ni moins. La chaîne dangereuse pour le HTML reste dangereuse, le vecteur d'injection SQL reste dangereux et la commande shell reste dangereuse. Le codage en pourcentage n'est pas une validation d'entrée, ni une désinfection ni une limite de sécurité. Il s'agit uniquement d'un format de représentation.
Le décodage restaure les octets d'origine — de sorte que chaque contexte en aval voit à nouveau la valeur brute
L'évasion spécifique au contexte est le lieu où la véritable protection vit véritablement. Le contexte HTML a besoin d'entités : moins que devient <, supérieur à devient >, les guillemets deviennent ", l'esperluette devient &. Le contexte SQL a besoin de requêtes paramétrées séparant la structure des données, empêchant l'attaquant d'éclater. Le contexte Shell a besoin de tableaux d'arguments évitant le fractionnement et la globalisation des mots.
Chaque contexte a précisément différents caractères dangereux et différentes règles d'évasion. L'entité HTML est inoffensive dans les requêtes SQL mais inutile pour la protection. La barre oblique inverse empêche l'injection SQL dans certaines bases de données mais pas dans d'autres. L'échappement du shell dépend du style de citation. Le développeur doit comprendre la destination avant de choisir comment gérer les données.
Échappement spécifique au contexte — entités HTML pour le balisage, requêtes paramétrées pour SQL, tableaux d'arguments pour les shells
Exemple concret : le suivi de la charge utile du lien au journal jusqu'à la page révèle où l'encodage et l'échappement doivent avoir lieu. Le lien contient une charge utile XSS codée comme paramètre de requête. Le serveur le reçoit toujours codé dans le corps de la requête HTTP. L'application décode le paramètre de requête pour l'afficher dans la page. Sans échappement de sortie, le navigateur restitue la charge utile au format HTML et l'exécute.
Si le même paramètre est enregistré dans le fichier, l'entrée du journal contient clairement la charge utile décodée. La deuxième application lit le journal, le décode à nouveau, l'insère dans la page HTML sans s'échapper. La charge utile s'exécute une deuxième fois. À chaque étape, le contexte déterminait ce qui était sûr. Le décodage des URL était sécurisé. Le stockage des fichiers était sécurisé. Mais la sortie HTML sans échappement était fatale.
Exemple concret : suivre une charge utile du lien au journal jusqu'à la page – où elle est codée, où elle est décodée, où elle doit être échappée
L'encodage en tant qu'outil d'évasion de filtre montre pourquoi les attaquants doublent l'encodage et mélangent considérablement la casse hexadécimale. Si le pare-feu recherche la balise img, l'attaquant envoie %3Cimg et espère que l'application décode une fois, mais pas le pare-feu. Si la validation rejette %3Cimg mais autorise une casse différente, les mêmes octets sont décodés vers la même charge utile. La sécurité qui dépend de la correspondance de modèles d'entrée codée est fragile.
Le décodage doit être exact et absolument prévisible. La forme canonique (hexadécimal minuscule, encodage connu) permet une politique cohérente mais ne résout pas le problème sous-jacent. La seule approche fiable consiste à autoriser le décodage si nécessaire et à appliquer une sortie spécifique au contexte immédiatement avant utilisation. Le décodage n’est jamais sûr ; uniquement nécessaire à la transmission.
L'encodage comme outil d'évasion de filtre : pourquoi les attaquants doublent l'encodage et mélangent la casse hexadécimale, et pourquoi le décodage doit être exact
La défense XSS complète nécessite une compréhension complète des flux de données, des contextes qu'ils traversent à chaque étape, et des besoins pour échapper à chaque contexte. Le codage de l'URL n'est qu'un petit élément : il préserve la structure pendant la transmission uniquement. Mais une seule pièce ne constitue jamais une défense en soi. De nombreux développeurs confondent codage et nettoyage, car les deux impliquent le remplacement de caractères, mais remplissent des tâches importantes complètement différentes.
Web Application Firewall peut détecter des modèles dans les charges utiles des requêtes, mais le codage échappe facilement aux techniques simples de correspondance de modèles. Le réglage WAF est complexe et va au-delà du codage d'URL. Une défense fiable consiste en une sortie d'échappement dans le code de l'application, associée à une validation d'entrée lorsque cela est logique pour votre contexte et vos exigences spécifiques.
Ce que cela ne couvre pas : un guide complet de défense XSS ou le réglage du pare-feu d'application Web
La défense XSS complète nécessite une compréhension complète des flux de données, des contextes qu'ils traversent à chaque étape, des besoins pour échapper à chaque contexte tout au long de l'application. Le codage de l'URL n'est qu'un petit élément : il préserve la structure pendant la transmission uniquement. Mais une seule pièce ne constitue jamais une défense en soi. De nombreux développeurs confondent codage et nettoyage, car les deux impliquent le remplacement de caractères, mais remplissent des tâches importantes complètement différentes tout au long du développement.
Testez la charge utile de bout en bout pour voir où l'encodage et l'échappement sont réellement importants tout au long du processus. Collez %3Cimg%20src%3Dx%20onerror%3Dalert%281%29%3E dans le décodeur d'URL et regardez devenir une chaîne ressemblant à un balisage. Collez ensuite le résultat dans l'échappement d'entité HTML pour voir comment devient le texte sécurisé. Deux outils affichent les calques clairement visibles.
À retenir : encoder pour l'URL, échapper pour la sortie - comment l'encodeur et le décodeur d'URL et l'échappement d'entité HTML sont côte à côte dans un seul produit pour les deux tâches différentes
Ce qu'il faut retenir, c'est que l'encodage et l'échappement sont des préoccupations distinctes à différentes couches absolument partout. Le codage URL protège uniquement la structure transmise. L'échappement de sortie protège le contenu rendu. La valeur correctement codée nécessite toujours un échappement de sortie lorsqu'elle atteint le HTML. Une chaîne correctement échappée n'a jamais besoin d'être codée en URL si elle n'est pas insérée dans l'URL.
Appliquez véritablement la bonne défense sur la couche de droite. Ne comptez pas sur le codage d'URL pour arrêter les attaques XSS. Ne comptez pas sur l'échappement HTML pour préserver la structure de l'URL. Comprenez votre flux de données et appliquez la transformation appropriée à chaque étape. L'encodeur d'URL vous aide à voir ce que fait l'encodage ; puis utilisez l'échappement d'entité HTML pour l'étape de sortie.