2009-09-11 17 views
6

Questo è in riferimento a this (excellent) answer. Dichiara che la migliore soluzione per l'input di escape in PHP è chiamare mb_convert_encoding seguito da html_entities.Perché chiamare mb_convert_encoding per disinfettare il testo?

Ma perché si chiamerebbe esattamente mb_convert_encoding con lo stesso parametro da e verso i parametri (UTF8)?

Estratto dalla risposta originale:

Anche se si utilizza htmlspecialchars ($ stringa) al di fuori dei tag HTML, si sono ancora vulnerabili a multi-byte vettori di attacco charset.

La cosa più efficace che si può avere è usare la combinazione di mb_convert_encoding e htmlentities come segue.

$str = mb_convert_encoding($str, 'UTF-8', 'UTF-8'); 
$str = htmlentities($str, ENT_QUOTES, 'UTF-8'); 

cosa questo ha un qualche tipo di beneficio che mi manca?

risposta

7

Non tutti i dati binari sono validi UTF8. Invocare mb_convert_encoding con le stesse da/a codifiche è un modo semplice per assicurarsi che si abbia a che fare con una stringa correttamente codificata per la codifica data.

Un modo per sfruttare l'omissione di convalida UTF8 è descritta nella sezione 6 (considerazioni di sicurezza) in rfc2279:

altro esempio potrebbe essere un parser che vieta la sequenza ottetto 2F 2E 2E 2F ("/ ../ "), ma consente la sequenza di ottetti illegali 2F C0 AE 2E 2F.

Ciò può essere più facilmente comprensibile esaminando la rappresentazione binaria:

110xxxxx 10xxxxxx # header bits used by the encoding 
11000000 10101110 # C0 AE 
     00101110 # 2E the '.' character 

In altre parole: (C0 AE - header-bits) == '.'

Poiché il testo citato rileva, C0 AE non è una sequenza UTF8 ottetto valido , quindi mb_convert_encoding lo avrebbe rimosso dalla stringa (o tradotto in '.', o qualcos'altro :-).

Problemi correlati