Condividi tramite

Considerazioni sulla sicurezza: funzionalità internazionali

  • Articolo

In questo argomento vengono fornite informazioni sulle considerazioni sulla sicurezza correlate alle funzionalità di supporto internazionale. È possibile usarlo come punto di partenza e quindi vedere la documentazione relativa alla tecnologia internazionale di interesse per considerazioni sulla sicurezza specifiche della tecnologia.

Questo argomento contiene le sezioni seguenti.

Considerazioni sulla sicurezza per le funzioni di conversione dei caratteri

MultiByteToWideChar e WideCharToMultiByte sono le funzioni Unicode e del set di caratteri più comunemente usate per convertire i caratteri tra ANSI e Unicode. Queste funzioni hanno il potenziale di causare rischi per la sicurezza perché contano gli elementi dei buffer di input e output in modo diverso. Ad esempio, MultiByteToWideChar accetta un buffer di input conteggiato in byte e inserisce i caratteri convertiti in un buffer di dimensioni in caratteri Unicode. Quando l'applicazione usa questa funzione, deve ridimensionare correttamente i buffer per evitare un sovraccarico del buffer.

wideCharToMultiByte per impostazione predefinita il mapping "più adatto" per le tabelle codici, ad esempio 1252. Tuttavia, questo tipo di mapping consente più rappresentazioni della stessa stringa, lasciando potenzialmente l'applicazione vulnerabile agli attacchi. Ad esempio, la lettera maiuscola in alfabeto latino A con dieresis ("Ä") potrebbe essere mappata alla lettera maiuscola latina A ("A"); Un carattere Unicode in una lingua asiatica potrebbe essere mappato a una barra ("/"). L'uso del flag WC_NO_BEST_FIT_CHARS è preferibile dal punto di vista della sicurezza.

Alcune tabelle codici, ad esempio, le tabelle codici 5022x (iso-2022-x) sono intrinsecamente non sicure perché consentono più rappresentazioni della stessa stringa. Il codice scritto correttamente esegue controlli di sicurezza nel formato Unicode, ma questi tipi di tabelle codici espandono la susceptibilità degli attacchi delle applicazioni e devono essere evitati, se possibile.

Considerazioni sulla sicurezza per le funzioni di confronto

I confronti tra stringhe possono potenzialmente presentare problemi di sicurezza. Poiché tutte le funzioni di confronto sono leggermente diverse, una funzione potrebbe segnalare due stringhe come uguali, mentre un'altra funzione potrebbe considerarle distinte. Di seguito sono riportate diverse funzioni che le applicazioni possono usare per confrontare le stringhe:

  • lstrcmpi. Confronta due stringhe di caratteri in base alle regole delle impostazioni locali, senza distinzione tra maiuscole e minuscole. La funzione confronta le stringhe controllando i primi caratteri tra loro, i secondi caratteri l'uno con l'altro e così via, fino a quando non trova una disuguaglianza o raggiunge le estremità delle stringhe.
  • lstrcmp. Confronta le stringhe usando tecniche simili a quelle di lstrcmpi. L'unica differenza è che lstrcmp esegue un confronto tra stringhe con distinzione tra maiuscole e minuscole.
  • CompareString, CompareStringEx (Windows Vista e versioni successive). Eseguire un confronto di stringhe sulle impostazioni locali fornite dall'applicazione. CompareStringEx è simile a CompareString, ma identifica le impostazioni locali nome delle impostazioni locali anziché identificatore delle impostazioni locali. Queste funzioni sono simili a lstrcmpi e lstrcmp, ad eccezione del fatto che operano su impostazioni locali specifiche anziché su impostazioni locali selezionate dall'utente.
  • CompareStringOrdinal (Windows Vista e versioni successive). Confronta due stringhe Unicode per testare l'equivalenza binaria. Ad eccezione dell'opzione di non distinzione tra maiuscole e minuscole, questa funzione ignora tutte le equivalenze non binarie e testa tutti i punti di codice per verificarne l'uguaglianza, inclusi i punti di codice che non hanno alcun peso nei linguistici di ordinamento schemi. Si noti che le altre funzioni di confronto indicate in questo argomento non testano tutti i punti di codice per verificare l'uguaglianza.
  • FindNLSString, FindNLSStringEx (Windows Vista e versioni successive). Individuare una stringa Unicode in un'altra stringa Unicode. FindNLSStringEx è simile a FindNLSString, ad eccezione del fatto che identifica le impostazioni locali in base al nome delle impostazioni locali anziché all'identificatore delle impostazioni locali.
  • FindStringOrdinal (Windows 7 e versioni successive). Individua una stringa Unicode in un'altra stringa Unicode. L'applicazione deve usare questa funzione anziché FindNLSString per tutti i confronti non linguistici.

