Поделиться через

Вопросы безопасности: международные функции

В этом разделе содержатся сведения о соображениях безопасности, связанных с функциями международной поддержки. Ее можно использовать в качестве отправной точки, а затем просмотреть документацию по международной технологии, интересующей вопросы безопасности для конкретных технологий.

В этом разделе содержатся следующие разделы.

Вопросы безопасности функций преобразования символов

MultiByteToWideChar и WideCharToMultiByte являются функциями Юникода и набора символов, наиболее часто используемыми для преобразования символов между ANSI и Юникодом. Эти функции могут вызывать риски безопасности, так как они учитывают элементы входных и выходных буферов по-разному. Например, MultiByteToWideChar принимает входной буфер, подсчитываемый в байтах, и помещает преобразованные символы в размер буфера в символах Юникода. Если приложение использует эту функцию, оно должно правильно размерить буферы, чтобы избежать переполнения буфера.

WideCharToMultiByte по умолчанию сопоставляет соответствие кодовых страниц, например 1252. Однако этот тип сопоставления позволяет несколько представлений одной строки, потенциально оставляя приложение уязвимым для атаки. Например, латинская буква A с диерезами ("Ä") может сопоставляться с латинской буквой A ("A"); Символ Юникода в азиатском языке может сопоставляться с косой чертой ("/"). Использование флага WC_NO_BEST_FIT_CHARS предпочтительнее с точки зрения безопасности.

Некоторые кодовые страницы, например, кодовые страницы 5022x (iso-2022-x), по сути, небезопасны, так как они позволяют использовать несколько представлений одной строки. Правильно написанный код выполняет проверки безопасности в форме Юникода, но эти типы кодовых страниц расширяют чувствительность атак приложений и следует избегать, если это возможно.

Рекомендации по безопасности для функций сравнения

Сравнение строк может привести к проблемам безопасности. Так как все функции сравнения немного отличаются, одна функция может сообщать о двух строках как равных, а другая функция может рассматривать их отдельно. Ниже приведено несколько функций, которые могут использоваться для сравнения строк.

  • lstrcmpi. Сравнивает две символьные строки в соответствии с правилами языкового стандарта без учета регистра. Функция сравнивает строки, проверяя первые символы друг с другом, второй символы друг с другом и т. д., пока не обнаружит неравенство или не достигнет конца строк.
  • lstrcmp. Сравнивает строки с помощью методов, аналогичных методам lstrcmpi. Единственное различие заключается в том, что lstrcmp выполняет сравнение строк с учетом регистра.
  • CompareString, CompareStringEx (Windows Vista и более поздних версий). Выполните сравнение строк на языковом стандарте, предоставленном приложением. CompareStringEx похож на CompareString, но он определяет языковой стандарт по имени языкового стандарта вместо идентификатора языкового стандарта. Эти функции похожи на lstrcmpi и lstrcmp, за исключением того, что они работают на определенном языковом стандарте вместо выбранного пользователем языкового стандарта.
  • CompareStringOrdinal (Windows Vista и более поздних версий). Сравнивает две строки Юникода для проверки двоичной эквивалентности. За исключением варианта без учета регистра, эта функция игнорирует все не двоичные эквиваленты и проверяет все точки кода для равенства, включая точки кода, которые не имеют никакого веса в лингвистических сортировке схемах. Обратите внимание, что другие функции сравнения, упомянутые в этом разделе, не проверяют все точки кода для равенства.
  • FindNLSString, FindNLSStringEx (Windows Vista и более поздних версий). Найдите строку Юникода в другой строке Юникода. FindNLSStringEx похож на FindNLSString, за исключением того, что он определяет языковой стандарт по имени языкового стандарта вместо идентификатора языкового стандарта.
  • FindStringOrdinal (Windows 7 и более поздних версий). Находит одну строку Юникода в другой строке Юникода. Приложение должно использовать эту функцию вместо FindNLSString для всех нелингвистических сравнений.

Как и lstrcmpi и lstrcmp, CompareString вычисляет символы строк по символу. Однако многие языки имеют элементы с несколькими символами, например двухзначный элемент "CH" в традиционном испанском языке. Так как CompareString использует языковой стандарт, предоставленный приложением, для идентификации элементов с несколькими символами и lstrcmpi и lstrcmp использовать языковой стандарт потока, идентичные строки могут не сравниться как равные.

CompareString игнорирует неопределенные символы и, следовательно, возвращает ноль (указывающее равные строки) для многих пар строк, которые довольно разные. Строка может содержать значения, которые не сопоставляются с символами или могут содержать символы с семантикой за пределами домена приложения, например символы управления в URL-адресе. Приложения, использующие эту функцию, должны предоставлять обработчики ошибок и тестовые строки, чтобы убедиться, что они действительны перед их использованием.

Заметка

Для Windows Vista и более поздних версий CompareStringEx аналогичен CompareString. Проблемы безопасности идентичны для этих функций.

 

Аналогичные проблемы безопасности применяются к функциям, таким как FindNLSString, которые выполняют неявные сравнения. В зависимости от заданных флагов результаты вызова FindNLSString для поиска одной строки в другой строке могут значительно отличаться.

Заметка

Для Windows Vista и более поздних версий FindNLSStringEx аналогичен FindNLSString. Проблемы безопасности идентичны для этих функций.

 

