Итак, у нас есть обходной лист XSS, чтобы проверить нашу фильтрацию XSS, но кроме пример доброкачественной страницы Я не могу найти никаких злых или искаженных тестовых данных, чтобы убедиться, что мой код UTF-8 может обрабатывать данные с ошибкой.
Где я могу найти хорошие хорошие данные для тестирования? Или что такое сложная последовательность символов?
См. также Как файл с китайскими иероглифами знает, сколько байтов использовать для каждого символа? - без сомнения, есть и другие вопросы SO, которые также помогут.
В UTF-8 вы получаете следующие типы байтов:
Binary Hex Comments
0xxxxxxx 0x00..0x7F Only byte of a 1-byte character encoding
10xxxxxx 0x80..0xBF Continuation bytes (1-3 continuation bytes)
110xxxxx 0xC0..0xDF First byte of a 2-byte character encoding
1110xxxx 0xE0..0xEF First byte of a 3-byte character encoding
11110xxx 0xF0..0xF4 First byte of a 4-byte character encoding
(Последняя строка выглядит так, как будто она должна читать 0xF0..0xF7, однако 21-битный диапазон Unicode (U + 0000 - U + 10FFFF) означает, что максимальное допустимое значение равно 0xF4, значения 0xF5..0xF7 не может произойти в действительном UTF-8.)
Посмотрев, действительно ли определенная последовательность байтов UTF-8 означает, что вам нужно подумать:
В действительном UTF-8 байты 0xF5..0xFF не могут встречаться.
Существует несколько возможных представлений для некоторых символов. Например, символ Unicode U + 0000 (ASCII NUL) может быть представлен:
0x00
0xC0 0x80
0xE0 0x80 0x80
0xF0 0x80 0x80 0x80
Однако в стандарте Unicode четко указано, что последние три альтернативы неприемлемы, поскольку они не минимальны. Так получилось, что байты 0xC0 и 0xC1 никогда не могут отображаться в действительном UTF-8, потому что только символы, которые могут быть закодированы ими, минимально кодируются как одиночные байтовые символы в диапазоне 0x00..0x7F.
В рамках базовой многоязычной плоскости (BMP) значения Unicode U + D800 - U + DFFF зарезервированы для суррогатов UTF-16 и не могут быть закодированы в действительном UTF-8. Если они были действительны в UTF-8 (что, я подчеркиваю, это не так), то суррогаты будут закодированы:
Итак, ваши данные BAD должны содержать образцы, нарушающие эти различные рецепты.
Обратите внимание, что знак байтового байта (BOM) U + FEFF, а также незаполненное пространство нулевой ширины (ZWNBSP), не может отображаться в UTF-8 незакодированным - байты 0xFF и 0xFE не разрешены в действительном UTF-8, Закодированный ZWNBSP может отображаться в файле UTF-8 как 0xEF 0xBB 0xBF, но спецификация полностью избыточна в UTF-8.
В Unicode также есть noncharacters. U + FFFE и U + FFFF - два таких нехарактера (и последние два кодовых точки в каждой плоскости, U + 1FFFE, U + 1FFFF, U + 2FFFE, U + 2FFFF,... U + 10FFFE, U + 10FFFF - другие). Они обычно не должны отображаться в данных Unicode для обмена данными, но могут отображаться в частном порядке. См. Ссылку на часто задаваемые вопросы в Unicode для получения множества грязных деталей, включая довольно сложную историю нехарактеров в Unicode. (Исправление № 9: Уточнение о нехарактерах, которое было выпущено в январе 2013 года, делает то, что предлагает его название:— разъясняет значение несимволов.)
Статья Wikipedias UTF-8 содержит хорошее резюме того, какие байтовые последовательности действительны/недействительны. Другая статья, заслуживающая внимания, - W3C I18N FAQ: Многоязычные формы.
Вы можете использовать этот удобный онлайн-инструмент от Джеффри Бергамини, чтобы преобразовать любой текст в действительно проводную строку UTF8 Homoglyphs.
Типичный
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tem incididunt ut labore et dolore magna aliqua.
сделайте следующее:
Ḽơᶉëᶆ ȋṕšᶙṁ ḍỡḽǭᵳ ʂǐť ӓṁệẗ, ĉṓɲṩḙċťᶒţûɾ ấɖḯƥĭṩčįɳġ ḝłįʈ, şếᶑ ᶁⱺ ẽḭŭŝḿꝋď ṫĕᶆᶈṓɍ ỉñḉīḑȋᵭṵńť ṷŧ ḹẩḇőꝛế éȶ đꝍꞎôꝛȇ ᵯáꞡᶇā ąⱡîɋṹẵ.
Сверху моей головы:
0xff и 0xfe
Одиночные биты с высоким бит
Многобайтовое представление низкобайтовых символов - Хороший способ контрабанды нулей после ранних проверок.
Знаки байт-порядка - Вы проигнорируете их?