Durante l'elaborazione di un documento XML nella mia applicazione, quali sono i rischi? Per esempio. se non è "Ben formata" o non viene confrontata con uno schema.
Durante l'elaborazione di un documento XML nella mia applicazione, quali sono i rischi? Per esempio. se non è "Ben formata" o non viene confrontata con uno schema.
Anche se si dispone di un documento XML "Ben formata", che non impedisce l'attacco, l'iniezione non interrompe sempre il documento XML. Per evitare attacchi di XML injection le seguenti misure dovrebbero aiutare:
Per completezza della mia risposta voglio aggiungere diversi link utili:
L'elaborazione sicura di XML tramite DTD e XSD è complicata.
Dovresti assicurarti che i dtd e xsd corretti siano referenziati per il tuo caso d'uso prima di elaborare il file xml con un parser (e che il contenuto misto xml non sia aggiunto come xmlns alternativi, definizioni dtd locali nell'xml, espansioni Entità ecc. ).
Come ho sentito su un podcast OWASP download di podcast OWASP qui , ed è particolarmente rilevante in questo contesto, bianco elenca i tuoi dati accettati (contenuto xml), non inserire mai nella lista nera i tuoi problemi noti con quel contenuto.
Disattivare i riferimenti esterni è fantastico (pensa a qualcuno che legge il tuo / etc / passwd o / etc / shadow facendo riferimento al file: // protocollo invece del dtd).
È possibile utilizzare un resolver e un file di catalogo per controllare / sostituire riferimenti esterni con copie locali conosciute che non possono essere sovvertite link
È possibile utilizzare un programma / libreria di validazione estrinseca come il validatore multi-schema di Sun / Oracle. link questo può fornire la convalida anche quando non c'è nulla da convalidare internamente e può utilizzare una tecnologia diversa / complementare come RELAX NG per convalidare il tuo xml.
Fai attenzione a tutti i tipi di iniezione (SQL, Javascript, xmlns, immagine, svg, url, xslt, xpath, ecc.) perché possono potenzialmente essere iniettati e trasmessi a un contesto all'interno del quale si attivano e diventano un pericolo per il tuo server db, server delle app o ambienti client. Considera un'immagine codificata Base64 con un compromesso IE che viene trasmesso in una pagina Web all'interno della tua infrastruttura (game over).
AncheDenial of Service sull'infrastruttura di elaborazione xml può essere una preoccupazione, ma potrebbe non essere pertinente al tuo sistema.
Nota: @anonymous ha fornito alcuni ottimi URL per le risorse pertinenti.
Il rischio principale in non controllo della sintassi del tuo XML è l'analisi non valida.
Se il software che legge l'XML non può gestire input non validi, potrebbe bloccarsi, fare qualcosa di inaspettato, esplodere spontaneamente (probabilmente no), ecc. Tali situazioni possono portare a problemi di sicurezza - ma se il software è abbastanza fragile da non essere in grado di gestire XML non valido, molto probabilmente avrà altri difetti di sicurezza, potenzialmente anche nei dati "validi".
Come un'analogia, la maggior parte dei buchi di sicurezza delle applicazioni Web (ad esempio l'iniezione SQL) non vengono attaccati utilizzando un codice HTML non valido, ma un input sintatticamente valido che causa problemi durante l'analisi. Nel tuo caso, l'XML è l'input. Il controllo dello schema è raramente sufficiente per convalidare l'input, specialmente se l'XSD / DTD / qualunque sia stato generato automaticamente. Qualunque sia il processo, l'input nell'applicazione stessa deve controllarlo.