È possibile introdurre XSS modificando la codifica della lingua?

Question

Diciamo che ho un'applicazione Web che utilizza Latin1 o una codifica della lingua inglese predefinita. Voglio cambiare l'applicazione per utilizzare UTF-8 o forse un'altra codifica del linguaggio. Puoi dimostrare che questa modifica introdurrà XSS?

Questa non è una domanda specifica per PHP, ma in PHP è possibile mostrare un caso in cui htmlspecialchars($var,ENT_QUOTES); è vulnerabile a XSS e non lo è htmlspecialchars($var,ENT_QUOTES,'UTF-8');.

Answer 1

Da RFC 3629:

10. Considerazioni di sicurezza

Implementers di UTF-8 necessità di considerare gli aspetti di sicurezza di come gestire illegali UTF-8 sequenze. È che in alcune circostanze un utente malintenzionato sarebbe in grado di sfruttare un parser UTF-8 incauro inviando una sequenza di ottetti che non è consentita dalla sintassi UTF-8.

Una forma particolarmente sottile di questa attacco può essere effettuata contro un parser che esegue controlli di validità sicurezza critici contro l'UTF-8 forma codificata del suo ingresso, ma interpreta certe illegali sequenze ottetto come caratteri . Ad esempio, un parser potrebbe proibire il carattere NUL quando codificato come la sequenza singolo ottetto 00, ma consentire erroneamente il illegale sequenza due ottetto C0 80 e interpretare come un carattere NUL.Un altro esempio di potrebbe essere un parser che proibisce la sequenza di ottetti 2F 2E 2E 2F ("/../"), ma consente l'illegale sequenza di ottetti 2F C0 AE 2E 2F. L'ultimo exploit è stato effettivamente utilizzato in un virus molto diffuso che attacca i server Web nel 2001; quindi, la minaccia di sicurezza è molto reale.

Quindi è di vitale importanza per accertare che i dati è valido UTF-8.

Ma una volta fatto questo, i problemi di sicurezza legati alla codifica sono minimi. Tutti i caratteri speciali HTML sono in ASCII e UTF-8 come ISO-8859-1 è completamente compatibile ASCII. htmlspecialchars si comporterà come ti aspetti.

C'è più di un problema con le codifiche non ASCII-compatibili. Ad esempio, in GB18030, i byte ASCII 0x30 e successivi possono verificarsi all'interno della codifica di un carattere a più byte. Il carattere HYPHEN ‐ (U + 2010) è codificato come A9 5C, che include un backslash ASCII. Ciò rende più difficile gestire correttamente l'escape di backslash, invitando SQL injection.

Answer 2

Ecco un esempio sciocco che imbroglia usando in modo errato htmlspecialchars come desiderato.

<?php 
$s = htmlspecialchars($_GET['x'], ENT_QUOTES); 
$s_utf8 = htmlspecialchars($_GET['x'], ENT_QUOTES, 'UTF-8'); 

if(!empty($s)) 
    print "default: " . $_GET['x'] . "<br>\n"; 

if(!empty($s_utf8)) 
    print "utf8: " . $_GET['x'] . "<br>\n" 
?> 

Inviare qualsiasi payload XSS e aggiungere un byte UTF-8 non valido, ad es.

http://site/silly.php?x=<script>alert(0)</script>%fe

htmlspecialchars balle su un valido UTF-8 sequenza di byte e restituisce una stringa vuota. La stampa del valore $_GET è un buco evidente, ma ho un punto da fare.

In breve, si ottengono controlli byte per byte con Latin1 e UTF-8, quindi non sono a conoscenza di un esempio dipendente dalla lingua in cui htmlspecialchars mancherà un byte pericoloso in una codifica, ma non un altro.

Il punto del mio esempio è che la tua domanda era più generale (e forse un po 'troppo vaga) dei pericoli dell'XSS quando si cambia schema di codifica. Quando il contenuto inizia a trattare con codifiche multibyte diverse, gli sviluppatori possono oscurare i filtri di convalida basati su strchr(), strlen() o controlli simili che non sono a conoscenza di più byte e potrebbero essere contrastati da una% 00 nel payload. (Ehi, alcuni sviluppatori continuano a utilizzare le espressioni regolari per analizzare e disinfettare l'HTML.)

In linea di principio, penso che le due righe di esempio nella domanda abbiano uguale sicurezza per quanto riguarda la commutazione della codifica. In pratica, ci sono ancora molti modi per fare altri errori con una codifica ambigua.