Poiché i tre punti riguardano la stessa versione dello stesso prodotto e la stessa classe di vulnerabilità, sono stati raggruppati in un'unica segnalazione e pubblicati sotto un unico identificativo CVE. In termini di impatto, il punto 1 è il più grave.

1. Pagina di Accesso — Parametro devam

Questo è il più critico. Il punto di iniezione è direttamente il tag HTML del modulo di autenticazione stesso.

Il parametro devam trasporta l'indirizzo a cui l'utente tornerà dopo l'accesso e arriva codificato in hex — il valore 2f796f7264616d2f significa /yordam/. L'applicazione decodifica questo valore dall'hex e lo scrive nel tag di apertura del modulo di accesso. Non c'è alcuna operazione di escaping nel mezzo:

Nell'output, i caratteri <, > e le virgolette compaiono grezzi. L'unica cosa che contiene il payload è il fatto che l'attributo data-url è racchiuso tra virgolette singole. Quando si inserisce una virgoletta singola nell'input, anche quella termina: l'attributo si chiude, il tag <form> si chiude e l'HTML scritto dall'attaccante prende il posto del modulo di autenticazione della pagina.

L'azione del modulo viene dirottata. Qui non viene disegnato un modulo falso — il modulo dell'applicazione viene lasciato vuoto e chiuso, e subito dopo viene aperto un nuovo <form> con le stesse classi CSS. Poiché i campi per nome utente, password e codice di verifica nella pagina sono tutti HTML originale dell'applicazione, rimangono all'interno di questo nuovo modulo. L'utente vede il modulo reale, compila il modulo reale; le informazioni inserite vengono inviate al server dell'attaccante. Non c'è alcuna differenza visivamente distinguibile.

Il punto critico: l'iniezione non avviene su una pagina qualsiasi, ma sulla pagina in cui ci si aspetta già che l'utente inserisca la propria password. In un'iniezione riflessa ordinaria, l'attaccante deve convincere la vittima; qui è l'interfaccia stessa dell'applicazione a fare il lavoro di convincimento.

2. Attributo value del Campo Modulo Nascosto — Doppio URL Decode

Nella pagina di ricerca, i valori dei parametri GET vengono scritti in campi modulo nascosti. A questo punto viene applicato l'escaping — ma nell'ordine sbagliato.

Lo stesso valore q viene utilizzato in tre contesti diversi all'interno della stessa risposta, ciascuno con una diversa profondità di decodifica:

La sequenza delle operazioni è la seguente:

Il filtro di ingresso e l'escaping operano sul primo livello di decodifica, mentre l'output viene alimentato dal secondo livello. Confrontando le versioni a codifica singola e doppia dello stesso payload, la differenza è chiaramente visibile:

La vulnerabilità non è specifica del parametro q. Il blocco che genera i campi nascosti itera su tutti i parametri GET della richiesta; è stata verificata anche su tip e alan.

3. Attributo name del Campo Modulo Nascosto — Iniezione nel Nome del Parametro

Lo stesso blocco genera la seguente struttura per ogni parametro GET:

L'escaping viene applicato solo al lato value. Non viene mai applicato al lato name. A questo punto non serve nemmeno la doppia codifica — la codifica singola è sufficiente, perché non c'è alcun escaping da aggirare.

Un nome di parametro inventato viene scritto direttamente e grezzo nell'attributo name, consentendo l'uscita dall'attributo. Poiché il nome del parametro è sotto il controllo dell'attaccante, non è necessario che sia un parametro riconosciuto dall'applicazione.

I punti 2 e 3 di queste tre vulnerabilità derivano dallo stesso blocco di codice, e questo blocco si ripete in sei moduli diversi: dilForm, adetForm, siralaForm, tkForm, ekForm, tmForm. In una singola richiesta, l'iniezione avviene quindi sei volte.

La natura dinamica del blocco è stata verificata confrontando l'output di due richieste:

I campi generati non derivano da un elenco fisso, ma direttamente dai parametri della richiesta. Pertanto, sia il contenuto scritto nell'attributo name che quello nell'attributo value sono sotto il controllo dell'attaccante.

