как пользователь может причинить вред, если я не использую функциональность mb_check_encoding?
Это касается слишком длинных кодировок.
Из-за досадной причуды дизайна UTF-8 можно создавать последовательности байтов, которые при анализе с помощью наивного декодера битовой упаковки давали бы тот же символ, что и более короткая последовательность байтов, включая один символ ASCII.
Например, символ < обычно представляется как байт 0x3C, но также может быть представлен с помощью чрезмерно длинной последовательности UTF-8 0xC0 0xBC (или даже более избыточных 3- или 4-байтовых последовательностей).
Если вы возьмете этот ввод и обработаете его в инструменте на основе байтов, не обращающем внимания на Unicode, то можно будет избежать любого шага обработки символов, используемого в этом инструменте. Каноническим примером будет отправка 0x80 0xBC в PHP, который имеет собственные байтовые строки. Типичное использование htmlspecialchars для HTML-кодирования символа < здесь не удастся, потому что ожидаемая последовательность байтов 0x3C отсутствует. Таким образом, выходные данные скрипта по-прежнему будут включать в себя слишком длинное закодированное <, и любой браузер, читающий этот вывод, потенциально может прочитать последовательность 0x80 0xBC 0x73 0x63 0x72 0x69 0x70 0x74 как <script и вуаля! XSS.
Оверлонги давно запрещены, и современные браузеры их больше не разрешают. Но это было настоящей проблемой для IE и Opera в течение долгого времени, и нет никакой гарантии, что каждый браузер решит ее правильно в будущем. И, конечно же, это только один пример — в любом месте, где байт-ориентированный инструмент обрабатывает строки Unicode, у вас могут возникнуть аналогичные проблемы. Поэтому наилучший подход — удалить все оверлонги на самой ранней фазе ввода.
person
bobince
schedule
23.10.2012
