Consideraciones de seguridad: Características internacionales
En este tema se proporciona información sobre las consideraciones de seguridad relacionadas con las características de soporte técnico internacional. Puede usarlo como punto de partida y, a continuación, ver la documentación de la tecnología internacional de interés para las consideraciones de seguridad específicas de la tecnología.
En este tema se incluyen las siguientes secciones.
- Consideraciones de seguridad para las funciones de conversión de caracteres
- Consideraciones de seguridad para las funciones de comparación
- Consideraciones de seguridad para los juegos de caracteres en nombres de archivo
- Consideraciones de seguridad para los nombres de dominio internacionalizados
- Consideraciones de seguridad para las funciones ANSI
- Consideraciones de seguridad para la normalización unicode
Consideraciones de seguridad para las funciones de conversión de caracteres
MultiByteToWideChar y WideCharToMultiByte son las funciones Unicode y juego de caracteres más usadas para convertir caracteres entre ANSI y Unicode. Estas funciones tienen el potencial de causar riesgos de seguridad porque cuentan los elementos de los búferes de entrada y salida de forma diferente. Por ejemplo, MultiByteToWideChar toma un búfer de entrada contado en bytes y coloca los caracteres convertidos en un tamaño de búfer en caracteres Unicode. Cuando la aplicación usa esta función, debe cambiar el tamaño de los búferes correctamente para evitar una saturación del búfer.
WideCharToMultiByte tiene como valor predeterminado la asignación de "mejor ajuste" para las páginas de códigos, como 1252. Sin embargo, este tipo de asignación permite varias representaciones de la misma cadena, lo que podría dejar a la aplicación vulnerable a ataques. Por ejemplo, la letra mayúscula latina A con dieresis ("Ä") podría asignarse a la letra mayúscula latina A ("A"); Un carácter Unicode en un idioma asiático podría asignarse a una barra diagonal ("/"). Se prefiere el uso de la marca WC_NO_BEST_FIT_CHARS desde una perspectiva de seguridad.
Algunas páginas de códigos, por ejemplo, las páginas de códigos 5022x (iso-2022-x), son intrínsecamente inseguros porque permiten varias representaciones de la misma cadena. El código escrito correctamente realiza comprobaciones de seguridad en el formulario Unicode, pero estos tipos de páginas de códigos expanden la susceptibilidad a ataques de las aplicaciones y deben evitarse si es posible.
Consideraciones de seguridad para las funciones de comparación
Las comparaciones de cadenas pueden presentar problemas de seguridad. Dado que todas las funciones de comparación son ligeramente diferentes, una función podría notificar dos cadenas como iguales, mientras que otra función podría considerarlas distintas. A continuación se muestran varias funciones que las aplicaciones pueden usar para comparar cadenas:
- lstrcmpi. Compara dos cadenas de caracteres según las reglas de la configuración regional, sin distinción entre mayúsculas y minúsculas. La función compara las cadenas comprobando los primeros caracteres entre sí, los segundos entre sí, etc., hasta que encuentre una desigualdad o alcance los extremos de las cadenas.
- lstrcmp. Compara cadenas con técnicas similares a las de lstrcmpi. La única diferencia es que lstrcmp realiza una comparación de cadenas que distingue mayúsculas de minúsculas.
- CompareString, CompareStringEx (Windows Vista y versiones posteriores). Realice una comparación de cadenas en una configuración regional proporcionada por la aplicación. CompareStringEx es similar a CompareString, pero identifica una configuración regional por nombre de configuración regional en lugar de un identificador de configuración regional. Estas funciones son similares a lstrcmpi y lstrcmp , salvo que funcionan en una configuración regional específica en lugar de en una configuración regional seleccionada por el usuario.
- CompareStringOrdinal (Windows Vista y versiones posteriores). Compara dos cadenas Unicode para probar la equivalencia binaria. Excepto por la opción de no distinguir entre mayúsculas y minúsculas, esta función omite todas las equivalencias no binarias y comprueba todos los puntos de código para la igualdad, incluidos los puntos de código que no tienen ningún peso en los esquemas de ordenación lingüística. Tenga en cuenta que las demás funciones de comparación mencionadas en este tema no prueban todos los puntos de código para la igualdad.
- FindNLSString, FindNLSStringEx (Windows Vista y versiones posteriores). Busque una cadena Unicode en otra cadena Unicode. FindNLSStringEx es similar a FindNLSString, salvo que identifica una configuración regional por nombre de configuración regional en lugar de un identificador de configuración regional.
- FindStringOrdinal (Windows 7 y versiones posteriores). Busca una cadena Unicode en otra cadena Unicode. La aplicación debe usar esta función en lugar de FindNLSString para todas las comparaciones no lingüísticas.
Al igual que lstrcmpi y lstrcmp, CompareString evalúa el carácter de cadenas por carácter. Sin embargo, muchos idiomas tienen elementos de varios caracteres, por ejemplo, el elemento de dos caracteres "CH" en español tradicional. Dado que CompareString usa la configuración regional amueblada por la aplicación para identificar elementos de varios caracteres y lstrcmpi y lstrcmp , es posible que las cadenas idénticas no se comparen como iguales.
CompareString omite caracteres no definidos y, por tanto, devuelve cero (que indica cadenas iguales) para muchos pares de cadenas que son bastante distintos. Una cadena puede contener valores que no se asignan a ningún carácter o pueden contener caracteres con semántica fuera del dominio de la aplicación, como los caracteres de control de una dirección URL. Las aplicaciones que usan esta función deben proporcionar controladores de errores y cadenas de prueba para asegurarse de que son válidos antes de usarlos.
Nota
Para Windows Vista y versiones posteriores, CompareStringEx es similar a CompareString. Los problemas de seguridad son idénticos para estas funciones.
Los problemas de seguridad similares se aplican a las funciones, como FindNLSString, que realizan comparaciones implícitas. Dependiendo de las marcas establecidas, los resultados de llamar a FindNLSString para buscar una cadena dentro de otra cadena pueden diferir considerablemente.
Nota
Para Windows Vista y versiones posteriores, FindNLSStringEx es similar a FindNLSString. Los problemas de seguridad son idénticos para estas funciones.
Consideraciones de seguridad para los juegos de caracteres en nombres de archivo
Las páginas de códigos de Windows y los juegos de caracteres OEM usados en los sistemas en japonés contienen el símbolo Yen ()*) en lugar de una barra diagonal inversa (\). Por lo tanto, el carácter Yen es un carácter prohibido para los sistemas de archivos NTFS y FAT. Al asignar Unicode a una página de códigos de idioma japonés, las funciones de conversión asignan la barra diagonal inversa (U+005C) y el símbolo Unicode normal (U+00A5) a este mismo carácter. Por motivos de seguridad, las aplicaciones no suelen permitir el carácter U+00A5 en una cadena Unicode que se pueda convertir para su uso como nombre de archivo FAT.
Consideraciones de seguridad para los nombres de dominio internacionalizados
Los nombres de dominio internacionalizados (IDN) se especifican mediante el Grupo de trabajo de red RFC 3490: Internacionalización de nombres de dominio en aplicaciones (IDNA) . El estándar presenta una serie de problemas de seguridad.
Los glifos que representan determinados caracteres de scripts diferentes pueden parecerse o incluso idénticos. Por ejemplo, en muchas fuentes, el A cirílico en minúsculaS ("a") es indistinguible de la minúscula latina A ("a"). No hay ninguna manera de indicar visualmente que "example.com" y "example.com" son dos nombres de dominio diferentes, uno con una letra A minúscula latina en el nombre, la otra con una A minúscula cirílico. Un sitio host no escrupuloso puede usar esta ambigüedad visual para pretender ser otro sitio en un ataque de suplantación de identidad.
El juego de caracteres extendido que IDNA permite a los IDN también tiene potencial de suplantación de identidad dentro de un script determinado. Por ejemplo, hay una gran similitud entre el guion menos ("-" U+002D), el guión ("—" U+2010), el guión no importante ("-" U+2011), el guión de figura ("\u2012" U+2012), el guión en guion ("–" U+2013) y el signo menos ("−" U+2212).
Surgen problemas similares a partir de determinadas composiciones de compatibilidad. Por ejemplo, el único carácter Unicode NUMBER TWENTY FULL STOP ("20.", U+249B) se convierte en "20". (U+0032 U+0030 U+002E) en un paso NamePrep, antes de la conversión a Punycode. En otras palabras, esta composición inserta un punto (parada completa). Estas composiciones tienen potencial de suplantación de identidad.
La combinación de scripts diferentes en un IDN no indica necesariamente la suplantación de identidad ni la intención engañosa. Informe técnico n.º 36: Consideraciones de seguridad Unicode proporciona varios ejemplos de IDN razonables que contienen una combinación de scripts, como XML-Документы.com ("Документы" es ruso para "documentos").
Los ataques de suplantación de identidad no están restringidos a los IDN. Por ejemplo, "rnicrosoft.com" es muy similar a "microsoft.com", pero es un nombre ASCII. Además, un ataque de suplantación de identidad puede hacerse por daños en un nombre. Agregar etiquetas adicionales después de un nombre de marca conocido o incluir el nombre de marca en la ruta de acceso de una dirección URL etiquetada como segura, puede confundir a los usuarios principiantes, independientemente del uso de la IDN. En algunas configuraciones regionales, los IDN son necesarios y la forma punycode de estos nombres es inaceptable, ya que hace que los nombres sean similares a gibberish.
Para obtener más información sobre los problemas de seguridad mencionados aquí, además de un gran número de otros problemas relevantes para IDNA, vea Informe técnico n.º 36: Consideraciones de seguridad de Unicode. Junto con discusiones detalladas sobre problemas de seguridad relacionados con IDNA, este informe ofrece sugerencias para tratar con idN sospechosos en las aplicaciones.
Consideraciones de seguridad para las funciones ANSI
Nota
Se recomienda usar Unicode en las aplicaciones globalizadas, especialmente las nuevas, si es posible. Solo debe usar funciones ANSI si tiene motivos para no usar Unicode, por ejemplo, la conformidad con un protocolo anterior que no admite Unicode.
Muchas funciones de National Language Support (NLS), como GetLocaleInfo y GetCalendarInfo, tienen versiones ANSI específicas, en este caso, GetLocaleInfoA y GetCalendarInfoA, respectivamente. Cuando la aplicación usa la versión ANSI de una función con un sistema operativo basado en Unicode, como Windows NT, Windows 2000, Windows XP o Windows Vista, la función puede producir un error o producir resultados indefinidos. Si tiene una razón atractiva para usar funciones ANSI con este tipo de sistema operativo, asegúrese de que los datos pasados por la aplicación son válidos para ANSI.
Consideraciones de seguridad para la normalización unicode
Dado que la normalización Unicode puede cambiar la forma de una cadena, los mecanismos de seguridad o los algoritmos de validación de caracteres normalmente deben implementarse después de la normalización. Por ejemplo, considere una aplicación con una interfaz web que acepta un nombre de archivo, pero no acepta un nombre de ruta de acceso. Un 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) cambia a U+0063 U+001A U+003C U+0077 U+0069 U+006E U+0064 U+006F U+0077 U+0073 (c:\windows) con la normalización de KC de forma. Si una aplicación prueba la presencia de los caracteres de dos puntos y barras diagonales inversas antes de implementar la normalización, el resultado puede ser acceso accidental a archivos.
Aunque la normalización Unicode es un elemento para proteger los sistemas operativos, recuerde que la normalización no es un reemplazo de una directiva de seguridad completa.
Temas relacionados