Безопасность и интернационализация

Мы все знаем, что безопасность это сложно. Но это часто сложно с точки зрения математики: криптография, шифрование, алгоритмы хеширования, наборы шифров, эллиптические кривые и все остальное — сложные задачи, которые нелегко понять.

В отличие от этого, наша сегодняшняя тема — интернационализация — сложна в беспорядочной реальности. Интернационализация (для краткости часто называемая «i18n», потому что кто хочет продолжать печатать эти 18 букв между «i» и «n»?) Включает в себя некоторые чрезвычайно сложные вопросы, включая:

• тысячи человеческих языков
• десятки сценариев (латинский, кириллица, арабский, кандзи, рунический и т.д.), используемые для написания этих языков
• 1+ миллионов отдельных символов Юникода, которые составляют эти сценарии
• компьютерные кодировки для символов Unicode, таких как UTF-8 и UTF-16
• методы сравнения символов, чтобы проверить, являются ли они «одинаковыми» (для нескольких значений «одинаковые»)
• символы, которые можно визуально спутать с другими похожими символами (они называются «смешиваемые символы»)
• много, много способов, которыми люди и компьютеры могут пойти не так, пытаясь понять и обработать языки, сценарии и символы

Интернационализация — это обширная тема, которую я даже не могу начать освещать в кратком сообщении в блоге (я имею в виду написать вступительную книгу об этом, но я не нашел времени — до тех пор, посмотрите некоторые слайды, которые я создал, несколько лет назад для команды, которая публикует RFC IETF).

Для наших целей настоящее веселье начинается, когда мы рассматриваем пересечение безопасности и i18n.

Рассмотрим простой пример взлома: адрес веб-сайта www.paypa1.com с номером один вместо строчной буквы «L» в названии компании. В зависимости от того, на каком шрифте он представлен, этот адрес может заставить вас думать, что вы общаетесь с PayPal Inc., а не с каким-либо злоумышленником.

Еще хуже персонажи, которые выглядят одинаково, но не так. Рассмотрим строчку кириллицы a, которая является символом Unicode U + 0430. Вот оно: «а». Можете ли вы сказать разницу между этим и латинской маленькой буквой «а»? Я так не думаю. А что если сообщение электронной почты укажет на www.pаypаl.com, используя кириллицу вместо латинской? Вы можете сказать: «Как сегодня фишинг?»

Затем есть символы, которые Unicode может считать одинаковыми в зависимости от того, какие правила применяются. Unicode имеет понятие «эквивалентности совместимости», так что такие символы, как буква-модификатор маленькая буква ᵅ (U + 1D45) и маленькая латинская буква a ⓐ (U + 24D0), могут считаться такими же, как наша хорошая латинская маленькая буква «a» ». Если ваша система применяет неправильный набор правил (разрешающий символы с эквивалентами совместимости), то злоумышленник, который идентифицируется как ⓙⓤⓛⓘⓔⓣ, может похитить учетную запись для Джульетты, оставив Ромео очень несчастным. (Действительно, похожая уязвимость попала в музыкальный сервис Spotify несколько лет назад.)

Как показывает даже этот небольшой пример, Юникод чрезвычайно выразителен (например, для большинства ваших любимых смайликов есть символы Юникода). Однако с этой выразительностью приходит сложность и возможность злоупотреблений.

Является ли ответ заставить всех использовать старый ASCII? Нет, это было бы невероятно наивно. Live Мы живем в многоязычном мире, и важно представлять информацию и разрешать общение на языках и сценариях, которые люди понимают (помните, ASCII может быть столь же непостижимым для кого-то из Восточной Азии, как и сценарии из Восточной Азии для вас).

Так как же мы можем безопасно обрабатывать интернационализированные имена пользователей, доменные имена и другие подобные идентификаторы?

Просто используйте UTF-8, верно?

Нет.

К сожалению, высказывание «просто используйте UTF-8» является эквивалентом высказывания i18n «просто используйте SSL / TLS» для обеспечения безопасности.

Да, это поможет вам в этом, но история намного шире. На самом деле, UTF-8 не решит ни одну из проблем i18n, описанных выше, так же, как TLS не решит целый ряд проблем безопасности.

Допустим, вам нужно развернуть систему, которая позволяет пользователям регистрировать свои собственные имена пользователей. Какой лучший способ спроектировать его для безопасности и интернационализации?

Вот некоторые основные принципы, которые я бы хотел иметь в виду:

Сначала попытайтесь ограничить допустимые символы буквой и цифрами. Конечно, это забавно, если люди могут использовать в качестве имени пользователя символ Unicode для черного шахматного короля but, но если вы разрешите такие символы, вы также допустите имена пользователей, которые, как мы видели, могут быть визуально приняты за более законные имена пользователей. , В структуре PRECIS ( RFC 7564 ), которую я недавно в соавторстве с Марком Бланше, мы сделали это, определив конструкцию под названием IdentifierClass. Помимо прочего, эта конструкция также запрещает символы с эквивалентами совместимости, такие как обведенные латинскими буквами «а» circ.

Во-вторых, тщательно продумайте, какие сценарии вы можете реально и безопасно поддерживать. Например, понимаете ли вы тонкости языковых сценариев, написанных справа налево (таких как арабский и иврит)? Может ли ваша полная цепочка инструментов (базы данных, командная строка, графические интерфейсы, системы поддержки и т.д.) Даже обрабатывать такие сценарии, если вам нужно отладить некоторый код, сбросить пароль, заблокировать пользователя или изменить разрешения пользователя? Если вы не понимаете и не можете обрабатывать такие сценарии, вы в конечном итоге столкнетесь с проблемами в работе — это всего лишь вопрос времени.

В-третьих, настоятельно рекомендуется запретить строки со смешанными сценариями (то есть строки с некоторыми символами из одного сценария и несколькими символами из другого сценария). Это поможет избежать таких вещей, как строка «paypal» с кириллицей «a» вместо латинского «a».

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

Для дальнейшего прочтения ознакомьтесь со слайдами i18n, о которых я упоминал выше, инфраструктурой PRECIS ( RFC 7564 ), документом PRECIS об именах пользователей и паролях (также недавно одобренным для публикации в качестве RFC) и соображениями безопасности Unicode .

Будь в безопасности там!