Comme les trois se trouvent dans la même version du même produit et relèvent de la même classe de vulnérabilité, elles ont été regroupées sous un seul avis et publiées sous un seul identifiant CVE. En termes d'impact, le point n° 1 est le plus grave.

1. Page de connexion — Paramètre devam

C'est le plus critique. Le point d'injection se trouve directement dans la balise HTML du formulaire d'authentification lui-même.

Le paramètre devam transporte l'adresse vers laquelle l'utilisateur reviendra après la connexion et arrive encodé en hexadécimal — la valeur 2f796f7264616d2f signifie /yordam/. L'application décode cette valeur depuis l'hexadécimal et l'écrit dans la balise d'ouverture du formulaire de connexion. Aucun échappement n'est appliqué entre les deux :

Dans la sortie, les caractères <, > et les guillemets apparaissent bruts. La seule chose qui retient le payload est que l'attribut data-url est entouré de guillemets simples. Lorsqu'un guillemet simple est inséré dans l'entrée, cela suffit : l'attribut se ferme, la balise <form> se ferme, et le HTML écrit par l'attaquant remplace le formulaire d'authentification de la page.

L'action du formulaire est détournée. Aucun faux formulaire n'est dessiné ici — le formulaire propre de l'application est laissé vide et fermé, puis un nouveau <form> portant les mêmes classes CSS est ouvert immédiatement après. Comme les champs de nom d'utilisateur, de mot de passe et de code de vérification de la page proviennent tous du HTML d'origine de l'application, ils restent à l'intérieur de ce nouveau formulaire. L'utilisateur voit le vrai formulaire, remplit le vrai formulaire ; les informations saisies partent vers le serveur de l'attaquant. Il n'y a aucune différence visuellement perceptible.

Le point crucial : l'injection ne se produit pas sur une page quelconque, mais sur la page où l'utilisateur est déjà censé saisir son mot de passe. Dans une injection réfléchie ordinaire, l'attaquant doit convaincre la victime ; ici, c'est l'interface de l'application elle-même qui fait le travail de persuasion.

2. Attribut value d'un champ de formulaire masqué — Double décodage URL

Sur la page de recherche, les valeurs des paramètres GET sont écrites dans des champs de formulaire masqués. Un échappement est appliqué à ce stade — mais dans le mauvais ordre.

La même valeur q est utilisée dans trois contextes distincts au sein d'une même réponse, chacun ayant une profondeur de décodage différente :

La séquence d'opérations est la suivante :

Alors que le filtre d'entrée et l'échappement opèrent sur la première couche de décodage, la sortie est alimentée par la seconde couche. La différence est clairement visible en comparant les versions à encodage simple et double du même payload :

La vulnérabilité n'est pas spécifique au paramètre q. Le bloc qui génère les champs masqués parcourt tous les paramètres GET de la requête ; elle a également été vérifiée sur tip et alan.

3. Attribut name d'un champ de formulaire masqué — Injection dans le nom du paramètre

Le même bloc génère la structure suivante pour chaque paramètre GET :

L'échappement n'est appliqué que du côté value. Il n'est jamais appliqué du côté name. À ce stade, le double encodage n'est même pas nécessaire — un simple encodage suffit, car il n'y a aucun échappement à contourner.

Un nom de paramètre inventé est écrit directement et brut dans l'attribut name, permettant de sortir de l'attribut. Comme le nom du paramètre est sous le contrôle de l'attaquant, il n'a pas besoin d'être un paramètre reconnu par l'application.

Les points n° 2 et n° 3 de ces trois points proviennent du même bloc de code, et ce bloc se répète dans six formulaires distincts : dilForm, adetForm, siralaForm, tkForm, ekForm, tmForm. Autrement dit, en une seule requête, l'injection se produit six fois.

Le caractère dynamique du bloc a été vérifié en comparant la sortie de deux requêtes :

Les champs générés ne proviennent pas d'une liste fixe, mais sont dérivés directement des paramètres de la requête. Par conséquent, le contenu écrit à la fois dans les attributs name et value est sous le contrôle de l'attaquant.

Impact

La seule chose dont l'attaquant a besoin est un lien que la victime ouvrira. Il n'a pas besoin de se connecter ni d'avoir un compte.

