Безопасность PHP: как можно неправильно использовать кодировку?
Из этого превосходного вопроса "UTF-8 до конца" я прочитал об этом:
К сожалению, вы должны проверять каждую отправленную строку как действительную UTF-8, прежде чем вы попытаетесь сохранить его или использовать где-либо. PHP - это mb_check_encoding() делает трюк, но вы должны использовать его религиозно. На самом деле нет никакого способа обойти это, как вредоносные клиенты могут отправлять данные в любой кодировке, которую они хотят, и я не нашел трюка, чтобы заставить PHP сделайте это для вас надежно.
Сейчас я все еще изучаю особенности кодирования, и я хотел бы точно знать, что могут сделать вредоносные клиенты, чтобы злоупотреблять кодированием. Чего можно достичь? Может кто-нибудь привести пример? Допустим, я сохраняю пользовательский ввод в базу данных MySQL или отправляю его по электронной почте, как пользователь может причинить вред, если я не использую функциональность mb_check_encoding?
2 answers
Как пользователь может причинить вред, если я не использую функцию mb_check_encoding?
Речь идет о слишком длинных кодировках.
Из-за неудачной особенности дизайна UTF-8 можно создавать последовательности байтов, которые при анализе с помощью наивного декодера с упаковкой битов приведут к тому же символу, что и более короткая последовательность байтов, включая один символ ASCII.
Например, символ < обычно представляется в виде байта 0x3C, но также может быть представлен с использованием слишком длинной последовательности UTF-8 0xC0 0xBC (или даже более избыточных 3- или 4-байтовых последовательностей).
Если вы возьмете этот ввод и обработаете его в инструменте на основе байтов, не учитывающем Юникод, то любой шаг обработки символов, используемый в этом инструменте, может быть пропущен. Каноническим примером может быть отправка 0x80 0xBC в PHP, который содержит собственные байтовые строки. Типичное использование htmlspecialchars для HTML-кодирования символа < здесь завершится неудачей, поскольку ожидаемая последовательность байтов 0x3C не подарок. Таким образом, вывод сценария все равно будет включать в себя слишком длинную кодировку <, и любой браузер, считывающий этот вывод, потенциально может прочитать последовательность 0x80 0xBC 0x73 0x63 0x72 0x69 0x70 0x74 как <script и вуаля! XSS.
Оверлонги были запрещены с давних пор, и современные браузеры больше не разрешают их. Но это было настоящей проблемой для IE и Opera в течение длительного времени, и нет никакой гарантии, что каждый браузер исправит это в будущем. И, конечно, это только один пример - любое место, где инструмент, ориентированный на байты, обрабатывает строки Юникода, у вас потенциально могут возникнуть аналогичные проблемы. Поэтому наилучший подход состоит в том, чтобы удалить все оверлонги на самом раннем этапе ввода.
Похоже, что это сложная атака. Проверка документов на наличие mb_check_encoding указывает на "Атаку с недопустимой кодировкой". Поиск в Google "Атака с неверным кодированием" приводит к некоторым интересным результатам, которые я попытаюсь объяснить.
Когда такого рода данные отправляются на сервер, он выполняет некоторое декодирование для интерпретации передаваемых символов. Теперь сервер выполнит некоторые проверки безопасности, чтобы найти закодированную версию некоторых специальных символов, которые могут быть потенциально опасными.
Когда неверная кодировка отправляется на сервер, сервер все равно запускает свой алгоритм декодирования и оценивает неверную кодировку. Именно здесь возникает проблема, потому что проверки безопасности могут не искать недопустимые варианты, которые все равно будут создавать вредные символы при выполнении алгоритма декодирования.
Пример атаки с запросом полного списка каталогов в системе unix:
http://host/cgi-bin/bad.cgi?foo=..%c0%9v../bin/ls%20-al|
Вот несколько ссылок, если вы хотите получить больше подробное техническое объяснение того, что происходит в алгоритмах:
Http://www.cgisecurity.com/owasp/html/ch11s03.html#id2862815