ch4r0nn/cve-2025-14855-pocSureForms <= 2.2.0 - Cross-Site Scripting memorizzato non autenticato
Una vulnerabilità critica di XSS Memorizzato esiste nel plugin SureForms. La vulnerabilità deriva da un'implementazione lato client non sicura in entries.js dove l'input utente viene decodificato programmaticamente (annullando la sanitizzazione lato server) e poi renderizzato utilizzando dangerouslySetInnerHTML senza una corretta sanitizzazione lato client. Ciò consente a un attaccante non autenticato di iniettare payload JavaScript dannosi tramite campi modulo standard, bypassando i filtri predefiniti di WordPress.
wp_ksesPer verificare se un sito target sta eseguendo SureForms, ispeziona l'intestazione del file di traduzione che tipicamente contiene il numero di versione.
URL Target:
http://target-site.com/wp-content/plugins/sureforms/languages/sureforms.pot
Comando di Verifica:
curl -s "http://target-site.com/wp-content/plugins/sureforms/languages/sureforms.pot" | grep "Project-Id-Version"
La vulnerabilità risiede nell'interfaccia amministrativa basata su React responsabile della visualizzazione delle voci del modulo (entries.js).
Nel file entries.js minificato, è presente una funzione di supporto (identificata come Xv nella build analizzata) progettata per gestire le entità HTML.
Logica del Codice (Ricostruita):
// Funzione Xv: Pre-elaborazione dei valori dei campi
var Xv = function(input) {
var value = input.value;
// CAUSA PRINCIPALE DELLA VULNERABILITÀ:
// Se la stringa contiene entità HTML (es. <), crea un textarea,
// inietta il contenuto e ne estrae il valore.
// Questo decodifica efficacemente le entità HTML in tag HTML grezzi.
// Esempio: "<img ...>" diventa ""
if (typeof value === "string" && value.match(/&[a-zA-Z0-9#]+;/)) {
var textarea = document.createElement("textarea");
textarea.innerHTML = value;
// Logica per annullare la sanitizzazione
if (textarea.value.includes("<") || textarea.value.includes(">")) {
value = textarea.value; // Ora 'value' contiene HTML GREZZO
}
}
return { ...input, value: value };
}
Analisi: Questa funzione vanifica la sicurezza del backend. Anche se WordPress memorizza correttamente <script> come <script> nel database, questa funzione lo riconverte in <script> subito dopo averlo recuperato dall'API.
Dopo la decodifica, i dati vengono passati al componente di rendering (identificato come Jv).
Logica del Codice (Ricostruita):
// Funzione Jv: Rendering del campo
var Jv = function(props) {
var field = props.field;
var val = field.value; // Questo valore è ora HTML grezzo (post-decodifica)
// IL TRIGGER: Verifica se la stringa assomiglia a HTML
if (typeof val === "string" && val.match(/<[^>]+>/g)) {
// IL SINK: Renderizza utilizzando dangerouslySetInnerHTML SENZA sanitizzazione lato client (es. DOMPurify)
return React.createElement("span", {
dangerouslySetInnerHTML: { __html: val }
});
}
// Render sicuro per testo non HTML
return React.createElement("span", null, val);
}
Iniezione: Un attaccante non autenticato invia un modulo sulla parte pubblica. Invece di usare tag HTML grezzi (che verrebbero rimossi/sanitizzati dal backend WordPress), l'attaccante invia Entità HTML.
Memorizzazione: WordPress vede l'input (es. <img...) come testo sicuro e lo memorizza nel database.
Esecuzione (La Trappola):
Xv rileva le entità e decodifica <img... in ` Voci (Entries).Clicca sulla voce inviata al Passo 1 per visualizzare i dettagli.
Risultato: Il browser eseguirà il payload JavaScript (alert('XSS_SUREFORMS')).