• Vol d'identifiants. Via le point n° 1, la cible action du formulaire de connexion est redirigée vers l'attaquant. Vérifié.
• Contenu frauduleux sous l'identité de l'institution. Le nom de domaine propre de l'institution et un certificat TLS valide apparaissent dans la barre d'adresse. De faux avis, de fausses campagnes et de faux textes d'information peuvent être insérés.
• Altération de contenu et redirection. L'apparence de la page peut être modifiée et l'utilisateur peut être redirigé vers une adresse externe.

Comme la plateforme concernée héberge les identifiants et les données personnelles des membres de la bibliothèque, l'accès aux dossiers des membres est possible via les comptes compromis.

Pourquoi les protections existantes ne l'arrêtent pas

L'application utilise une CSP, avec script-src et object-src basés sur des nonces ; autrement dit, les XSS classiques basés sur des scripts ne fonctionnent pas sur ces pages. À première vue, cela semble réduire la découverte au niveau d'une « simple altération de contenu ».

La politique complète est la suivante :

Il n'y a pas de form-action. Il n'y a pas non plus de default-src — donc aucune valeur par défaut vers laquelle retomber pour les directives non définies. Résultat : rien dans le navigateur n'empêche le formulaire d'envoyer un POST vers le serveur de l'attaquant.

Pour voler des identifiants, il n'est pas nécessaire d'exécuter du JavaScript. Du HTML simple suffit, et la CSP n'arrête pas le HTML simple.

Faiblesses associées

Principale

• CWE-79 — Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')

Connexes

• CWE-116 — Improper Encoding or Escaping of Output
• CWE-174 — Double Decoding of the Same Data
• CWE-172 — Encoding Error
• CWE-451 — User Interface (UI) Misrepresentation of Critical Information

Dans l'enregistrement CVE, la faiblesse principale est classée comme CWE-79. Au niveau de la cause racine, CWE-116 est plus explicite : la cause des trois points est que l'échappement de sortie n'est soit jamais appliqué, soit appliqué dans le mauvais ordre.

Il convient de noter qu'aucun script n'est exécuté dans ce produit — la politique script-src basée sur des nonces envoyée par le produit lui-même ne le permet pas, et la valeur du nonce ne peut pas être lue en cross-origin. L'impact réel n'est pas l'exécution de scripts, mais l'injection HTML et le détournement du formulaire de connexion. C'est également pour cette raison que la correspondance CAPEC-148 (Content Spoofing) a été établie.

CWE-174 s'applique particulièrement au point n° 2 — le décodage d'une même donnée une seconde fois après l'échappement.

Sévérité

Moyen — Score de base CVSS 3.1 6.1 (AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N)

L'attaquant n'a besoin d'aucun privilège ; comme la victime doit ouvrir le lien préparé, l'interaction utilisateur est Requise. Le Scope est défini sur Changed, car le contenu injecté est traité dans le contexte de sécurité du navigateur.

Les trois points correspondent tous au même score. En termes d'impact, le point n° 1 est le plus grave : comme l'injection se produit directement dans la balise du formulaire d'authentification lui-même, le détournement de la cible action du formulaire et le vol d'identifiants sont possibles.

Versions concernées

La vérification a été effectuée sur v22.1. Les vulnérabilités ne proviennent pas d'une erreur de configuration spécifique à une institution, mais de composants d'interface communs du produit ; elles affectent toutes les installations de la même famille de versions. L'état des versions plus anciennes doit être évalué par le fabricant.

Comme les installations sont sur site, même si le fabricant a publié le correctif, les installations qui n'ont pas appliqué la mise à jour restent vulnérables.

Composant concerné

Les points n° 2 et n° 3 proviennent du même bloc générateur de champs masqués ; le bloc se répète dans les formulaires dilForm, adetForm, siralaForm, tkForm, ekForm et tmForm.

Solution

Les vulnérabilités ont été corrigées par le fabricant. L'application doit être mise à niveau vers v22.2 ou une version ultérieure.

Enregistrement CVE

Fabricant : Yordam Bilgi Teknolojileri Danışmanlık Eğitim ve Elektronik Sistemler Sanayi ve Ticaret A.Ş.

Découvreur

Alkım Coşkun – Netlore Security

Calendrier de divulgation