Campo di gioco XSLT e XML pubblico (con DOMDocument PHP, ecc.) Rischi per la sicurezza?

Sono un "principiante" di PHP, se puoi chiamarmi. Ma avendo analizzato le librerie XML e XSLT in passato per le vulnerabilità della sicurezza e avendo recentemente lavorato a un'applicazione che utilizza un bel po 'di XML, ecco cosa potrei pensare:

• Se è possibile passare una trasformazione XSL che causa l'esecuzione di un codice privilegiato, potrebbe essere necessario trovare alcuni modi per disabilitare tale esecuzione. Nel mondo Java (da dove vengo), questa 'caratteristica' non è uno standard, ma puoi trovarla implementata in Trasformatore Xalan-J, in cui sono state create diverse estensioni . Se un utente malintenzionato doveva passare un file XSL, che tentava di eseguire una query SQL (usando l'estensione SQL), o eseguire codice già disponibile sul server (usando l'estensione Java), Xalan-J lo farebbe, se le condizioni avevano ragione. Non sono sicuro che questo si applichi ai trasformatori utilizzati da PHP, ma vale la pena garantire che il trasformatore trasformi XML in XML e non esegua nient'altro (che sembra essere il tuo requisito). Vorrei riformularlo in parole più semplici: scegliere un trasformatore XML che possa essere bloccato il più possibile, per fornire solo la funzione necessaria per trasformare i documenti XML.
• I file e altri URI (che non sono visibili all'attaccante) possono essere specificati nell'XSL, che verrà recuperato dal trasformatore e potrebbe essere incluso nell'XML risultante. Questo è l'attacco espansione dell'entità esterna (XXE). Sarebbe possibile ottenere /etc/passwd , /etc/shadow ecc. In questo modo, se i file fossero accessibili al processo sottostante. Disabilita l'espansione dei riferimenti di entità, se puoi.
• Relativo a XXE, è XDoS che consente di montare attacchi denial-of-service, conseguente consumo di cicli della CPU. Le contromisure includono:
  • limitando il numero di espansioni di entità che possono essere eseguite dal parser (che è simile alla elaborazione sicura supporto richiesto dall'API Java per XML Processing 1.4). Una contromisura correlata in quest'area consiste nel limitare il numero di attributi che possono apparire in qualsiasi elemento del documento.
  • disabilita l'uso dei DTD; il parser deve essere configurato per rifiutare qualsiasi documento con un elemento DOCTYPE al suo interno. Questo è l'approccio adottato dalle implementazioni SOAP.
• Esiste una possibilità di XSS riflesso (presupponendo che non si sta compilando la textarea utilizzando JavaScript), per le trasformazioni XSL non è necessario generare XML valido o HTML. Il risultato potrebbe essere semplicemente una sequenza casuale di caratteri. L'output dovrebbe quindi essere opportunamente scappato per prevenire qualsiasi attacco XSS.
• Le vulnerabilità nel parser XML stesso renderanno possibili altre forme di attacco. Questo advisor CERT , è un poster-boy, poiché è indicativo dei potenziali problemi in XML analisi delle biblioteche Gli parser sono complessi, a causa dei vari requisiti imposti su di essi attraverso varie specifiche; a volte questo si traduce in casi limite in cui i parser non sarebbero in grado di gestire certe sequenze di caratteri in modo sicuro. Anche se è stato fatto molto lavoro per scrivere parser sicuri, il lavoro non può essere considerato non completo. La raccomandazione appropriata in questo caso è di scegliere una libreria di analisi XML ben implementata e compresa e di correggere periodicamente la libreria di analisi per le correzioni di sicurezza.

Quanto sopra non è necessariamente completo, ma suppongo che sia un buon punto di partenza.