Come lstrcmpi e lstrcmp, CompareString valuta i caratteri delle stringhe in base al carattere. Tuttavia, molte lingue hanno elementi a più caratteri, ad esempio l'elemento a due caratteri "CH" in spagnolo tradizionale. Poiché CompareString utilizza le impostazioni locali fornite dall'applicazione per identificare elementi a più caratteri e lstrcmpi e lstrcmp usare le impostazioni locali del thread, le stringhe identiche potrebbero non essere confrontate come uguali.

CompareString ignora i caratteri non definiti e restituisce quindi zero (che indica stringhe uguali) per molte coppie di stringhe distinte. Una stringa può contenere valori che non eseguono il mapping ad alcun carattere oppure può contenere caratteri con semantica esterna al dominio dell'applicazione, ad esempio i caratteri di controllo in un URL. Le applicazioni che usano questa funzione devono fornire gestori errori e stringhe di test per assicurarsi che siano valide prima di usarle.

Nota

Per Windows Vista e versioni successive, CompareStringEx è simile a CompareString. I problemi di sicurezza sono identici per queste funzioni.

 

Problemi di sicurezza simili si applicano alle funzioni, ad esempio FindNLSString, che effettuano confronti impliciti. A seconda dei flag impostati, i risultati della chiamata FindNLSString per cercare una stringa all'interno di un'altra stringa possono variare notevolmente.

Nota

Per Windows Vista e versioni successive, FindNLSStringEx è simile a FindNLSString. I problemi di sicurezza sono identici per queste funzioni.

 

Considerazioni sulla sicurezza per i set di caratteri nei nomi di file

La tabella codici di Windows e i set di caratteri OEM usati nei sistemi in lingua giapponese contengono il simbolo Yen (++) anziché una barra rovesciata (\). Pertanto, il carattere Yen è un carattere proibito per i file system NTFS e FAT. Quando si esegue il mapping di Unicode a una tabella codici in lingua giapponese, le funzioni di conversione eseguono il mapping della barra rovesciata (U+005C) e del normale simbolo Unicode Yen (U+00A5) allo stesso carattere. Per motivi di sicurezza, le applicazioni non devono in genere consentire il carattere U+00A5 in una stringa Unicode che potrebbe essere convertita per l'uso come nome file FAT.

Considerazioni sulla sicurezza per i nomi di dominio internazionalizzati

I nomi di dominio internazionalizzati (IDN) vengono specificati dal gruppo di lavoro di rete RFC 3490: internazionalizzazione dei nomi di dominio nelle applicazioni (IDNA). Lo standard introduce una serie di problemi di sicurezza.

I glifi che rappresentano determinati caratteri di script diversi potrebbero apparire simili o persino identici. Ad esempio, in molti tipi di carattere, il minuscolo cirillico A ("a") è indistinguishable dal latino minuscolo A ("a"). Non c'è modo di dire visivamente che "example.com" e "example.com" sono due nomi di dominio diversi, uno con un alfabeto latino minuscolo A nel nome, l'altro con un alfabeto cirillico minuscolo A. Un sito host senza scrupoli può usare questa ambiguità visiva per fingere di essere un altro sito in un attacco di spoofing.

Il set di caratteri esteso che IDNA consente gli IDN ha anche il potenziale di spoofing all'interno di uno script specifico. Ad esempio, esiste una forte somiglianza tra il trattino meno ("-" U+002D), il trattino ("—" U+2010), il trattino non di rilievo ("-" U+2011), il trattino figura ("\u2012" U+2012), il trattino en ("–" U+2013) e il segno meno ("-" U+2212).

