Considerazioni sulla sicurezza: funzionalità internazionali

  • Articolo

In questo argomento vengono fornite informazioni sulle considerazioni sulla sicurezza relative 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.

In questo argomento sono contenute le sezioni seguenti.

Considerazioni sulla sicurezza per le funzioni di conversione dei caratteri

MultiByteToWideChar e WideCharToMultiByte sono le funzioni Unicode e 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 ridimensionato in caratteri Unicode. Quando l'applicazione usa questa funzione, deve ridimensionare correttamente i buffer per evitare un sovraccarico del buffer.

Per impostazione predefinita WideCharToMultiByte viene usato 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 dieresi ("Ä") potrebbe essere mappata alla lettera maiuscola in alfabeto latino A ("A"); un carattere Unicode in una lingua asiatica potrebbe essere mappato a una barra ("/"). L'uso del flag di 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 l'uno con l'altro, i secondi caratteri tra loro 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 in base al nome delle impostazioni locali anziché all'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 negli schemi di ordinamento linguistico. Si noti che le altre funzioni di confronto menzionate in questo argomento non testano tutti i punti di codice per verificarne 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 usa le impostazioni locali fornite dall'applicazione per identificare elementi a più caratteri e lstrcmpi e lstrcmp usano 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 o che potrebbero contenere caratteri con semantica all'esterno del dominio dell'applicazione, ad esempio i caratteri di controllo in un URL. Le applicazioni che usano questa funzione devono fornire gestori di 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 emettono confronti impliciti. A seconda dei flag impostati, i risultati della chiamata a 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 di file FAT.

Considerazioni sulla sicurezza per i nomi di dominio internazionalizzati

I nomi di dominio internazionalizzati (IDN) sono specificati da Network Working Group RFC 3490: Internationalizing Domain Names in Applications (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 carattere alfabetico minuscolo A ("a") è indistinguibile 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 consentito da IDNA per gli IDN ha anche potenziale di spoofing all'interno di uno script specifico. Ad esempio, esiste una forte somiglianza tra il trattino meno 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 (arresto 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, poiché rende i nomi simili a 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: Unicode Security Considerations( Considerazioni sulla sicurezza Unicode). Oltre a discussioni dettagliate sui problemi di sicurezza correlati all'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 file, ma non accetta un nome di percorso. A larghezza intera U+FF43 U+FF1A U+FF3C U+FF57 U+FF49 U+FF4E 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 un accesso accidentale ai file.

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

Set di caratteri usati nei nomi di file

Convenzioni per prototipi di funzione

Gestione dell'ordinamento nelle applicazioni

Gestione dei nomi di dominio internazionalizzati (IDN)

Unicode