Почему использование UTF-8 для кодирования во время десериализации лучше, чем ASCII? - PullRequest
Новая
       11

Почему использование UTF-8 для кодирования во время десериализации лучше, чем ASCII?

4 голосов
/ 05 марта 2020

Я хочу десериализовать файл JSON - который представляет ответ веб-службы RESTful - в соответствующие классы. Я использовал System.Text.ASCIIEncoding.ASCII.GetBytes(ResponseString) и прочитал на Microsoft Docs , что использование кодировки UTF-8 вместо ASCII лучше по соображениям безопасности.

Теперь я немного растерялся, потому что я не не знаю реальной разницы между этими двумя ( относительно безопасности ). Может кто-нибудь показать мне, каковы реальные практические преимущества использования UTF-8 по сравнению с ASCII для десериализации?

Ответы [ 2 ]

7 голосов
/ 05 марта 2020

В конечном счете, цель кодировщика - вернуть данные, которые вы должны были получить. ASCII определяет только крошечный крошечный 7-битный диапазон значений; что-либо сверх этого не обрабатывается , и вы можете получить обратно мусор - или ? из полезных нагрузок, которые включают e̵v̷e̴n̸ ̷r̵e̸m̵o̸t̸e̵l̶y̸ ̶i̴n̴t̵e̵r̷e̵s̶t̶i̷n̷g̵ ̶t̵e * 100 * 100 * 100 * 100 * 100 * 100 * 100 * 100 * 100 * 5 * 5 * 5 что происходит, когда ваше приложение получает данные, которые оно не может обработать? Мы не знаем, и это действительно может вызвать проблемы с безопасностью, когда вы получаете полезные данные, с которыми вы не можете справиться.

Это также просто откровенно смущает в этом связанном мире, если вы не можете правильно хранить и отобразить имена et c ваших клиентов (или напечатать их имена в обратном направлении из-за маркеров справа налево). Большинство людей в мире используют вещи вне ASCII ежедневно.

Поскольку UTF-8 является расширенным набором ASCII, а UTF-8 в основном выиграл войну кодирования: вы могли бы также просто использовать UTF-8 ,

1 голос
/ 05 марта 2020

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

Позвольте мне сослаться на статью из черной шляпы о Безопасность Unicode :

Кодировки символов и стандарт Unicode также подвержены уязвимости. ... часто они связаны с практическим использованием. ... следующие категории могут включать уязвимости в приложениях, которые не созданы для предотвращения соответствующих атак:

  • Визуальный спуфинг 
  • Отображения с наилучшим соответствием
  • Charset транскодирование и сопоставление символов
  • Нормализация
  • Канонизация чрезмерного UTF-8
  • Избыточное потребление
  • Замена символов
  • Удаление символов
  • Оболочка
  • Переполнение буфера
  • Управление синтаксисом
  • Несоответствие кодировки

Рассмотрим следующий ... пример. В случае U + 017F LATIN SMALL LETTER LONG S, верхний регистр и операции нормализации преобразуют символ в совершенно другое значение. В некоторых ситуациях это поведение можно использовать для создания межсайтовых сценариев или других сценариев атаки ios

... программные уязвимости возникают, когда возникают соответствия наилучшего соответствия. Вот некоторые из них:

  • Отображения с наилучшим соответствием необратимы, поэтому данные безвозвратно утеряны.
  • Символами можно манипулировать, чтобы обойти фильтры обработки строк, например межсайтовый скриптинг. (XSS) фильтры, WAF и устройства IDS.
  • С символами можно манипулировать, чтобы злоупотреблять логикой c в программном обеспечении. Например, когда символы могут использоваться для доступа к файлам в файловой системе. В этом случае наилучшее соответствие для символов, таких как ../ или file: //, может быть вредным.

Если вы на самом деле храните двоичные данные рассмотрите base64 или hex вместо .

...