È necessario disporre di filtri XSS quando sto salvando i dati come XML?

2

La mia web-app prende alcune configurazioni dall'utente e le salva in un file XML (non è stato fatto per fermare XSS). L'input è codificato XML in modo che " , & ... e tali caratteri non interrompano la struttura XML.

Quindi è necessario avere un altro livello del filtro XSS o in questo modo il salvataggio dei dati interrompe automaticamente gli attacchi XSS.

Sono consapevole del fatto che questo attacco dipende da molti e molti altri fattori come il rendering della pagina web ma consente di limitare la discussione al seguente frammento di codice, tuttavia dal modo in cui stamperò i dati molto di volta in volta sei libero di modificare echo "<h1> Hello ".$name."</h1>" per mostrarmi eventuali modi sbagliati di stampa dei dati.

$data = $_POST['malicious_user_supplied_data'];
$xml_encoded_data = xml_encode($data);
write_to_xml_as($xml_encoded_data,"config.xml");

------ config.xml --------
<user>
   <name>&lt;script&gt;alert(&quot;BigBang&quot;)&lt;/script&gt;</name>
</user>
--------------------------    

$name = get_name("config.xml") // would return &lt;script&gt;alert(&quot;BigBang&quot;)&lt;/script&gt;

echo "<h1> Hello ".$name."</h1>" // which on the browser would print &lt;script&gt;alert(&quot;BigBang&quot;)&lt;/script&gt;

Per favore mostrami alcuni esempi di lavoro in cui il filtro XML sopra può essere rotto, se ce ne sono.

    
posta vikkyhacks 06.08.2014 - 14:10
fonte

2 risposte

1

Preferirei usare JSON invece di XML. È più facile capire come funziona il parser e quindi i rischi per la sicurezza sono molto più bassi. Ad esempio, devi disattivare il caricamento di entità esterne con libxml_disable_entity_loader(true) se non vuoi un attacco XXE e così via.

L'altra parte della domanda è la generazione di HTML, SVG, ecc. nel browser. Ad esempio con innerHTML = "..." è facile iniettare javascript. Con i tag data è possibile iniettare javascript in firefox, quindi filtrare solo i tag script non è sufficiente ... Devi usare sempre le funzioni DOM come createTextNode() invece di innerHTML . Non è necessario un archivio lato server per inserire javascript. La visualizzazione di cookie o parametri di query tramite javascript è più che sufficiente. Sul lato server è necessario utilizzare anche le funzioni DOM, non sono sicuro di quanto siano sicure, ma sono molto meglio di concatenare le stringhe ... Ofc. devi filtrare contro elementi HTML, ecc ... Ma se hai bisogno di un editor di testo avanzato hai un grosso problema ...

Penso che uno strato di sicurezza non sia mai abbastanza, e in questo caso non è certamente sufficiente. Questo perché i parser HTML sono una parte della tecnologia molto complessa e la maggior parte degli sviluppatori (incluso me) ne capisce solo le basi. Ciò di cui hai veramente bisogno in questo caso sono alcune intestazioni di sicurezza , come Content-Security-Policy . Quindi lo script iniettato non sarà in grado di comunicare con il dominio dell'attaccante. (Ofc. Questo non funziona nei vecchi browser come ie6.)

    
risposta data 22.08.2014 - 19:45
fonte
0

È difficile da dire, se il codice sopra è completamente protetto, poiché non ci hai fornito la definizione di xml_encode funzione. In base ai tuoi campioni di input / output, sembra che xml_encode sia simile a htmlspecialchars che potrebbe essere utilizzato per disinfettare anche i tuoi dati XML.

Se fossi in te, deciderei di utilizzare htmlspecialchars con flag corretti ( ENT_QUOTES ) o librerie per la creazione di documenti XML (ad esempio DOMDocument::createTextNode eseguirà la codifica per te).

Poiché non esiste una definizione della funzione xml_encode , giochiamo con l'ipotesi della black-box, cosa potrebbe andare storto qui.

  • Codifica errata: È necessario assicurarsi che l'applicazione web imposti il set di caratteri corretto (ad esempio UTF-8). In caso contrario, la tua webapp potrebbe essere vulnerabile agli attacchi XSS UTF-7. Questo problema riguarda solo i vecchi browser.

  • Caratteri UTF-8: xml_encode codifica caratteri UTF-8? Come vengono visualizzati dopo il processo di codifica?

  • Sezione CDATA: Questo potrebbe essere complicato, se il xml_encode ignora le sezioni CDATA. Queste sezioni informano il parser che non ci sono marcature nei caratteri all'interno di CDATA. Devi assicurarti che anche < > " & sia codificato all'interno di CDATA.

  • Apostrofo singolo: Anche l'apostrofo singolo è codificato? In caso negativo, è necessario fare attenzione durante la visualizzazione dei dati da XML. %codice%. L'esempio precedente mostra codice vulnerabile, in quanto un utente malintenzionato potrebbe iniettare <input type='text' value='<?php echo get_name("config.xml"); ?>' /> come payload.

  • Nomi di tag: hai intenzione di consentire all'utente di controllare anche i nomi dei tag? Se sì, devi essere consapevole che esiste la possibilità di eseguire XSS direttamente dal file .xml. Dai un'occhiata qui .

risposta data 22.08.2014 - 18:48
fonte

Leggi altre domande sui tag