Impatto

L'unica cosa di cui l'attaccante ha bisogno è un collegamento che la vittima apra. Non è necessario che acceda né che abbia un account.

• Furto di credenziali. Attraverso il punto 1, la destinazione action del modulo di accesso viene reindirizzata all'attaccante. Verificato.
• Contenuti falsi con l'identità dell'istituzione. Nella barra degli indirizzi compaiono il dominio dell'istituzione e un certificato TLS valido. È possibile inserire annunci falsi, campagne false, testi informativi falsi.
• Manomissione dei contenuti e reindirizzamento. L'aspetto della pagina può essere modificato e l'utente può essere trasportato verso un indirizzo esterno.

Poiché la piattaforma interessata contiene le credenziali e i dati personali degli utenti della biblioteca, attraverso gli account compromessi è possibile accedere ai registri degli iscritti.

Perché le Protezioni Esistenti Non Bloccano

L'applicazione utilizza CSP e script-src e object-src sono basati su nonce; quindi il classico XSS basato su script non funziona su queste pagine. A prima vista, ciò sembrerebbe ridurre il risultato al livello di "sola manomissione dei contenuti".

La politica completa è la seguente:

Non c'è form-action. Non c'è nemmeno default-src — quindi non esiste un valore predefinito a cui ricadere per le direttive non definite. Risultato: il browser non blocca in alcun modo l'invio POST del modulo al server dell'attaccante.

Per rubare le credenziali non è necessario eseguire JavaScript. L'HTML semplice è sufficiente, e il CSP non blocca l'HTML semplice.

Debolezze Correlate

Primaria

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

Correlate

• 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

Nel record CVE, la debolezza primaria è classificata come CWE-79. A livello di causa principale, CWE-116 è più descrittiva: la causa di tutti e tre i punti è che l'escaping dell'output o non viene mai applicato o viene applicato nell'ordine sbagliato.

Va notato che in questo prodotto non viene eseguito script — la politica script-src basata su nonce inviata dal prodotto stesso non lo consente e il valore del nonce non può essere letto cross-origin. L'impatto realizzato non è l'esecuzione di script, ma l'iniezione HTML e il dirottamento del modulo di accesso. Per questo motivo è stata effettuata anche la corrispondenza con CAPEC-148 (Content Spoofing).

CWE-174 si applica in particolare al punto 2 — la decodifica secondaria degli stessi dati dopo l'escaping.

Gravità

Media — Punteggio Base CVSS 3.1 6.1 (AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N)

L'attaccante non necessita di alcun privilegio; poiché la vittima deve aprire il collegamento predisposto, l'interazione dell'utente è Richiesta. Lo Scope è stato impostato su Changed perché il contenuto iniettato viene elaborato nel contesto di sicurezza del browser.

Tutti e tre i punti corrispondono allo stesso punteggio. In termini di impatto, il più grave è il punto 1: poiché l'iniezione avviene direttamente nel tag del modulo di autenticazione stesso, è possibile il dirottamento della destinazione action del modulo e il furto di credenziali.

Versioni Interessate

La verifica è stata effettuata sulla v22.1. Le vulnerabilità non derivano da errori di configurazione specifici dell'istituzione, ma da componenti comuni dell'interfaccia del prodotto; interessano tutte le installazioni della stessa famiglia di versioni. Lo stato delle versioni precedenti deve essere valutato dal produttore.

Poiché le installazioni sono on-premise, anche se il produttore ha pubblicato la correzione, le installazioni che non hanno applicato l'aggiornamento continueranno a essere vulnerabili.

Componente Interessato

I punti 2 e 3 derivano dallo stesso blocco generatore di campi nascosti; il blocco si ripete nei moduli dilForm, adetForm, siralaForm, tkForm, ekForm e tmForm.

Soluzione

Le vulnerabilità sono state risolte dal produttore. L'applicazione deve essere aggiornata alla versione v22.2 o successiva.

Record CVE

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

Ricercatore

Alkım Coşkun – Netlore Security

Cronologia della Divulgazione