Normalisation URL : éviter les erreurs de matching IOC

Deux chaînes différentes peuvent représenter la même destination, et deux URL visuellement proches peuvent désigner des ressources différentes. Pour un moteur de correspondance IOC, la normalisation URL doit réduire les différences justifiées sans effacer celles qui comptent pour l’enquête.

Une règle trop stricte manque des correspondances. Une règle trop agressive associe des événements sans lien. Le travail consiste à définir une égalité adaptée au contrôle utilisé, puis à conserver la chaîne brute qui permet d’expliquer chaque décision.

Définir ce qui doit correspondre

Commencez par nommer la portée de votre indicateur. Un domaine, une origine composée d’un schéma, d’un hôte et d’un port, une URL complète et un préfixe de chemin ne représentent pas la même règle. Ne réduisez pas silencieusement un IOC URL à son domaine pour faciliter l’indexation.

Précisez aussi la donnée disponible dans votre capteur. Un journal DNS ne voit pas le chemin HTTP. Un proxy peut ne conserver qu’une partie de la requête. Un navigateur peut produire une URL déjà transformée. Le moteur doit comparer des champs effectivement observés, sans reconstituer les morceaux manquants comme s’ils étaient certains.

Cette étape complète le pipeline général de gestion des IOC. Ici, la question est plus étroite : quelles transformations permettent de dire que deux observations correspondent au même indicateur ?

Garder la preuve et la clé de comparaison séparées

Stockez au minimum la valeur brute, sa source, l’heure, la valeur destinée à la comparaison et la version du normaliseur. Conservez également le résultat du parsing et les avertissements. Une entrée rejetée doit rester explicable, avec les contrôles de confidentialité adaptés.

La clé calculée sert à la recherche. La valeur brute permet de comprendre une erreur, de rejouer une conversion et de distinguer une transformation du producteur d’une transformation de votre plateforme. Sans cette séparation, modifier le normaliseur réécrit implicitement l’histoire de vos observations.

N’incluez pas automatiquement l’URL entière dans tous les journaux de diagnostic. Les paramètres peuvent contenir un jeton ou une adresse personnelle. Prévoyez une conservation restreinte de la preuve et une version expurgée pour les vues courantes, sans prétendre que ces deux formes sont identiques.

Traiter la casse composant par composant

La RFC 3986, section 6, distingue plusieurs formes de comparaison et de normalisation. Le schéma et l’hôte ne se traitent pas comme tous les autres composants. Transformer globalement la chaîne en minuscules peut modifier le chemin ou des données de requête.

Les exemples suivants sont fictifs et utilisent un domaine réservé :

https://PORTAIL.EXAMPLE/Compte?id=AbC
https://portail.example/Compte?id=AbC
https://portail.example/compte?id=abc

Les deux premières formes ne diffèrent que par la casse de l’hôte. La troisième modifie aussi le chemin et la valeur du paramètre. Votre moteur ne doit pas les fusionner sur la simple intuition que « les URL ne sont pas sensibles à la casse ».

Pour les noms internationalisés, utilisez la même bibliothèque et la même convention des deux côtés de la comparaison. Gardez les représentations utiles à l’analyste, mais ne confondez pas ressemblance visuelle et égalité technique du nom.

Résister aux décodages successifs

L’encodage en pourcentage est un point sensible. Décoder une fois pour faciliter l’affichage, puis une seconde fois avant le matching, peut changer la valeur comparée. Les caractères réservés et les séparateurs ne doivent pas être transformés sans tenir compte de leur rôle.

Comparez ces deux chemins fictifs :

https://portail.example/fichiers/a%2Fb
https://portail.example/fichiers/a/b

Ils ne sont pas interchangeables par défaut. Le premier contient un séparateur encodé dont le traitement dépend aussi de la chaîne serveur. Conservez cette distinction tant que votre politique n’a pas établi précisément l’équivalence recherchée.

Séparez de même le décodage HTML d’un lien extrait d’un message et le parsing de son URL. & peut provenir du document qui contenait le lien. Appliquer aveuglément cette conversion à une chaîne déjà extraite introduit une autre transformation. Notez à quelle couche chaque opération appartient.

Ne pas réécrire arbitrairement la requête et le fragment

Trier les paramètres paraît faciliter la déduplication. Pourtant, une application peut interpréter leur ordre ou des clés répétées. Une signature applicative peut également dépendre de la représentation transmise. Préservez l’ordre tant que l’équivalence n’est pas documentée pour votre usage.

Le fragment, après #, appartient à la représentation de l’URL et peut servir au fonctionnement côté client. Un journal de requête HTTP ne l’observe généralement pas. Votre politique doit dire si elle compare une navigation complète ou une cible transmise au serveur.

Le standard URL de WHATWG décrit les opérations de parsing et de sérialisation utilisées pour les URL web. Choisissez un parseur dont le comportement correspond à votre source, puis vérifiez les cas limites. Mélanger plusieurs parseurs à des étapes successives peut produire des résultats différents sur une entrée ambiguë.

Constituer un corpus qui protège contre les fusions abusives

Préparez deux familles de tests : les paires qui doivent correspondre et celles qui doivent rester distinctes. Chaque cas doit indiquer la portée du matching et la raison de la décision. Un test positif seul ne détectera jamais une normalisation qui transforme toutes les URL d’un domaine en une même clé.

Ajoutez les données mal formées, les ports explicites et les URL relatives. Une URL relative exige une base connue ; lui ajouter arbitrairement un domaine produit un indicateur inventé. Réexécutez le corpus à chaque changement de bibliothèque ou de règles.

Expliquer une alerte avec la transformation exacte

Lorsqu’un événement correspond, affichez la portée de la règle et les transformations appliquées. L’analyste doit pouvoir comprendre si le résultat vient d’une égalité exacte, d’une normalisation limitée ou d’une règle plus large au niveau domaine.

Avant toute consultation externe, examinez les données sensibles selon le guide sur les URL suspectes et redirections. Vous pouvez ensuite consulter un rapport sur l’indicateur public pertinent, en gardant séparée l’URL originale si elle contient des secrets.

Une bonne conclusion décrit ce qui correspond réellement. « Même domaine » et « même URL observée » demandent des actions différentes. Votre normaliseur doit permettre de conserver cette différence jusque dans la décision finale.