Da sich alle drei in derselben Version desselben Produkts und in derselben Schwachstellenklasse befinden, wurden sie unter einer einzigen Meldung zusammengefasst und unter einer einzigen CVE-ID veröffentlicht. In Bezug auf die Auswirkung ist Punkt 1 der schwerwiegendste.

1. Anmeldeseite — Parameter devam

Dies ist der kritischste Punkt. Die Injektionsstelle befindet sich direkt im HTML-Tag des Authentifizierungsformulars selbst.

Der Parameter devam trägt die Adresse, zu der der Benutzer nach der Anmeldung zurückkehren soll, und kommt hex-kodiert an — der Wert 2f796f7264616d2f bedeutet /yordam/. Die Anwendung decodiert diesen Wert aus Hex und schreibt ihn in das Öffnungs-Tag des Anmeldeformulars. Dazwischen gibt es keinerlei Escaping:

In der Ausgabe erscheinen <, > und Anführungszeichen als Rohzeichen. Das Einzige, was das Payload zusammenhält, ist die Tatsache, dass das data-url-Attribut in einfache Anführungszeichen gesetzt ist. Sobald ein einfaches Anführungszeichen in die Eingabe eingefügt wird, ist es damit vorbei: Das Attribut wird geschlossen, das <form>-Tag wird geschlossen, und das vom Angreifer geschriebene HTML ersetzt das Authentifizierungsformular der Seite.

Das Formular-action wird übernommen. Hier wird kein gefälschtes Formular gezeichnet — das eigene Formular der Anwendung wird leer gelassen und geschlossen, unmittelbar danach wird ein neues <form> mit denselben CSS-Klassen geöffnet. Da alle Felder für Benutzername, Passwort und Verifizierungscode auf der Seite aus dem ursprünglichen HTML der Anwendung stammen, bleiben sie innerhalb dieses neuen Formulars. Der Benutzer sieht das echte Formular, füllt das echte Formular aus; die eingegebenen Informationen gehen an den Server des Angreifers. Optisch gibt es keinen erkennbaren Unterschied.

Der kritische Punkt: Die Injektion erfolgt nicht auf einer beliebigen Seite, sondern auf der Seite, auf der der Benutzer ohnehin erwartet, sein Passwort einzugeben. Bei einer gewöhnlichen reflektierten Injektion muss der Angreifer das Opfer überzeugen; hier übernimmt die eigene Oberfläche der Anwendung die Überzeugungsarbeit.

2. value-Attribut eines versteckten Formularfelds — Doppelte URL-Decodierung

Auf der Suchseite werden die Werte der GET-Parameter in versteckte Formularfelder geschrieben. An dieser Stelle wird Escaping angewendet — aber in der falschen Reihenfolge.

Derselbe q-Wert wird in einer einzigen Antwort in drei verschiedenen Kontexten verwendet, von denen jeder eine andere Decodierungstiefe aufweist:

Die Verarbeitungsreihenfolge ist wie folgt:

Während der Eingabefilter und das Escaping auf der ersten Decodierungsebene arbeiten, wird die Ausgabe aus der zweiten Ebene gespeist. Beim Vergleich desselben Payloads in einfach und doppelt kodierter Form wird der Unterschied deutlich:

Die Schwachstelle ist nicht auf den Parameter q beschränkt. Der Block, der die versteckten Felder erzeugt, iteriert über alle GET-Parameter der Anfrage; sie wurde zusätzlich auf tip und alan verifiziert.

3. name-Attribut eines versteckten Formularfelds — Injektion im Parameternamen

Derselbe Block erzeugt für jeden GET-Parameter die folgende Struktur:

Das Escaping wird nur auf die value-Seite angewendet. Auf die name-Seite wird es überhaupt nicht angewendet. An dieser Stelle ist auch keine doppelte Kodierung erforderlich — eine einfache Kodierung genügt, da es kein Escaping gibt, das umgangen werden müsste.

Ein erfundener Parametername wird direkt als Rohwert in das name-Attribut geschrieben, und es kann aus dem Attribut ausgebrochen werden. Da der Parametername unter der Kontrolle des Angreifers steht, muss es sich nicht um einen von der Anwendung erkannten Parameter handeln.

Die Punkte 2 und 3 dieser drei Stellen stammen aus demselben Codeblock, und dieser Block wiederholt sich in sechs verschiedenen Formularen: dilForm, adetForm, siralaForm, tkForm, ekForm, tmForm. Das bedeutet, dass die Injektion in einer einzigen Anfrage sechsmal erfolgt.

Dass der Block dynamisch ist, wurde durch den Vergleich der Ausgaben zweier Anfragen verifiziert:

Die erzeugten Felder stammen nicht aus einer festen Liste, sondern werden direkt aus den Parametern der Anfrage abgeleitet. Folglich steht sowohl der Inhalt, der in das name- als auch der in das value-Attribut geschrieben wird, unter der Kontrolle des Angreifers.

