Исправлена ​​проблема, связанная с преобразованием Unicode / уязвимость в ColdFusion

Недавно мы обновили наш сканер безопасности, и он сообщает о новой проблеме.

Какое исправление рекомендуется? (Мы оказались на ACF9.)

(Также, если у вас есть пример эксплойта, ориентированный на CF, я был бы признателен.)


Проблемы преобразования Unicode

Строгость

Высоко

Тип

конфигурация

Сообщено модулем

Сценарии (XSS.script)

Описание

Эта страница уязвима для различных проблем преобразования Unicode, таких как сопоставления с наилучшим соответствием, последовательности длинных байтов, плохо сформированные последовательности.

Наилучшие соответствия отображаются, когда символ X преобразуется в совершенно другой символ Y. В общем случае наилучшие соответствия отображаются, когда символы транскодируются между Unicode и другой кодировкой.

Слишком длинные байтовые последовательности (не самая короткая форма) - UTF-8 допускает различные представления символов, которые также имеют более короткую форму. По соображениям безопасности декодер UTF-8 не должен принимать последовательности UTF-8, которые длиннее, чем необходимо для кодирования символа. Например, символ U+000A (перевод строки) должен приниматься из потока UTF-8 только в форме 0x0A, но не в любой из следующих пяти возможных длинных форм:

  • 0xC0 0x8A

  • 0xE0 0x80 0x8A

  • 0xF0 0x80 0x80 0x8A

  • 0xF8 0x80 0x80 0x80 0x8A

  • 0xFC 0x80 0x80 0x80 0x80 0x8A

Плохо сформированные подпоследовательности В соответствии с требованиями UNICODE 3.0 и отмеченными в Техническом отчете Unicode #36, если после начального байта следует недопустимый последующий байт, он НЕ должен его использовать.

Влияние

Уязвимости в программном обеспечении возникают, когда происходят сопоставления Best-Fit. Например, символами можно манипулировать, чтобы обойти фильтры обработки строк, такие как межсайтовый скриптинг (XSS) или фильтры SQL-инъекций, WAF и устройства IDS. Слишком длинная последовательность UTF-8 может использоваться для обхода тестов подстрок UTF-8, которые ищут только самое короткое возможное кодирование.

Рекомендация

Определите источник этих проблем преобразования Unicode и исправьте их. Обратитесь к ссылкам ниже для получения дополнительной информации.

Рекомендации

Unicode Security

UTF-8 и Unicode FAQ для Unix/Linux

Несколько проблем с юникодом на PHP и Firefox

Вопросы безопасности Unicode

Affecteditems

/ MySite-портал /

подробности

Зашифрованный URL-адрес POST-ввода linkServID был установлен в acu5955%EF%BC%9Cs1%EF%B9%A5s2%CA%BAs3%CA%B9uca5955

Список вопросов:

  • Символ Unicode U+02B9 ПРЕМЬЕР ПИСЬМА МОДИФИКАТОРА (закодированный как%CA%B9) был преобразован в U + 0027 APOSTROPHE (')

  • Unicode символ U+02B9 ПРЕМЬЕР ПИСЬМА МОДИФИКАТОРА (закодированный как%CA%B9) был передан... (усеченная строка)

Заголовки запроса

ПОЛУЧИТЬ

/mysite-portal/?display= логин & статус = сбой & запомнить Me = 0 & contentid = & LinkServID = acu5955% 1 Cs1es2% BAs3% B9uca5955 & returnURL = https://stage-cms.mysite.com/mysite-portal/ HTTP / 1.1 Ссылка: https://stage-cms.mysite.com/

Подключение: Keep-alive

Accept-Encoding: gzip, выкачать

Пользователь-агент: Mozilla/5.0 (совместимый; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)

Принять: */*

Ведущий: stage-cms.mysite.com

3 ответа

Канонизация не поможет вам, если ваши пользовательские входы имеют неправильную последовательность.

Для получения дополнительной информации о том, как обрабатывать неправильно сформированные подпоследовательности, см. "Ограничения в процессах преобразования" в Разделе 3.9, Формы кодирования Unicode в Unicode 5.2

В этих случаях замените недопустимые последовательности на "символ замены" U+FFFD построен именно для этой цели. Это волшебная таблетка, которая будет работать в 99,9% случаев, но оставшихся 0,1% достаточно, чтобы уничтожить ваши базы данных.

Чтобы быть по-настоящему безопасным, вам нужно полностью проанализировать ваши входные парсеры, чтобы увидеть, уязвимы ли они U+FFFD замены.

Лучшее решение, которое работает постоянно, - это прекратить синтаксический анализ, очистить мусор, а затем вернуть сообщение об ошибке.

Ответ: канонизация.

https://www.owasp.org/index.php/Canonicalization,_locale_and_Unicode

Как защитить себя

Должна быть выбрана подходящая каноническая форма, и все пользовательские данные канонизируются в эту форму до того, как будут приняты какие-либо решения об авторизации. Проверки безопасности должны выполняться после завершения декодирования UTF-8. Кроме того, рекомендуется проверить, что кодировка UTF-8 является действительным каноническим кодированием для символа, который он представляет.

http://www.mattgifford.co.uk/canonicalize-method-in-coldfusion-8-and-coldfusion-9

Существуют различные решения для этого

Для пользователей CF 8 и 9:

Набор функций для обхода этого можно найти по адресу:

https://github.com/coldfumonkeh/cfml-security

Для пользователей CF 10:

canonicalize(inputString, restrictMultiple, restrictMixed) 

Охватывает это беспокойство. См. http://help.adobe.com/en_US/ColdFusion/10.0/CFMLRef/WS932f2e4c7c04df8f-1a0d37871353e31b968-8000.html

Для пользователей Railo:

Это было решено в 4.0.0.011

https://issues.jboss.org/browse/RAILO-1873?_sscc=t

Другие вопросы по тегам