Problemi simili derivano da determinate composizioni di compatibilità. Ad esempio, il singolo carattere Unicode NUMBER TWENTY FULL STOP ("20.", U+249B) viene convertito in "20". (U+0032 U+0030 U+002E) in un passaggio NamePrep, prima della conversione in Punycode. In altre parole, questa composizione inserisce un punto (stop completo). Tali composizioni hanno potenziale di spoofing.

La combinazione di script diversi in un IDN non indica necessariamente lo spoofing o la finalità ingannevole. Technical Report #36: Considerazioni sulla sicurezza Unicode fornisce diversi esempi di IDN ragionevoli che contengono una combinazione di script, ad esempio XML-Документы.com ("Документы" è russo per "documenti").

Gli attacchi di spoofing non sono limitati agli IDN. Ad esempio, "rnicrosoft.com" è simile a "microsoft.com", ma è un nome ASCII. Inoltre, un attacco di spoofing può essere fatto da danneggiamento di un nome. L'aggiunta di etichette aggiuntive dopo un nome di marchio noto o l'inclusione del nome del marchio nel percorso di un URL etichettato come sicuro può confondere gli utenti principianti, indipendentemente dall'uso dell'IDN. Per alcune impostazioni locali, gli IDN sono obbligatori e la forma Punycode di questi nomi è inaccettabile, perché rende i nomi come gibberish.

Per altre informazioni sui problemi di sicurezza indicati qui, oltre a un numero elevato di altri problemi relativi all'IDNA, vedere Technical Report #36: Considerazioni sulla sicurezza Unicode. Oltre a discussioni dettagliate sui problemi di sicurezza correlati a IDNA, questo report offre suggerimenti per gestire i nomi IDN sospetti nelle applicazioni.

Considerazioni sulla sicurezza per le funzioni ANSI

Nota

È consigliabile usare Unicode nelle applicazioni globalizzate, in particolare quelle nuove, se possibile. È consigliabile usare le funzioni ANSI solo se si hanno motivi di override per non usare Unicode, ad esempio la conformità a un protocollo meno recente che non supporta Unicode.

 

Molte funzioni NLS (National Language Support), ad esempio GetLocaleInfo e GetCalendarInfo, hanno versioni ANSI specifiche, in questo caso, GetLocaleInfoA e GetCalendarInfoA, rispettivamente. Quando l'applicazione usa la versione ANSI di una funzione con un sistema operativo basato su Unicode, ad esempio Windows NT, Windows 2000, Windows XP o Windows Vista, la funzione può avere esito negativo o produrre risultati non definiti. Se si ha un motivo interessante per usare le funzioni ANSI con un sistema operativo di questo tipo, assicurarsi che i dati passati dall'applicazione siano validi per ANSI.

Considerazioni sulla sicurezza per la normalizzazione Unicode

Poiché la normalizzazione Unicode può modificare la forma di una stringa, i meccanismi di sicurezza o gli algoritmi di convalida dei caratteri devono in genere essere implementati dopo la normalizzazione. Si consideri, ad esempio, un'applicazione con un'interfaccia Web che accetta un nome di file, ma non accetta un nome di percorso. U+FF43 U+FF1A U+FF3C U+FF57 U+FF49 U+FF49 U+FF44 U+FF44 U+FF4F U+FF57 U+FF53 (c : \ w i n d o w s) modifiche a U+0063 U+001A U+003C U+0077 U+0069 U+006E U+0064 U+006F U+0077 U+0073 (c:\windows) con normalizzazione KC. Se un'applicazione verifica la presenza dei due punti e dei caratteri barra rovesciata prima di implementare la normalizzazione, il risultato può essere l'accesso involontario ai file.

Sebbene la normalizzazione Unicode sia un elemento per rendere sicuri i sistemi operativi, tenere presente che la normalizzazione non è una sostituzione di criteri di sicurezza completi.

set di caratteri utilizzati nei nomi di file

convenzioni di per i prototipi di funzioni

gestione dell'ordinamento nelle applicazioni

gestione dei nomi di dominio internazionalizzati (IDN)

Unicode