Прочитать на английском

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

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

  • Статья

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

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

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

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

По умолчанию Для WideCharToMultiByte используется сопоставление "наилучшим образом" для кодовых страниц, например 1252. Однако этот тип сопоставления позволяет использовать несколько представлений одной и той же строки, потенциально делая приложение уязвимым для атак. Например, латинская прописная буква A с dieresis ("Ä") может сопоставляться с латинской прописной буквой 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, используемые в системах на японском языке, содержат символ иены (евро) вместо обратной косой черты (\). Таким образом, символ иены является запрещенным символом для файловых систем NTFS и FAT. При сопоставлении Юникода с кодовой страницей на японском языке функции преобразования сопоставляют обратную косую черту (U+005C) и обычный символ Юникода йены (U+00A5) с этим же символом. По соображениям безопасности приложения обычно не должны разрешать символ U+00A5 в строке Юникода, который может быть преобразован для использования в качестве имени файла FAT.

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

Международные доменные имена (IDN) задаются в рабочей группе по сети RFC 3490: internationalizing domain names in Applications (IDNA). В стандарте возникает ряд проблем безопасности.

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

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

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

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

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

Юникод