Вопросы безопасности для наборов символов в именах файлов

Кодовая страница Windows и наборы символов OEM, используемые в системах японского языка, содержат символ иены (jp) вместо обратной косой черты (\). Таким образом, символ йена является запрещенным символом для файловых систем NTFS и FAT. При сопоставлении Юникода с кодовой страницей японского языка функции преобразования сопоставляют обратную косую черту (U+005C) и обычный символ Юникода (U+00A5) с таким же символом. По соображениям безопасности приложения обычно не должны разрешать символ U+00A5 в строке Юникода, которая может быть преобразована для использования в качестве имени FAT-файла.

Вопросы безопасности для международных доменных имен

Международные доменные имена (IDN) задаются группой по работе с сетями RFC 3490: интернационализация доменных имен в приложениях (IDNA). Стандарт представляет ряд проблем безопасности.

Глифы, представляющие определенные символы из разных скриптов, могут выглядеть аналогично или даже идентичны. Например, во многих шрифтах кириллица А ("a") неотличима от латинского нижнего регистра A ("a"). Нет никакого способа визуально сказать, что "example.com" и "example.com" являются двумя разными доменными именами, один с латинским строчным регистром A в имени, другой с кирилличным строчным регистром A. Недобросовестный сайт узла может использовать эту визуальную неоднозначность, чтобы притворяться другим сайтом в атаке спуфинга.

Расширенный набор символов, разрешающий IDNA для идентификаторов, также имеет спуфингов потенциал в рамках определенного скрипта. Например, Существует сильное сходство между дефисом-минус ("-" U+002D), дефисом ("-" U+2010), неразрывным дефисом ("-" U+2011), фигурным дефисом ("\u2012" U+2012), дефисом en dash ("–" U+2013) и знаком минуса ("-" U+2212).

Аналогичные проблемы возникают из определенных составов совместимости. Например, один символ Юникода NUMBER ДВАДЦАТЬ FULL STOP ("20.", U+249B) преобразуется в "20". (U+0032 U+0030 U+002E) на шаге NamePrep до преобразования в Punycode. Другими словами, эта композиция вставляет период (полная остановка). Такие композиции имеют спуфингов потенциал.

Сочетание различных сценариев в idN не обязательно указывает на спуфинго или обманчивое намерение. технический отчет No 36. Вопросы безопасности Юникода содержат несколько примеров разумных идентификаторов, содержащих сочетание сценариев, таких как XML-Документы.com ("Документы" — "Документы").

Атаки спуфингов не ограничиваются идентификаторами IDN. Например, "rnicrosoft.com" выглядит так же, как "microsoft.com", но это имя ASCII. Кроме того, атака спуфингов может быть выполнена путем повреждения имени. Добавление дополнительных меток после известного фирменного имени или в том числе фирменного имени в пути URL-адреса, помеченного как безопасный, может запутать начинающих пользователей независимо от использования идентификатора. Для некоторых языковых стандартов идентификаторы требуются, и форма Punycode этих имен неприемлема, так как она делает имена похожими на гиббериш.

Дополнительные сведения о проблемах безопасности, упомянутых здесь, а также о большом количестве других вопросов, относящихся к IDNA, см. в техническом отчете No 36: Вопросы безопасности Юникода. Наряду с подробными обсуждениями проблем безопасности, связанных с IDNA, этот отчет предлагает предложения по работе с подозрительными идентификаторами IDN в ваших приложениях.

Рекомендации по безопасности функций ANSI

Заметка

Рекомендуется использовать Юникод в глобальных приложениях, особенно новых, если это возможно. Функции ANSI следует использовать только в том случае, если у вас есть переопределяющие причины не использовать Юникод, например соответствие более старому протоколу, который не поддерживает Юникод.

 

Многие функции поддержки национального языка (NLS), такие как GetLocaleInfo и GetCalendarInfo, имеют определенные версии ANSI, в данном случае GetLocaleInfoA и GetCalendarInfoAсоответственно. Если приложение использует версию ANSI функции с операционной системой на основе Юникода, например Windows NT, Windows 2000, Windows XP или Windows Vista, функция может завершиться ошибкой или создать неопределенные результаты. Если у вас есть убедительные основания использовать функции ANSI с такой операционной системой, убедитесь, что данные, передаваемые приложением, действительны для ANSI.

Вопросы безопасности для нормализации Юникода

Так как нормализация Юникода может изменить форму строки, механизмы безопасности или алгоритмы проверки символов обычно должны быть реализованы после нормализации. Например, рассмотрим приложение с веб-интерфейсом, который принимает имя файла, но не принимает имя пути. Полная ширина 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) изменения U+0063 U+001A U+003C U+0077 U+0069 U+006E U+0064 U+006F U+0077 U+0073 (c:\windows) с нормализацией KC формы. Если приложение проверяет наличие символов двоеточия и обратной косой черты перед реализацией нормализации, результат может быть непреднамеренным доступом к файлам.

Хотя нормализация Юникода является элементом обеспечения безопасности операционных систем, помните, что нормализация не является заменой комплексной политики безопасности.

наборы символов, используемые в именах файлов

Соглашения для прототипов функций

обработка сортировки в приложениях

обработка международных доменных имен (IDN)

Юникод