Recentemente ho deciso di consentire tutti i personaggi per il mio sito web. Ci sono problemi di sicurezza comuni che devo affrontare? ci sono modi per "iniettare" usando utf-8? È sicuro consentire agli utenti di utilizzare password con caratteri alfabetici non inglesi? e può gestire l'handle di bcrypt di php?
modifica: non ho idea di cosa sto facendo quando si tratta di cose come i set di caratteri.
I comuni problemi di sicurezza inerenti all'aggiunta del supporto Unicode (non specifico per UTF-8) derivano dall'aumento del potenziale di spoofing visivo e dai problemi derivanti dalla mancata corrispondenza della normalizzazione.
Spoofing visivo: dì che hai un forum con un utente chiamato "admin" di cui tutti possono fidarsi. Qualcun altro potrebbe registrare un account utente denominato "аdmin" (la prima lettera è la lettera cirillica a ) e inducono gli altri a pensare che fossero l'amministratore del sito. Questa è principalmente una tecnica per l'ingegneria sociale: è improbabile che qualsiasi software possa confondere gli utenti. (Questo specifico esempio potrebbe essere parzialmente risolto facendo in modo che il sito aggiunga una formattazione o un tocco speciale vicino al nome dell'amministratore, facendo sì che i nomi dei profili siano link alle pagine del profilo che mostrano la cronologia delle attività dell'utente e la data di iscrizione, ecc. Oltre al loro nome visibile e modificabile, si tratta di un problema più generale che non è esclusivo del supporto Unicode: gli utenti potrebbero anche nominarsi altri nomi fuorvianti come "< site > Support", "admin" con uno spazio, "admim", ecc. .)
Normalizzazione: alcuni caratteri come "ö" possono essere rappresentati in più modi. Potrebbe essere il singolo carattere U + 00F6 (LATIN SMALL LETTER O WITH DIAERESIS), oi due caratteri U + 0061 U + 0308 (LATIN SMALL LETTER O + DIAERESIS COMBINANTE). La normalizzazione è il processo di conversione di tutto il testo nella forma combinata o decomposta. Se non si utilizza costantemente la normalizzazione o si utilizza sempre la normalizzazione, non si verificheranno problemi. Tuttavia, se a volte lo fai, puoi avere problemi di sicurezza:
Ad esempio, OS X normalizza unicode nei nomi dei file. Supponiamo che tu avessi un sito Web senza alcun codice relativo alla normalizzazione in esecuzione su un server OS X dove ogni volta che un utente si registrava, veniva creato un file con il loro nome e si utilizzava un database senza alcuna normalizzazione per tenere traccia dei nomi utente che erano già registrati in ordine per impedire la registrazione dei nomi. Se avessi un utente chiamato "foö" (usando U + 00F6), allora qualcun altro potrebbe registrare un account chiamato "foö" (U + 0061 U + 0308), e il sito lo consentirebbe ma sovrascriverà il file creato dal primo utente "foö". Per risolvere questo problema, dovresti rendere la tua applicazione normalizzata in modo coerente in tutta l'applicazione, o dovresti controllare le collisioni ogni volta che attraversi un confine che normalizza in modo diverso (quando un utente si registra e devi creare un file per loro , apri il file in modalità esclusiva in modo che non funzioni se il file esiste già e puoi bloccare la registrazione del nuovo utente.
La risposta di AgentME descrive due importanti classi di vulnerabilità correlate a Unicode: somiglianza visiva e normalizzazione. Non li vado sopra.
Esistono anche vulnerabilità legate a UTF-8 in particolare. UTF-8 ha alcune sequenze di byte non valide e alcune applicazioni non le gestiscono bene, ad es. possono andare in crash o calcolare lunghezze non valide. Sequenze di byte non valide possono anche causare il caos nei parser. Ad esempio, supponiamo di avere un codice che raddoppia tutte le virgolette singole per inserirle in una query SQL:
"Robert'); DROP TABLE Studers;--" → "select * where name = '" + "Robert''); DROP TABLE Studers;--" + "'"
(Si spera che questo non sia fatto dal codice dell'applicazione ma da una libreria di basso livello ... ma nel mondo reale, c'è troppo codice che lo fa e non sempre lo fa bene.) Immagina ora che ci sia un invalid Sequenza di byte UTF-8 dopo Robert , es %codice%. La libreria di quoting e il database devono concordare se il "Robert0'); etc" deve essere raddoppiato in questo caso e in pratica non sempre sono d'accordo e ottieni un'iniezione SQL.