Breve domanda:
Domanda: potrebbero sorgere vulnerabilità di sicurezza se un server esegue htmlentities come UTF-8 ma il client visualizza i risultati come ISO-8859-1?
Presupposto: non esistono vulnerabilità quando si utilizza un set di caratteri coerente
Domanda dettagliata:
Domanda: Potrebbe sorgere qualche vulnerabilità di sicurezza se il server htmlentities una stringa ISO-8859-1 come UTF-8? (e il client interpreta il risultato come ISO-8859-1?)
(ad esempio $results = htmlentities($iso_8859_1_string, ENT_QUOTES, "UTF-8")
Supponendo che tutto sia codificato in modo tale che non sorgano vulnerabilità quando viene utilizzata in modo coerente un'unica codifica del set di caratteri. (Ignorando se $ results = stringa vuota).
Forse se $iso_8859_1_string potrebbe contenere qualsiasi valore, i risultati verrebbero considerati come non validi UTF-8 (e restituiti ""), o come UTF-8 valido. Per UTF-8 valido, le sequenze UTF-8 sarebbero state sottoposte a escape come previsto, ma come sarebbero visualizzati i risultati sul client interpretando il risultato come ISO-8859-1? I caratteri determinano l'escape dell'intervallo 0 - 127 come previsto (come "US-ASCII"), alcuni caratteri potrebbero essere convertiti in entità html e potrebbero essere visualizzati come previsto. Ci sono caratteri UTF-8 validi nell'intervallo 128+ superiore che non risolvono le entità html? Il client vedrebbe solo un mucchio di testo / simboli incomprensibili / illeggibili, ma nessun carattere che potrebbe far sì che il browser esegua codice o passi a un contesto di esecuzione del codice? (ad esempio, nessun carattere tag come "<" ">" simboli)? (Supponendo che i risultati $ vengano inseriti in un "contesto di contenuto" e non in un "valore di attributo" o un corpo di "script").
Questa linea di pensiero è giusta?
Nota : credo di aver già elaborato il caso vice versa (cioè se il server htmlentities è una stringa UTF-8 come ISO-8859-1 e il il client interpreta il risultato come UTF-8)
(ad esempio htmlentities($utf8_string, ENT_QUOTES, "ISO-8859-1") )
Risposta: la mia ipotesi non è una vulnerabilità di sicurezza sul client (per htmlentities come ISO - > client si legge come UTF-8) perché:
-
In ISO-8859-1, caratteri nell'intervallo:
- 0-127 (US-ASCII): sono codificati esattamente allo stesso modo in UTF-8,
- 160 - > 255 in ISO-8859-1 sarebbero tutti codificati come entità HTML,
- lasciando solo l'intervallo di caratteri di 128-159 ..., ma in base alle specifiche UTF-8 di Wikipedia, link , tutti i byte UTF-8 compresi nell'intervallo 128+ fanno tutti parte di "sequenze multibyte" che comprendono un "byte iniziale" che è sempre 192 o superiore e "byte di continuazione" nell'intervallo 128+ . Pertanto,
htmlentities($utf8_string, ENT_QUOTES, "ISO-8859-1")non è stato in grado di generare alcun "byte iniziale" necessario per UTF-8 per generare sequenze multi-byte valide. Quindi qualsiasi carattere in questo intervallo apparirebbe in UTF-8 come un? (cioè un carattere non valido) a causa di non vedere alcun "byte iniziale".
Penso che questo risolva la mia domanda per l'altra direzione.
Situazione reale: un server PHP 5.3.x con backport di sicurezza utilizza ISO-8859-1 come codifica predefinita. A partire da PHP 5.4, UTF-8 è la codifica predefinita. link . Sto cercando di determinare se il codice funziona correttamente in tutti gli ambienti UTF-8 o ISO-8859-1 e se non ci sono buchi di sicurezza automatici causati da errori di codifica / mancata corrispondenza.
Sento che posso essere certo che solo l'usabilità è influenzata, ma non la sicurezza in questi casi specifici.