Auswirkung

Das Einzige, was der Angreifer benötigt, ist ein Link, den das Opfer öffnet. Er muss sich nicht anmelden oder ein Konto besitzen.

• Diebstahl von Anmeldedaten. Über Punkt 1 wird das action-Ziel des Anmeldeformulars auf den Angreifer umgeleitet. Verifiziert.
• Gefälschter Inhalt unter der Identität der Institution. In der Adressleiste stehen die eigene Domain der Institution und ein gültiges TLS-Zertifikat. Gefälschte Ankündigungen, gefälschte Kampagnen und gefälschte Informationstexte können platziert werden.
• Inhaltsmanipulation und Weiterleitung. Die Seitenansicht kann verändert werden, der Benutzer kann zu einer externen Adresse geleitet werden.

Da die betroffene Plattform die Anmeldedaten und personenbezogenen Daten von Bibliotheksmitgliedern speichert, ist über kompromittierte Konten ein Zugriff auf Mitgliederdatensätze möglich.

Warum bestehende Schutzmaßnahmen es nicht verhindern

Die Anwendung verwendet CSP, und script-src sowie object-src sind nonce-basiert; klassisches script-basiertes XSS funktioniert auf diesen Seiten also nicht. Auf den ersten Blick scheint dies den Befund auf das Niveau einer „bloßen Inhaltsmanipulation" zu reduzieren.

Die vollständige Richtlinie lautet:

Es gibt kein form-action. Es gibt auch kein default-src — folglich gibt es keinen Rückfallwert für nicht definierte Direktiven. Ergebnis: Das POSTen des Formulars an den Server des Angreifers wird vom Browser in keiner Weise blockiert.

Zum Stehlen von Anmeldedaten ist es nicht erforderlich, JavaScript auszuführen. Reines HTML genügt, und CSP stoppt reines HTML nicht.

Verwandte Schwachstellen

Primär

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

Zugehörig

• 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

Im CVE-Eintrag wird die primäre Schwachstelle als CWE-79 klassifiziert. Auf der Ebene der Grundursache ist CWE-116 aussagekräftiger: Die Ursache aller drei Stellen ist, dass das Ausgabe-Escaping entweder gar nicht oder in der falschen Reihenfolge angewendet wird.

Es ist anzumerken, dass in diesem Produkt kein Script ausgeführt wird — die vom Produkt selbst gesendete nonce-basierte script-src-Richtlinie erlaubt dies nicht, und der Nonce-Wert kann nicht cross-origin gelesen werden. Die tatsächlich eintretende Auswirkung ist keine Script-Ausführung, sondern HTML-Injektion und die Übernahme des Anmeldeformulars. Die Zuordnung zu CAPEC-148 (Content Spoofing) wurde aus diesem Grund vorgenommen.

CWE-174 gilt insbesondere für Punkt 2 — die zweite Decodierung derselben Daten nach dem Escaping.

Schweregrad

Mittel — CVSS 3.1 Basiswert 6.1 (AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N)

Der Angreifer benötigt keinerlei Berechtigungen; da das Opfer den vorbereiteten Link öffnen muss, ist Benutzerinteraktion erforderlich. Der Scope wurde als Changed bewertet, da der injizierte Inhalt im Sicherheitskontext des Browsers verarbeitet wird.

Alle drei Stellen entsprechen demselben Wert. In Bezug auf die Auswirkung ist Punkt 1 der schwerwiegendste: Da die Injektion direkt im Tag des Authentifizierungsformulars selbst erfolgt, sind die Übernahme des Formular-action-Ziels und der Diebstahl von Anmeldedaten möglich.

Betroffene Versionen

Die Verifizierung wurde auf v22.1 durchgeführt. Die Schwachstellen sind kein institutionsspezifischer Konfigurationsfehler, sondern stammen aus gemeinsamen Oberflächenkomponenten des Produkts; sie betreffen alle Installationen derselben Versionsfamilie. Der Status älterer Versionen muss vom Hersteller bewertet werden.

Da die Installationen on-premise erfolgen, bleiben Installationen, die das Update nicht angewendet haben, auch dann betroffen, wenn der Hersteller den Fix veröffentlicht hat.

Betroffene Komponente

Die Punkte 2 und 3 stammen aus demselben Block zur Erzeugung versteckter Felder; der Block wiederholt sich in den Formularen dilForm, adetForm, siralaForm, tkForm, ekForm und tmForm.

Lösung

Die Schwachstellen wurden vom Hersteller behoben. Die Anwendung sollte auf v22.2 oder höher aktualisiert werden.

CVE-Eintrag

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

Entdecker

Alkım Coşkun – Netlore Security

Offenlegungszeitplan