Безопасность PHP: как кодирование может быть использовано неправильно?

Из этого отличного "UTF-8 весь путь через" я прочитал об этом:

К сожалению, вы должны проверить, что каждая поданная строка действительна UTF-8, прежде чем пытаться его сохранить или использовать в любом месте. РНР mb_check_encoding() делает трюк, но вы должны использовать его религиозно. На самом деле это не так, как вредоносные клиенты может отправлять данные в любую кодировку, которую они хотят, и я не нашел трюк, чтобы заставить PHP сделать это для вас надежно.

Теперь я все еще изучаю причуды кодирования, и я хотел бы точно знать, что могут делать вредоносные клиенты, чтобы злоупотреблять кодировкой. Что можно достичь? Может ли кто-нибудь привести пример? Скажем, я сохраняю вход пользователя в базу данных MySQL или отправляю его по электронной почте, как пользователь может нанести вред, если я не использую функции mb_check_encoding?

Ответ 1

как пользователь может нанести вред, если я не использую функции mb_check_encoding?

Речь идет о оверлейных кодировках.

Из-за неудачной причуды дизайна UTF-8 можно создавать байтовые последовательности, которые при анализе с наивным декодером бит-упаковки приведут к тому же характеру, что и более короткая последовательность байтов - включая один ASCII характер.

Например, символ < обычно представлен как байт 0x3C, но также может быть представлен с использованием чередующейся последовательности UTF-8 0xC0 0xBC (или даже более избыточных трех- или четырехбайтовых последовательностей).

Если вы берете этот ввод и обрабатываете его в инструменте, базирующемся на Unicode-забывающем байте, тогда любой шаг обработки символов, используемый в этом инструменте, может быть уклонен. Канонический пример должен представлять 0x80 0xBC для PHP, который имеет собственные байтовые строки. Типичное использование htmlspecialchars для кодирования HTML символа < завершится неудачно, потому что ожидаемая байтовая последовательность 0x3C отсутствует. Таким образом, вывод script будет по-прежнему включать в себя <, и любой браузер, считывающий этот вывод, мог бы читать последовательность 0x80 0xBC 0x73 0x63 0x72 0x69 0x70 0x74 как <script и hey presto! XSS.

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

Ответ 2

Похоже, это сложная атака. Проверка документов для mb_check_encoding дает примечание к "Недопустимая атака кодирования". Googling "Invalid Encoding Attack" приводит некоторые интересные результаты, которые я попытаюсь объяснить.

Когда этот вид данных отправляется на сервер, он выполняет некоторое декодирование для интерпретации передаваемых символов. Теперь сервер выполнит некоторые проверки безопасности, чтобы искать закодированную версию некоторых специальных символов, которые могут быть потенциально опасными.

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

Пример атаки, требующей полного списка каталогов в системе unix:

http://host/cgi-bin/bad.cgi?foo=..%c0%9v../bin/ls%20-al|

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

http://www.cgisecurity.com/owasp/html/ch11s03.html#id2862815

http://www.cgisecurity.com/fingerprinting-port-80-attacks-a-look-into-web-server-and-web-application-attack-signatures.html